如何着手布局一个相对大型的的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实用技巧细节，我会博客中单独分享。