自动化运维

作用 :ansible是一款强大的配置管理工具，可以对成百上千台服务器进行管理，ansible可以理解为一个管理员，基于SSH协议对多台服务器进行指令下 发实现多台服务器的批量操作，一次下发一条命令(ansible ad-hoc模式)的方式来控制服务器，也可以将多条命令写在纸上(ansible playbook模式)让服 务器按照你写好指令工作，也可以通过管理配置实现多台服务器同一时间做不通的事情。上述这些操作都可以基于ansible来实现，前提是ansible可以通 过SSH协议远程服务器 安装: Centos或者redhat可以通过yum安装 yum -y install ansible 配置：正常情况下默认配置即可满足 规划： 配置文件详解 ：/etc/ansible/ansible.cfg inventory=/etc/ansible/hosts　　表示主机清单inventory文件的位置 forks=5　　 并发连接数默认为5 sudo_user=root　　默认执行命令的用户 remote_port=22 指定连接被管理节点的管理端口，默认是22端口，建议修改成其它的端口，能够更安全 host_key_checking = False　　设置是否检查SSH主机的秘钥，值为True/False。关闭后第一次连接不会提示配置实例 timeout=60　

2020新年开始，史上最全云计算技术学习体系，全是干货！新的一年从学习开始，想好好学习的同学，可以和我一起慢慢成长，一下我将我的学习笔记一并奉献给大家。 **网络原理与应用（交换机路由器知识） Linux系统管理（系统管理） Linux网络服务与Shell脚本攻略（基本服务管理） Web服务器群集（集群服务管理） 数据库应用（各种数据库知识） Docker容器与虚拟化技术（虚拟化知识） 大型网站架构与自动化运维（自动化运维知识） Python开发向导（基础编程知识） 云计算与网络安全（云安全） 云计算部署实战（私有云及共有云知识） 学习永远不算一蹴而就的，学习永远不算晚，就看你有没有这个决心和能力 请给自己一个学习的机会，学习不怕晚，就怕不努力，如果你有一个超强的自控能力和学习能力，你也可以自学完成。 但如果你没有这个能力，还是建议你踏踏实实找个地方，创造让你学习的能力与机会，给你一个强迫自己学习的机会。 来吧！跟着我一起学习云计算吧！ 来源： 51CTO 作者： 云上Linux 链接： https://blog.51cto.com/14658705/2464819

第1章 自动化运维架构 主要讲解了自动化运维的概念，分析了现在的自动化运维的面临的挑战。基于我对自动运维的理解，提出了中小企业自动化运维架构，并讲解了该架构。后续的章节，主要是实现这个架构。 1-1 课程介绍 试看 1-2 自动化运维流程 第2章 服务器批量管理 Ansible Ansible作为一个优秀的IT资产管理、配置工具，这一章主要讲解了Ansible的使用，包括Ansible的安装、配置、使用，并且在课程的最后，结合我们公司业务的需求，实际演示了如何使用Ansible Playbook功能实现Zabbix的安装。 2-1 Ansible的介绍及流程 2-2 Ansible安装配置 2-3 Ad-hoc和Inventory的基本使用 2-4 使用ansible实战MySQL安装操作 2-5 什么是Ansible playbook 2-6 使用playbook完成一个helloword以及介绍playbook的基本结构 2-7 使用playbook实战Python环境的安装 2-8 Ansible实战安装Zabbix_Shell版 2-9 Ansible实战安装Zabbix_Playbook版 第3章 监控报警 Zabbix Zabbix作为一个非常强大的监控管理工具，这一章主要讲解的Zabbix的安装、配置，介绍了Zabbix的主要功能和使用方法，并且在课程的最后

