1.自动化运维建设背景

随着IT技术的快速发展，IT系统的运维复杂度不断增加，IT部门的体量不断扩大，传统的人工操作和借助管理流程的方式已不能满足日益增长的运维工作量。而智能时代的到来，无论是DevOps的思想还是AIOps思想，自动化就像人的“手”一样，决定着最终这些技术思想的是否能够落地，决定着未来一个IT运维的生产力。

而从银行IT架构、运维的特殊性考虑，也需要结合银行自身的特点，对于双模的架构、双模的运维方式也要兼备在稳态和敏态下的自动化运维方案。

自动化运维可以带来的益处：

1. 降低成本 - 没有一家公司是不想降低成本的，而自动化运维可以通过提高效率、减少人为错误和人力需求，降低企业IT成本。
2. 提高生产力 - 自动化运维几乎不需要手动工作，这也就意味着它不仅可以提高产出，还可以将运维人员从复杂的传统运维工作中释放出来，将其知识和技能应用于更有价值的工作和任务上。此外，通过减少周转时间，每天可处理工作量也提高了。
3. 高可用 - 系统宕机可能会使企业损失惨重，无论是金钱上，还是声誉上。运维优先要保障的便是高可用，这也是自动化运维的一大目标。例如通过自动化保存和恢复机制，全天候系统监控和远程通信，以大幅降低网络停机时间；或是快速恢复，减少故障带来的损失。
4. 更可靠 - 运维常常包括一些重复的但完全必要的工作，这也就是为什么它容易出错。当人为因素从这个过程中消除时，那些昂贵的人为错误也自然消失了，这对于具有多个操作系统的大型网络尤其有用。自动化运维可以明显提高可靠性，减轻运维人员繁琐的手动任务。
5. 性能优化 - 运维专家面临的另一个问题是，让执行任务和工作流程变得更快、更高效、具备更高工作负载。传统运维方式想要满足这些需求是很困难的，而自动化运维工具则可以填补此类需求，在务虚雇佣更多员工的情况下，最大限度的提高性能。

基于以上业务发展的需要以及自动化运维的收益，结合自身IT发展的形势，某银行在自动化运维方面进行了探索和实践。

2.自动化运维平台设计

2.1需求分析

1. 建立自动化运维管理作业平台，集成自动化部署、批量变更、资源管理、资产信息自动发现等功能。
2. 实现物理机一站式批量部署，包括服务器部署以及操作系统HPUX、Linux以及Windows操作系统的部署。
3. 实现基于虚拟化平台OpenStack和VMWare的基础环境的自动化部署。
4. 实现Windows安全补丁的批量安装和管理。
5. 实现基于操作系统的批量变更的功能，包括Windows安全补丁安装、批量推送配置、批量安装软件等。
6. 实现基于操作系统层面资产信息的自动发现。
7. 实现基于操作系统的自动化巡检功能。
8. 与流程平台、配置平台的对接，实现流程数据和资源数据的整合实现资源管理功能。
9. 与流程平台对接，实现工单驱动自动化部署和变更的半自助服务。

2.2系统架构

1.总体设计思路

系统运维自动化的应用架构及关键业务流程的总体规划及设计如下：

建设自动化作业管理平台是本项目的主要工作目标，底层对接资源层，使用各类技术工具以实现自动化操作，横向对接配置管理平台、流程平台、监控平台和数据管理平台，贯穿整体统一运维管理框架，以实现自动化部署、批量变更、配置发现、自动巡检、资源管理的功能。

2.总体应用逻辑架构设计

下图是系统运维自动化的总体逻辑架构图

解释说明：

整体架构分为资源层、工具层、平台层和应用层。底层根据企业特点，目前主要是基于私有云环境以及物理裸机，私有云主要使用VmWare和OpenStack等虚拟化平台，而容器平台也逐渐将作为一种资源类型纳入到资源层的管控中。而基于金融行业的特殊性，物理裸机的部署依旧占用比重很大。在设计上依旧需要考虑物理裸机的自动化部署。

