运维自动化过程其实是简化对象操复杂度过程，即命令执行和文件传输的便利化过程，是开发和运维从分立对抗到合作共赢的过程. Ansible 做为当下运维自动化工具如火如荼的发展了很多年，但哪种使用方式是正确的姿势呢？本文将为大家揭开某公司互联网中心的 Ansible 应用场景
我们从如下4个角度来进行本次分享：
1、互联网中心自动化工具演化史
fabric、ansible、puppet、saltstack作为同时代的自动化工具，各有优劣：
- fabric：四者中最为轻量，但应对多/大项目，会明显“力不从心”
- puppet：老牌自动化工具，四者中最重的自动化工具，ruby语言实现
- saltstack：即puppet之后的新兴运维工具，当下 运维必备开发技能的python语言实现
- ansible：最新出现的无client客户端工具，非C/S架构。python实现，以去中心化理念推广盛行。也是目前最为火热的运维自动化工具，github 的fork和star数是第二名 saltstack 和第三名puppet两者之和还要多。
1.1 流程化、标准化是自动化的前提
在整个2016年，运维的工作重心和难点，很大一部分精力都是树立标准规范，对抗个人原则。
早期开发同学使用的是fabric来做运维工具，在运维到来之前，开发的所有选择都是合理的。运维所要发挥的价值是让事情更加专业化。
所幸，运维及时发现 fabric 在多/大项目的应对上不足以承载规模，因此，第一时间将所有逻辑迁移至 ansible。这个选择太正确的，在随后快速发展中，ansible相继承载了三十余项目。
2018年是运维自动化工具的起飞年，Ansible 结合 Jenkins 实现了初步的流程一站化，将运维和测试环境打通。
而在2019年的web化和智能化历程中，运维自研平台和测试自研平台，终于将CICD完整闭环，从开发提交版本发一刻开始，到版本是上线生产为止，所有的环境均归纳到CICD闭环中，均有完整流程和轨迹可供追溯。
1.2 版本流转流程
和绝大多数公司的使用场景一样，随着互联网技术的逐步成熟，这样的流程基本已经是标配。互联网技术成熟的标志之一就是某个技术热点的消失
- Developers 开发环境开发版本
- 提交 gitlab
- 触发 jenkins打包
- 结合自动化工具如 Ansible ，发布更新
有运维开发能力的公司往往会将各平台相互打通，实现无人干预。
1.3 AutomaticTool架构规划
我们特意分了2大模块：
- 应用发布
- 应用部署
应用发布目录主要存放运维自定义或编写的yml文件，而应用部署则主要针对 galaxy 下载或二次开发的外部引用模块。
针对应用发布模块，我们也做了很多约束和目录规范「但其实是无效的」：
- 各目录功能使用定义，如 files 目录存放普通文件；scripts存入执行脚本; tasks存放临时任务脚本等；
- 配置自动远程备份；
- 应用部署目录下的配置不能覆盖
- 等
2、用Ansible做了什么？
目前实现的功能有如下这些：
- 系统初始化（目录，用户，软件包）
- Nginx conf配置自动生成
- 业务应用环境初始化部署
-
- 一键安装指定版本
- 全量生成全服配置
- 应用权限自动刷新
- 自动化发布（console）
-
- git打通
- 自动打包&分发
- 自动备份
- DB更新自动检测及备份
- DB自动更新
- Ansible与K8S结合初探(测试)
2.1 Ansible 与应用部署
我们找一些比较经典的场景做细节探究
想象这么一个场景，新申请的服务器需要安装nginx、php等应用，你用Ansible会怎么做。
全手工写YAML playbook是一种不错但肯定不是最优路径的办法。正确的姿势如图：
- 从 glaxy 下载role
- 修改 roles
- 使用
对的，就是这么简单
2.2 Ansible 与发布
发布通常要完成的要素有如下几个方面：
- 打包
- 分发包
- 备份旧程序
- 停进程
- 更新程序
- 起进程
该 YAML只是其中一个范例，最大的特点是，其它数十个项目的发项代码和它有着惊人的相似处，修改维护成本很低，新增我通常的做法是复制一个文件，花几分钟修改下就能够满足要求了。
秘决在哪里呢？前提有提到流程化、标准化是自动化的前提
2.3 Ansible 与 nginx 配置生成
Nginx的大家都会，但正因为大家都会，也同步带来了很多风格问题。
想像这么一个场面，大家都能修改nginx配置，每个人都在修改，每个人都留下了自己的想法和气味，但最终的结果可想而知。最终nginx配置再也没人能懂，再也没人能维护了。
我们就经历了这样的惨剧，最终不得已，终于下狠心，将所有的nginx配置推翻重来。就有了现在的这种方式。使用 Ansible 命令，通过读取模板配置来动态生成 Nginx 的配置。
2.4 Ansible 与 Spring Boot
这里不想讲太多，具体直接看代码，逻辑上都很简单，只是在结合使用时，有一些接口的处理比较麻烦。
2.5 Ansible 与 web 化
如图，是我们当下使用的平台。在 Ansible 的调用上也并不优雅。主要是API接口不够完善，各模块的使用场景并非每个人都很熟悉。
2.6 Ansible使用之初始化
- 系统初始化
ans;ansible-playbook init.yml- 安装部署 proxy 应用
ans;ansible-playbook sysinit/NginxProxy.yml- 安装部署 web 应用
ans;ansible-playbook sysinit/NginxWeb.yml- 生成 Proxy Nginx 配置
ans;ansible-playbook sysinit/NginxProxy.yml --tags “nginx_vhost_generate"- 生成 Web Nginx 配置
ans;ansible-playbook sysinit/NginxWeb.yml --tags “nginx_vhost_generate,php_conf_generate"- 部署 Rabbit MongoDB等
ans;ansible-playbook sysinit/Rabbitmq.yml
ansible-playbook sysinit/Mongodb.yml
…2.7 Ansible使用之代码发布
- PHP类
$ ansible-playbook all.yml --extra-vars “project=all git_commit=a7db8750e7fb8b3845a6e5d76c6b7b6843f5bacd"
$ ansible-playbook yunying.yml --extra-vars "project=yunying git_commit=c4d753ae0e29f03961d8093760eeb9b2bdb08241"
$ ansible-playbook h5.yml --extra-vars "project=h5 git_commit=6c99ce066f7cc7134f3c5fb51d3fbcd0366e8c96"
$ ansible-playbook static.yml --extra-vars "project=static git_commit=d3ebf117e19b656eea6dfb2fe1e3a04aaa43ceb1”
…- JAVA类
$ ansible-playbook java-cloud.yml --extra-vars "project=outer git_commit=d3sdfv117e19b656eea6dfb2fe1e3a04aaa43ceb1”
$ ansible-playbook java-cloud.yml --extra-vars "project=account git_commit=d3sdfv117e19b656eea6dfb2fe1e3a04aaa43ce2ds”
……
大家可以看到，所有项目的发布项目几乎都是类似的。
3. Ansible OR Shell
使用 Ansible 工具最大的好处，我依然认为是能够打平整个团队的整体输出质量。
