如何着手布局一个相对大型的的ansible playbook脚本
一、适用人群
1、文章适用于已经对ansible有所了解，但是不知如何着手布局一个相对大型的脚本框架。
2、适用于运维从业者或者爱好者，对运维自动化运维有一定基础的人士。如果帮到您，我非常乐意看到；如果文章中有不妥的地方或者疑问，请留言吐槽讨论。
二、前言
文章以k8s自动部署为例，例子中展开解释，为什么要这么做。
ansible布局非常重要，类似于开发的框架。开发人员都非常清楚，一个框架的质量对于IT产品的重要性；作为一名从事运维开发的人员，也一定要培养顶层设计的习惯，尽量是在某个业务框架下输出脚本，而不是聚焦在单个问题上来输出一些零碎的脚本。
三、布局设计
1、确认部署步骤。
k8s部署是一个相对大型的脚本，我们首先整理一个安装过程中大致步骤，这个步骤可以根据自己的理解的维度来分解。
这一步非常重要，一定要考虑清楚，后续所有的布局都是以此为基础
本文例：检查环境--导入基础镜像--安装--基本配置--安装etcd--安装CA及ha--安装节点--安装核心服务--安装插件
2、布局目录、细化入口文件、主机清单
先上目录结构：（tree命令结果）
tree -A -L 2 -C k8s_deploy
-L代表只查询二级目录，蓝色为目录，白色为文件。
那么这么二级目录是怎么来的？了解ansible的剧本规则以后我们知道，ansible可以以目录来定义不同功能的入口；下面分别介绍一下：
group_vars：目录默认的all文件定义了所有安装过程中的全局变量；
roles：定义了执行的实体内容，8个子目录分别代表上一步规划的8个步骤的实际执行规则。
hosts：主机清单文件，一个列子；我个人习惯于这样定义一个主机清单，好处在于它能够适用于任何部署场景，比如不允许免密设置、ssh端口非默认、密码不统一等场景。事实上，这样的场景在生产环境很常见。
host_id这个变量是额外定义的一个变量，本次设计意义在于脚本部署过程中区分主机的作用；在这个地方定义的变量叫做局部变量或者主机变量，部署过程中仅在这个主机中生效。
[master]
192.168.100.28 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass='root' host_id=1
192.168.100.29 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass='root' host_id=2
[node]
192.168.100.30 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass='root' host_id=3
192.168.100.31 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass='root' host_id=4
[cluster:children]
master
node
site.yml：这是一个入口文件，定义了主机组、执行顺序、以及对应的规则（roles）、添加标签（能够实现自由选择rules部署）。
---
- hosts: cluster
roles:
- role: check_env
tags:
- check
- hosts: cluster
roles:
- role: load_files
tags:
- upload
- hosts: cluster
roles:
- role: install_base
tags:
- base
- hosts: master
roles:
- role: install_etcd
tags:
- etcd
- hosts: master
roles:
- role: config_ca
tags:
- ca
- hosts: cluster
roles:
- role: config_nodes
tags:
- nodes
- hosts: master
roles:
- role: config_core
tags:
- core
- hosts: master
roles:
- role: deploy_plugin
tags:
- plugin
完成了二级目录以后，需要细化三级目录，主要是roles目录；先上结构图：
命令：tree -A -L 3 k8s_deploy
这一级的目录是ansible固化的目录结构，主要有files、handlers、tasks、tempates四种；tasks必须有，其他三种根据脚本需要再决定要不要。
这里我大致介绍一下这四个目录的功能作用：先来一张某roles下最终的目录结构图
files：放文件的地方，当前roles下默认文件源地址
handler：定义当ansible执行状态为changed时触发的规则；和notify配合使用；必须有入口文件main.yml
tasks：定义主要的主要的执行规则，必须有入口文件main.yml
templates：使用jinja2的语法规则，存放j2模板的地方
四、如何灵活执行ansible playbook
场景1、你需要使用自定义的hosts
ansible-playbook -i hosts site.yml
场景2、你需要执行其中一部分的rules
ansible-playbook -i hosts site.yml --tags="check,upload"
场景3、你不需要执行其中一部分的rules
ansible-playbook -i hosts site.yml --skip-tags="check,upload"
做到这里，基本上就剩coding了，大梁已经搭好，添砖加瓦就是了。
结语：
本文主要说的是布局，至于ansible playbook实用技巧细节，我会博客中单独分享。