在工具层根据底层资源的类型以及特性选择相应的技术工具，如X86服务器的部署选择Cobbler，HPUnix服务器选择Ux-ignite，而虚拟化平台选择Ansible、虚拟化平台API或是命令对接的方式实现资源的自动化部署和资源管控。对接流程管理平台主要实现环境交付和变更的半自助服务，以及实现资源管控的流程信息的分类和管理。对接监控信息实现故障自愈以及资源回收。对接配置平台，是通过信息的自动发现保证配置信息的准确性。

在平台层建立自动化作业管理平台，也是本期实施的主要部分。在金融企业内部基本已建立了流程平台、配置平台、监控平台。作业管理平台，主要面向运维人员，可提供自动化操作和配置界面。

而在应用场景方面，主要需要解决的问题，一是环境的自动化部署交付、二是批量变更、三是主机信息的自动化发现、四是自动化巡检、五是资源管控。

3.关键应用实施方案

物理服务器部署

根据实际需求情况，由于物理服务器的操作系统版本没有高度统一，如RedHat、CentOS、Exsi等各类版本，故物理服务器一站式部署的实质是要形成X86物理资源池，再按需下发部署操作系统。

要实现Cobbler的自动化下推操作系统，必须提供DHCP网络环境，根据公司现有的网络环境，按如下方案实施：

1. Cobbler服务器根据其业务功能将其部署在数据中心的业务管理区（或某一个业务区中），Cobbler提供X86服务器基于PXE的自动引导安装功能，同时提供DHCP服务，并定义跨区域的多网段IP地址段。
2. 由于Cobbler的网络引导需要在DHCP网络内进行，而在目前业务网中采用的是固定IP分配方式，故采取在每个业务区建立一个Vlan作为物理服务器的预安装区，在这些区域内单独开启DHCP服务。Cobbler服务器本身作为DHCP服务器，每个区域预安装区Vlan的服务器通过本区域的接入交换机的中继服务向DHCP服务器申请IP地址。
3. 裸机上电上架时业务口先接入预安装区Vlan，该Vlan网络与同区业务网络通过接入交换机隔离。已接入各业务区Vlan的待安装裸机，在启动时会广播请求DHCP服务以获取IP地址，通过每个区汇聚层的DHCP中继服务，将其指向业务管理区（Cobbler服务器所在业务区）的DHCP服务器（部署在Cobbler服务器上）以获取IP地址，获取IP地址后会继续请求引导文件，获取镜像文件等后续操作系统部署动作。在完成操作系统的自动安装后，将该裸机服务器的业务IP由预安装Vlan切换至正式业务环境。
4. Cobbler在kickstart的基础上集成了电源管理功能，故每台X86服务器在批量上电上架后配置带外口配置，可以实现批量部署物理服务器形成物理资源池，再按需实现操作系统部署。无需在上电上架时人为开机进行引导操作系统，将批量部署和按需下发的动作分离，形成物理资源池。

具体网络结构如下图：

4.主要工具简介

Cobbler

Cobbler 是一个系统启动服务（boot server），可以通过网络启动（PXE）的方式用来快速安装、重装物理服务器和虚拟机，支持安装不同的 Linux 发行版和 Windows。该工具使用python开发，小巧轻便（才15k行代码），使用简单的命令即可完成PXE网络安装环境的配置，同时还可以管理DHCP，DNS，以及yum包镜像。

Cobbler 使用命令行方式管理，也提供了基于 Web 的界面管理工具（cobbler-web），还提供了API接口，可以方便二次开发使用。

Ignite-UX

Ignite-UX是HP-UX的系统管理工具，可以利用该工具通过镜像备份恢复的方式从网络引导并安装HP-UX操作系统。

WSUS

WSUS是个微软推出的网络化的补丁分发方案，是个免费的工具。WSUS支持微软公司全部产品的更新。通过WSUS这个内部网络中的Windows升级服务，所有Windows更新都集中下载到内部网的WSUS服务器中，而网络中的客户机通过WSUS服务器来得到更新。这在很大程度上节省了网络资源，避免了外部网络流量的浪费并且提高了内部网络中计算机更新的效率。WSUS采用C/S模式，客户端已被包含在各个WINDOWS操作系统上。从微软网站上下载的是WSUS服务器端。通过配置，将客户端和服务器端关联起来，就可以自动下载补丁了。这个配置几乎就是使用WSUS的全部工作了。