DevOps时代下工作整合问题 什么样的工作需要整合，什么样的工作不应该整合？ 在软件交付领域，分角色的精细分工是不利于整体交付效率的，那为什么在DevOps倡导下的全栈工程师、开发运维一体化又会产生新的问题呢？如何解决这些新问题呢？ 也许，我们需要认真思考， 在整个软件交付过程中，什么样的工作需要整合，什么样的工作不应该整合。 在前DevOps时代，分角色分工的思路其实是来源于工业时代的。做过手工的都知道，如果要手工做100只灯笼，一开始会做得很慢，做了几只后，会越做越快，所谓熟能生巧。 再进一步，把做灯笼的过程拆解一下，比如拆解成搭骨架、糊纸、上色等工序，然后多找几个人来，每人负责其中一道工序，经过几番磨合，由于每个人要做的事情比较单一，很容易上手和熟练，效率将会大大提升。灯笼的成品和质量也会越来稳定。 把这个过程放大，就是一个工厂的模式。 所有工厂都是通过拆解和精细分工获得极高的效率的，而且，分工越精细，效率越高。而 生产最大的特点是在不断地做重复的事情， 产出是同样的产品，而且产品间的差异越小越好，最好趋近于零。 对于重复的事情，就应该通过拆解、精细分工、标准化和自动化来提升效率。 但是软件交付过程则完全不一样， 和生产最大的区别就是“不重样”。 每一个软件需求都是不一样的，用户想要的结果也是不一样的，这导致需求分析、开发、测试面对每个需求

在这文章里，我会分享学习过程中的一些感悟，时刻鞭挞自己，提醒自己！ 2019/12/27     最近在学习go语言，发现使用的框架越多，屏蔽掉的基础实现细节就越多，这就导致很难正在去理解为什么要这么做，只是一昧地在跟寻作者的规范和思路，这样很难在编程领域有成就，只有自己去认真地学习好底层知识，琢磨作者封装的目的和技术实现，这样才能更好地帮助我们去理解框架，去理解语言。     这点在自动化方面也是非常地类似。假设某一天，我们实现了高度地自动化，如果新来的接手系统的人，不能很好地去理解，我们对常用的一些运维操作的封装，不理解为什么我们如此封装，彻底地沦为一个使用者，那么在自动化发生故障的情况下，往往是束手无策，只能坐以待毙。高度自动化运维带来便利的同时，对于运维其实带来了更多的挑战，需要持续不断学习，理解各个自动化背后，到底做了什么内容，才能更好地去运维你的环境。 来源： CSDN 作者： xiaojinran 链接： https://blog.csdn.net/xiaojinran/article/details/103729045

1.基本语法 playbook文件格式为yaml语法.示例如下: 1.1 nginx.yaml --- - hosts: all tasks: - name: Install Nginx Package yum: name=nginx state=present - name: Copy Nginx.conf template: src=./nginx.conf.j2 dest=/etc/nginx/nginx.conf owner=root group=root mode=0644 validate='nginx -t -c %s' notify: - Restart Nginx Service handlers: - name: Restart Nginx Service service: name=nginx state=restarted ---第一行表示该文件是yaml文件,非必须,建议写上 hosts:all 定义该playbook针对的目标主机,all表示针对所有主机,这个参数支持Ad-Hoc模式的所有参数 tasks: 定义该playbook所有的tasks集合 name: Install Nginx Package定义一个task的名称,建议根据task实际任务命名 yum: name=nginx state=present 定义一个状态的action

一、Ansible概述 Ansible是今年来越来越火的一款开源运维自动化工具，通过Ansible可以实现运维自动化，提高运维工程师的工作效率，减少人为失误。Ansible通过本身集成的非常丰富的模块可以实现各种管理任务，其自带模块超过上千个。更为重要的是，它操作非常简单，即使小白也可以轻松上手，但它提供的功能又非常丰富，在运维领域，几乎可以做任何事。 1、Ansible特点 Ansible自2012年发布以来，很快在全球流行，其特点如下： Ansible基于Python开发，运维工程师对其二次开发相对比较容易； Ansible丰富的内置模块，几乎可以满足一切要求； 管理模式非常简单，一条命令可以影响上千台主机； 无客户端模式，底层通过SSH通信； Ansible发布后，也陆续被AWS、Google Cloud Platform、Microsoft Azure、Cisco、HP、VMware、Twitter等大公司接纳并投入使用； 二、Ansible的角色 使用者：如何使用Ansible实现自动化运维？ Ansible工具集：Ansible可以实现的功能？ 作用对象：Ansible可以影响哪些主机？ 1、使用者 如下图所示：Ansible使用者可以采用多种方式和Ansible交互，图中展示了四种方式： CMDB：CMDB存储和管理者企业IT架构中的各项配置信息

