如何着手布局一个相对大型的的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这个变量是额外定义的一个变量,本次设计意义在于脚本部署过程中区分主机的作用;在这个地方定义的变量叫做局部变量或者主机变量,部署过程中仅在这个主机中生效。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
[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部署)。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
---
- 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实用技巧细节,我会博客中单独分享。