Ansible

ansible是新出现的自动化运维工具，基于Python开发，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。

3.Ansible的应用

在整个自动化运维管理平台中，除了集成部分由专业开发团队外包集成外，Ansible是由我们自己目前研究的方向和目标。而基于Ansible基本实现了自动化运维平台的后端核心部分，下面的章节主要就Ansible研究和探索的内容进行分享和探讨。

3.1Ansible的特点

Ansible在官网中被定义为Ansible is a radically simple IT automation engine。说明Ansible是一款极其简单的IT自动化工具，在0.X的版本中甚至使用Stupid Simple来形容Ansible是令人发指的简单。可见Ansible这块自动化工具非常注重Simple的理念。

虽然Ansible注重使用的简单，但它自身并不简单，它拥有丰富稳定的内置模块和开放的API接口。目前在Ansible2.3的版本中已经拥有了1014个内置模块（数据更新至2017年9月6日）。而由于其开源生态非常好使得其内置模块支持的覆盖面非常广：

系统层：Linux、Windows、AIX等，对应的模块有acl、cron、pip、yum、shell、command、file、copy、user、lvol等等。

虚拟化：OpenStack、VMware、Docker、CloudStack、LXC等，对应的模块glance_image、os_server、vmware_vmkernel、docker等等。

商业化软件：F5、ASA、Citrix、Eos等

系统应用层：Apache、Jboss、Zabbix、Rabbitmq、SVN、GIT、Mysql、Mariadb等，对应的模块apache2_module、jboss、zabbix_group、rabbitmq_binding、subversion、git等

Ansible与Puppet和Saltstack的对比

目前主流的自动化配置管理工具主要有Ansible、Puppet和SaltStack，这三款自动化开源工具的主要优劣势如表一所示，而近年来Ansible也成为了自动化配置管理工具的“网红”，其在GitHub中的社区关注度见表二。

GitHub社区活跃度：

3.2Ansible的技术能力

Ansible在Linux下的技术能力

作为开源系统和软件，Linux系统是Ansible支持最佳的操作系统。我们使用Ansible在Linux下对部分模块进行了测试和实际的运用。结果表明，模块的丰富程度很高可以覆盖绝大多数自动化运维场景。无代理的特性Ansible的管控覆盖快速、轻便。稳定性和容错能力不错。在大量覆盖千量级服务器发现了几个不足是需要寻求一些更好的解决方案的，一是Ansible会对中文字符集的操作系统支持上存在一些小问题，比如service模块；二是Ansible执行命令时会在某些被控节点特定异常时挂住，无法继续，即使采用异步模式；三是性能并不是特别好，需要调优或寻求其他解决方案。未调优情况下，管控千量级服务器可以，万量级服务器难以胜任。在8C8G的服务器上对2000台服务器执行20并发的ping模块（即单作业执行）消耗时间大约3分钟。实际在进行ZabbixAgent批量安装时，我们的Playbook有20多个作业，在安装500台服务器时使用的时间大约时20-30分钟。

常用Linux模块（基本覆盖90%的自动化场景）：

user: 用户管理
group：用户组管理
shell：调用shell
file：文件、目录管理（包括权限、属主）
copy：文件复制（包括权限、属主）
service：Linux服务管理
lineinfile：对于文本文件的处理，可通过正则表达式进行替换、新增、删除等，是配置文件调整的利器
template：下发模版文件，可以随变量变化在下发后自动生成适用于受控主机的配置文件，是配置文件管理的利器，特别适用于系统应用软件，比如mysql、jboss、apache等
authorized_key：密钥管理，可以批量下发或管理ssh密钥
unarchive：对zip、tar、gzip等格式的包可以解压
yum：使用yum管理器对包进行管理
lvg：lvm的pv和vg管理，可以创建、调整、删除vg
lvol：lvm的lv管理，可以创建、调整、删除lv
fssystem：文件系统管理
mount：文件系统挂载管理

