运维目标有三个阶段，第一是追求稳定性，第二是追求标准化，第三是追求自动化。对于第三阶段来说，什么是运维自动化呢？简单地讲，运维自动化就是将日常重复性工作按照事先设定好的规则，在一定时间范围内自动化运行，而不需要人工参与。接下来简单介绍运维自动化工具，要了解运维平时用到的自动化工具，就需要了解运维人员的日常工作有哪些。
一、运维的日常工作
运维的日常工作可以总结为以下四个部分，分别是：
(1) 系统安装
(2) 应用程序配置（Configuration）
(3) 命令执行与控制（Command and Control）
(4) 程序发布
接下来一一拆解。
1.1 系统安装（批量系统部署）
运维的工作是运行和维护，那首先就需要有服务器主机。当一批服务器采购回来时，首先要做的是为这批主机安装操作系统。如果只是为一两台主机安装系统，那还可以使用手动的方式安装，但如果是安装一批主机的话那效率就太低了，因此需要有便于同时安装多台操作系统的安装工具，也就是支持批量部署系统操作。批量系统部署有两种方式，一种是在裸机（bare metal）上使用安装工具部署系统，另一种是在虚拟机（virtual machine）通过虚拟机实例安装系统，以下分别介绍这两种部署方式的安装工具。
① 在裸机上安装（bare metal）
在裸机上安装时使用的安装工具常用的有 pxe 和 cobbler。
| 安装工具 | 介绍 |
| pxe | 预执行环境/预引导环境，pxe 技术能在主机未安装操作系统时，借助于网卡自身的 ROM 中的代码功能扮演成 DHCP 服务器的客户端并自己通过网络获取一个 IP 地址；还可以扮演成文件服务器的客户端来获取 bootloader 程序文件。pxe 的缺陷是只能预引导一种操作系统，例如不能同时预引导 CentOS 6/CentOS 7/ubuntu/... 中的其中两种操作系统。 |
| cobbler | cobbler 是 pxe 的二次封装，cobbler 能够整合多个预引导环境（操作系统环境）到一个镜面下。使用 cobbler 工具时需要硬件设备支持 pxe 技术。 |
②在虚拟机上安装（virtual machine）
在虚拟机上安装就更加方便，需要安装系统时只需要创建虚拟机实例，然后下载一个模板文件就可以安装完操作系统了，在这个模板文件包含了操作系统的配置。
1.2 应用程序部署（Configuration）（批量程序部署）
服务器是用来提供服务的，所以为服务器装完了操作系统后，首先要做的是的部署应用程序并提供服务，这一步骤称为应用程序部署（Configuration），包括了应用程序的安装、配置和启动。在这一步骤中常用的运维工具有 Puppet、Saltstack、Chef、Cfengine、Ansible 等。
其中，Puppet 和 Saltstack 更适用于管理大规模主机的场景，最好是管理的主机数量超过 100 台，否则难以发挥出 Puppet 和 Saltstack 的优势，而且可能使用成本大于收益。对于管理小规模主机的场景，则简单轻量级的 Ansible 更适用。另外，Puppet 学习曲线较陡峭，而 Ansible 入门非常简单。
这一部分的运维工具都支持幂等性，即前一次命令的执行不会影响后一次命令的执行。
1.3 命令执行与控制（Command and Contorl）（批量执行命令）
在平时的运维工作中，需要手动完成一些管理和控制操作时，可能需要在一批服务器的每台服务器上都执行一批命令。因此为了简化运维工作，就有了一些运维工具可以帮助同时控制多台主机，并在每台主机上执行运维人员指定的一批命令操作。在这一部分中常用的运维工具有 Fabric、Func 和 Ansible 等。其中 Fabric 是由 Python 开发的轻量级工具。相比于 Fabric，Func 是一个重量级的运维工具。
1.4 程序发布
程序发布，就是在主机上用新版本的程序替换旧版本的程序，简而言之是给服务程序换版本。在程序发布这一环节上，由于各个公司的应用业务不同，导致程序的发布流程、发布模式和发布过程中需要注意的细节是不一样的。所以程序发布几乎没有一个通用的工具来实现，发布工具基本都是各个公司自行研发的。
1.4.1 程序发布的方式
程序发布的方式可以总结为以下三种。
(1) 手动发布 ==> 人工发布
(2) 通过脚本发布 ==> 使用脚本也可以发布程序，但使用脚本时有以下两个缺陷。
① 程序环境发生变化时，脚本可能也需要随之灵活修改。如果脚本没有修改完善，可能会出现问题。
② 脚本自身能够提供的功能比较有限。例如在跨主机进行通信时，需要借助于外部服务程序并基于 SSH 协议进行通信，而脚本自身很难开发出基于网络通信的组件。
(3) 通过发布程序发布 ==> 又称运维程序，是公司内部专门研发出来的运维框架。
1.4.2 程序发布的三个要求
合格的脚本发布的整个流程需要满足三个要求，这三个要求可以类比于在飞机上换发动机的场景。这三个要求如下。
(1) 不能影响用户体验。
(2) 系统不能停机。
(3) 不能导致系统故障或造成系统完全不可用。
1.4.3 灰度模型
程序发布过程中需要基于灰度模型发布。灰度模型就是让一批主机下线，其它主机仍然向外提供服务，当这一批下线的主机更换程序版本完毕后，如果没有问题就开始上线提供服务，接着换另一批主机下线，以此类推。灰度模型有两种方式：
(1) 基于主机 ==> 例如先让 20% 的主机下线更换程序，上线后再换另一批 20% 的主机，以此类推。
(2) 基于用户 ==> 例如部分提供会员服务的网站中，可以在保障会员用户的用户体验、不保障免费用户体验的前提下进行程序发布。
1.4.4 程序发布路径
在程序发布过程中，可以为程序目录创建一个链接目录，这样便于管理程序版本。例如，在程序发布前，程序版本是 tuangou-1.1，而程序目录 /webapps/tuangou-1.1 的链接目录是 /webapps/tuangou。在执行程序版本更换时（假设更换为 tuangou-1.2），只需要将链接目录的链接路径修改为 /webapps/tuangou-1.2 即可。
创建链接目录的好处，是可以方便更换程序版本，并且在高版本程序出现bug时，可以快速“回滚”，把对用户的影响降到最低。
1.4.5 程序发布流程
程序发布流程可以总结如下。
在调度器上下线一批主机（标记为维护模式） --> 关闭服务 --> 部署新版本 --> 启动服务 --> 在调度器上启用这一批主机。
以上在运维日常中提到的运维工具都可以称为自动化运维工具，而自动化运维工具有 agent 和 agentless 类，接下来分别介绍。
二、运维工具的分类
运维工具根据在被管理端上是否装有 agent 程序，将运维工具分为 agent 和 agentless 两种类别。什么是 agent 程序呢？agent 的中文为“代理”之意，对于拥有 agent 程序的运维工具而言，当管理端（管理节点）通过网络管理被管理的主机时，被管理端主机上需要运行一个代理程序（agent 程序），并以管理员身份运行。当管理端向被管理端发送一个或多个要执行的命令时，被管理端的代理程序（agent 程序）负责代替管理端执行命令（因为 agent 程序是以管理员身份执行，所以以管理员身份代为执行其它命令）。这就是 agent 程序。
所以，运维工具的分类可总结如下。
① agent：在被管理端上装有管理程序（在管理端上运行）的代理程序（agent 程序，以管理员身份运行），在管理端和被管理端之间基于安全的认证进行通信。常见的拥有 agent 程序的运维工具有 Puppet、Func 等。
② agentless：在被管理端上无需任何配置，由管理端配置好后即可使用。管理端和被管理端之间通常基于 SSH 协议进行通信（基于 OpenSSH），也就是两者之间的底层通信依赖于系统软件。虽然基于 SSH 协议进行通信较为简单，但容易成为安全漏洞（一旦管理端被劫持，则被管理的主机的信息也会遭到泄露）。
本文出自 “Tab” 博客，请务必保留此出处http://xuweitao.blog.51cto.com/11761672/1950210
原文地址：http://xuweitao.blog.51cto.com/11761672/1950210