企业应用运维定义 我们把企业内的IT团队做一个初步职责和边界划分： 运维的起始点是拿到开发的代码包开始，然后进行资源环境准备、环境搭建、应用发布，以及一些列的运维支撑保障工作；而从运维团队内部来看，大致从技术栈层面分为几类： IDC运维： 负责操作系统及以下的运维支撑工作，主要提供稳定的网络、存储和服务器。 SA： 系统管理员，负责操作系统以上，代码以下的运维管理工作，不过有的公司，由于中间件的运维支撑与应用关联紧密，很多时候SA只负责操作系统和数据库两个内容。 应用运维： 核心职能是确保进程和服务可用，同时响应研发、运营人员的诉求，维护新版本的稳定运行，以及提供数据和服务给到运营人员。 应用运维在各个行业里面都非常重要，其发挥的价值深度，对于公司业务支撑保障和与优化辅助，都起着至关重要的作用，但面临的困境也很多。 应用架构多样性、异构化程度大；无论是多年前无法重构的单体架构，SOA架构的应用，微服务架构应用，基于业务中台的架构，还是近几年号召的云原生架构，越大的企业，应用的多样与异构化程度就越大，对于应用运维人员的技术栈要求高，管理复杂度大。 安全和质量级别要求高；无论是新版本发布，灾备切换与演练，应用故障处理还是其他维护场景，都直接影响应用服务的可用性，更不要说因为操作权限很高，可能出现误操作或破坏性行为的风险。 效率要求高；快速发现问题，定位问题和触发预案处置

一.ansible的前戏 1.ansible与saltstack对比 　　相同点:都是为了同时在多台机器上执行相同的命令; 　　　　　 都是python开发; 　　不同点: 　　　　 agent(salt 控制节点需要安装salt-master,被控节点需要安装salt-minion,而ansible不需要,它通过ssh来连接并控制被控节点) 　　　　 配置(salt配置麻烦,ansible基本不用配置) 　　　　 学习路线(salt比较陡峭,ansible比较平缓) 　　　　 第三方工具(salt比较少) 　　　　 开源社区的对接(salt比较少) 　　　　 现有用户(salt还是比ansible少一些) 　　　　　二次开发扩展的能力(ansible比较差,尤其是2.0以后) 　　　　　大规模开发(200以内一样,200以上salt会好一些,我们也可以对ansible做一些配置使其在200以上追上salt) 　　　　　Windows的支持(salt会很好多) 2.准备工作 　　准备四台干净的虚拟机,如下: 　　192.168.85.132 (主控节点,下面三个为被控节点) 　　192.168.85.133 　　192.168.85.134 　　192.168.85.135 3.安装ansible(只有主控节点192.168.85.132安装) wget -O /etc/yum

前言 通常来说，自动化运维有两种类型的运维方式： 定时的脚本任务， 比如定时更换云服务的 acess key secret , 定时检查 ecs 对外暴露的端口等 报警事件的紧急处理, 比如 ecs 实例发生异常重启 在传统的运维中，对于定时任务的处理通常用crontab脚本来实现，但是一旦管理的机器多了，必定会对脚本进行集中管理，这个时候对集中管理脚本的机器的可用性、脚本里面会散落密码明文等相关信息以及定时任务执行的记录都是一个很大的挑战；而对于事件驱动的报警处理，要么是通过短信报警告知运维人员，要么需要自建服务来处理报警信息, 无论是哪种方式，财务成本和运维成本都很大。本文探讨一种新的运维方式，利用函数计算做自动化运维，以极低的成本就可以获得一个高可靠，高质量的运维服务。 函数计算 阿里云 函数计算 是一个事件驱动的serverless计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，具体表现为： 无需采购和管理服务器等基础设施 按需付费，比如对运维管控这类低频调用的系统，财务成本通常能节约90%以上 专注业务逻辑的开发，能极大提高开发效率，比如 十分钟上线弹性高可用的图片处理服务 稳定高可用，毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力 提供日志查询、性能监控、报警等功能快速排查故障