Ansible在HPUX下的技术能力

根据公司的实际情况，Unix服务器主要是HPUX，AIX使用的比较少。故对Ansible在HPUX的使用进行了测试。

首先HPUX11.31下并未默认安装python，故需要手动安装python后才能接管。而测试结果发现支持情况不佳，HPUX下可以使用少部分的Linux的模块，而使用到一些系统级的模块时HPUX下无法支持，比如service、mount、lvg、lvol等等。所以不推荐Ansible在HPUX下直接使用。如果需要Ansible统一管控，可以通过Ansible连接后调用脚本实现管控。

Ansible在Windows下的技术能力

Ansible连接Windows主机从技术实现上是利用了Windows的Powershell及.net库，通过Python的pywinrm库实现基于Windows的winrm协议远程控制Windows主机，而调用的Ansible的内置模块实质均为Powershell脚本，仅由python程序调用。

故Ansible连接Windows主机需要Powershell3.0及.net3.5，所以WindowsServer2008需要进行升级，而Windows2012及以上版本可以直接使用。

通过测试及实际运用发现，常规运维操作覆盖能力不错。甚至使用Ansible进行WindowsHotFix补丁的安装均可以实现。当然我们在选择补丁安装时最终还是选择了微软原生的WSUS进行集成。

根据实际情况，目前依旧有不少应用运行在WindowsServer2008上，升级.net需要应用的测试，工作量较大需要逐步推进。而在WindowsServer2012及以上版本上，使用Ansible是没有什么问题的。

常用Windows模块（基本覆盖90%的自动化场景）：

win_user: windows用户管理
win_group: windows用户组管理
win_shell：调用windows内部命令或脚本
win_file：管理windows文件，包括复制、删除、创建等，包括管理文件属主、权限等
win_copy：复制windows文件，包括复制、删除、创建等，包括管理文件属主、权限等
win_service：管理windows的服务，可以启动、停止、设置自启、禁止自启
win_lineinfile：对文本文件通过正则表达式进行调整，包括插入、替换、删除
win_unzip：可对zip压缩包进行解压，win_zip可以进行打包
win_msi：对windows的msi包进行管理

Ansible在OpenStack下的技术能力

Ansible可以作为OpenStack的自动化编排工具，通过Ansible控制OpenStack的Controller节点，通过Ansible的内置模块os_server、os_volume等模块实现在OpenStack平台上管理instance和存储。

从需求出发公司目前的需求仅为环境交付。所以在实际使用中，我们根据用户对环境的需求，使用已经编制好的AnsiblePlaybook调用不同的参数在OpenStack上创建实例、挂载磁盘、进行安全加固、安装基础软件最终交付至用户，与流程对接后可以实现半自助服务。

而在社区中也可以看到大量关于Ansible安装OpenStack以及扩展的资料和实际使用情况。本文在这里不做深入介绍。另外，Git上也有不少Ansible在OpenStack上的实际案例，比如使用Ansible的Playbook来实现整个OpenStack环境的自动化应急演练，检测网络、实例、存储、以及实例上的资源异常时的系统健壮程度。

所以，我们认为Ansible可以作为OpenStack的编排工具在公司进行推广使用。

Ansible技术能力总结

Ansible的优点主要是：
一、学习曲线平滑，使用简易。具备一定脚本使用基础的运维人员两个月可以较为熟练的使用。
二、无代理，部署简单。
三、模块丰富，覆盖面较广，使用场景较多。
四、社区热度高，资料丰富。

Ansible的缺点是：
一、性能相对较弱，需要优化或更改连接模式提升性能。
二、HPUX、WindowsServer08支持较弱。
三、对于中文环境依旧存在一些弊端。
四、日志记录功能不够强大。
五、基于幂等设计，回退机制弱。

3.3Ansible的应用场景

目前公司Ansible已经广泛开始使用，目前应用的场景主要是批量变更、软件安装、环境交付以及主机信息的自动发现。

批量变更

主要应用在Linux操作系统上，根据实际运维需要我们应用在Agent批量安装、用户批量开设、配置批量更新等方面。

使用最多的是Zabbix和Flume的Agent批量安装，特别是Zabbix使用Ansible工具特别方便，除了安装Agent之外，批量更改配置非常方便，如使用Zabbix服务器或代理服务器地址更换、自定义Key的新增调整等等。

在用户开立方面也使用Ansible进行批量推送。

同时，在配置方便除了Zabbix配置之外，还在ELK的Syslog的配置上也已经进行了应用。

在使用Ansible进行批量变更的时候，需要保证代码进行充分测试，虽然Ansible在使用上非常简单，但回退机制较弱。比如文件的批量更新，虽然可以进行备份，但无法将备份批量进行回退。

基础设施即代码的概念中最困难的一点是碎片服务器，由于存在大量的存量服务器，所以这个问题无法避免。这就需要企业内部使用Ansible的时候一定要将Ansible作为一种软件代码进行管理，建立开发测试发布机制，保证代码充分测试。在批量变更的时候寻找不同类型的设备进行试点后再逐步推送。如果使用Ansible进行过一次推送后，碎片的问题基本就不是问题了，今后可以较为放心的反复更新。

关于开发测试发布机制，我们目前以GitLab为工具建立了版本控制系统，并定义了代码迁入迁出规则，严格根据流程开发、测试最后才能最终发布。

软件安装

除了批量变更之外，Ansible主要是实现基础软件的安装，比如mysql、oracle、jboss等等。在使用Ansible安装此类软件时将配置独立出来，这样可以根据用户需求获取不同参数，以实现不同配置的软件。

环境交付

除了批量变更之外，Ansible主要是实现基础软件的安装，比如mysql、oracle、jboss等等。

在环境交付层面，由于Ansible是基于操作系统或是虚拟化云平台的，所以在裸机部署上并不适用。在虚拟化云平台上，通过Ansible基于OpenStack和VMWare的模块开设实例和虚机以及挂盘，完成虚机的下放后，再进行软件的安装。从Ansible的Playbook的设计上只需要将下放虚机挂盘操作作为一部分再集成前述的软件安装部分即可。下放虚机挂盘的操作也可以由自动化运维平台中集成各个虚拟化平台的命令完成。

最后呈现的形式由用户递交环境申请信息，标注需要什么配置的服务器、几台、需要安装什么样的软件。递交申请审批通过，由自动化平台自动运行部署后交付至用户。

主机信息自动发现

利用Ansible的现成连接通道以及自带的facts模块，实现主机信息的自动发现和更新功能，并将这些信息定期更新至配置平台中，以辅助配置平台的数据准确性。由于Ansible的facts模块采集的信息有限，且基于Linux、HPUX以及Windows采集的内容也稍有不同，所以还是需要一些本地化的程序辅助。

Facts中可以采集的信息主要包含了主机的一些基础信息，如主机名、IP地址、网卡信息、CPU、MEM以及操作系统版本等信息。而从需求出发，我们可能还关注基础软件的版本信息、文件系统以及用户的信息等等。所以需要根据需求定义一些程序以获取这些信息。

我们目前采用如下图，设计方法获取主机信息，根据需求编制Ansible的模块，比如获取用户的信息，定义新的模块，定义完成后即形成新的AnsibleAD-HOC命令，通过一段程序获取所有受控的主机的facts以及自定义的信息之后将其入库，并同步更新至CMDB库。运维人员自己就可以根据自身的需求去定义需要的信息，并且将其入库，无需专业的开发人员实施。

其他场景

Ansible的其他使用场景，主要是应用的发布和变更，利用Ansible本身与Git结合的能力，考虑应用的发布，社区中也有不少这样的案例可以参考。同时公司目前也在研究以Jenkins为主要工具的持续集成、持续测试，Jenkins环境部署和应用发布的部分考虑与Ansible对接实现。

本文电子版下载：http://www.talkwithtrend.com/Document/detail/tid/416907