关于java:进击的-Ansible二如何快速搞定生产环境-Ansible-项目布局

Tips：与前文《进击的 Ansible（一）：Ansible 疾速入门》一样，本文应用的 Ansible 版本 2.5.4，我的项目演示环境 MacOS。因为 Ansible 我的项目开发沉闷版本更新快，很多 API 接口不向后兼容，所以对照本文实际时请确保所用版本统一。

学完前文《进击的 Ansible（一）：Ansible 疾速入门》后，用来公布单体我的项目入不敷出。然而理论生产环境中一个服务往往有多个组件，比方部署大数据服务时，经常须要部署一个“大数据全家桶”：Hadoop、Zookeeper、Hive、Mysql、Flink 等。这时仅靠前文中的常识就有点顾此失彼了，繁多的 yaml 文件和其余配置文件依赖关系简单，如果不能正确地划分目录组织我的项目构造，对于前期保护十分不利。所以明天的文章着重解决一下这个问题：如何迷信正确地划分 Ansible 利用的目录构造？

把 Ansible 视为一种编程语言
首先要建立这样一个观点：“把 Ansible 视为一种编程语言”。咱们能够将 Ansible 了解为专门用来治理自动化公布的 DSL，它的根本语法规定约等于 yaml 语言规定，诸如 synchronize、pip、template 等。同时 Ansible 模块可等价为语言的内置函数或内置包，也就是编写 playbook 就是在写 Ansible 这门语言的代码块。如此，只有咱们沿着编程语言的思路去了解 Ansible，很多纳闷会迎刃而解：比方 Ansible 反对变量，模块 when 就是编程语言的流程管制语句 if，模块 loop 或 with_* 就是编程语言中的循环迭代语句 for 或 while。

应用编程语言进行我的项目开发的过程中，咱们是如何升高我的项目复杂度的？当然是进行“模块化”。不同的性能封装到不同的包或文件中，这样形成一个业务性能的最小单位咱们称之为“模块”。在我的项目的入口文件中，咱们通过 import (Python、Golang 等语言中应用此关键字) 或 require（Node.js 等语言应用此关键字）等关键字把须要的模块载入进来，而后就能够进行业务逻辑上的编排。https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…

这样做的长处不言而喻，一个模块是一个业务性能的具体实现，当前期有批改的需要时只须要批改相干的模块即可，这正是 SOLID 准则中的“SRP”(繁多职责准则) 所提倡的。此外，模块化还反对像“搭积木”一样依据业务需要灵便地组织业务流程，这样就能最大限度地复用以后模块，这也合乎编程准则中的“DRY”(Don’t Repeat Yourself)。

因而在咱们将 Ansible 视为一门编程语言（DSL）的当初，咱们能够发现在 Ansible 文档中用 Roles 示意“模块”这个概念，用 import_tasks、include_tasks 等示意 import 这个概念。这里说一个题外话，不晓得有没有人感觉 Ansible 中创造的“playbook”、“roles”等直译成“剧本”、“角色”的概念让人摸不着头脑？

至关重要的概念：Roles
当初咱们建立了“Roles = 模块”的概念。咱们在看一下文档中对 Roles 的定义，丰盛一下细节：

Roles let you automatically load related vars, files, tasks, handlers, and other Ansible artifacts based on a known file structure. After you group your content in roles, you can easily reuse them and share them with other users.

“角色容许您基于已知的文件构造主动加载相干的变量、文件、工作、处理程序和其余 Ansible 工件。在将内容按角色分组后，能够轻松地重用它们并与其余用户共享它们。”

直白来讲就是 Roles 是对变量、文件、工作等的封装，目标是为了模块重用。

如何应用 Roles？

在软件设计范式的最佳实际中有一条叫做“约定大于配置”，简略来讲就是“软件中做了一些前提性假如，这些假如就是软件开发者与软件用户的约定。作为软件用户你恪守这些约定即可，不再须要（或不反对）对这些约定进行配置。”—— 肯定水平上能够了解为软件中的默认配置。

Ansible 在应用 Roles 时同样存在“约定大于配置”的状况，并且这些约定是硬性的（即不反对在配置文件中自定义）。

首先，Role 的目录构造是固定的。

An Ansible role has a defined directory structure with eight main standard directories. You must include at least one of these directories in each role. You can omit any directories the role does not use.

Ansible 角色有一个定义好的目录构造，其中有八个次要的规范目录。该已规定好的目录构造，示例如下：

├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── tasks
│ └── main.yml
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars

└── main.yml

By default Ansible will look in each directory within a role for a main.yml file for relevant content.

这八个目录的作用是：

tasks/main.yml：搁置 role 执行工作时用到的文件。

handlers/main.yml：处理程序，能够在 role 外部或内部应用

library/my_module.py：模块，能够在 role 中应用(无关更多信息，请参见在 rroles 中嵌入模块和插件)。

defaults/main.yml：role 的默认变量 (无关更多信息，请参阅应用变量)。这些变量具备所有可用变量中最低的优先级，并且能够被任何其余变量(包含库存变量) 轻松笼罩。

vars/main.yml：role 中的其余变量。（与 Ansible 模块中的 vars 作用统一，只不过这里的 vars 示意目录。）

files/main.yml：role 部署时用到的文件。

templates/main.yml：role 部署时用到的模板。与 Ansible 模块中的 templates 作用统一，只不过这里的 templates 示意目录。）

meta/main.yml：role 应用到的元数据。

在每个角色中必须蕴含至多一个这样的目录，当然咱们能够省略角色不应用的任何目录，然而每个目录下的 main.yml 文件是该目录的入口文件，Ansible 读取时会默认查找该文件。所以这个 main.yml 文件不能省略。

其次，存储和查找 roles。

上文咱们曾经理解到了一个 role 的外部目录构造，然而这远远不能满足理论生产的需要。在文章的开始局部咱们也以一个大数据我的项目为例，往往须要部署 Flink、Hadoop 等多个组件。这每一个组件都能够看做是一个 role。那么 Ansible 是如何查找 roles 的呢？

默认状况下，有 2 种形式：

在 Ansible 的公布我的项目中，创立一个叫做 roles 的目录。

默认状况下，Ansible 会主动查找 /etc/ansible/roles 目录下的 role。

举个例子，咱们要应用 Ansible 创立一个公布大数据“全家桶”的我的项目 bigdata，该我的项目下要蕴含 Flink、Mysql、Hive 这 3 个 role。那么 bigdata 这个我的项目的目录构造大抵如下：

➜ bigdata tree -L 3
.
└── roles

├── flink
│   ├── defaults
│   ├── files
│   ├── handlers
│   ├── meta
│   ├── tasks
│   ├── templates
│   ├── tests
│   └── vars
├── hive
│   ├── defaults
│   ├── files
│   ├── handlers
│   ├── meta
│   ├── tasks
│   ├── templates
│   ├── tests
│   └── vars
└── mysql
    ├── defaults
    ├── files
    ├── handlers
    ├── meta
    ├── tasks
    ├── templates
    ├── tests
    └── vars

很显著能够看到 roles 下的 Flink、hive、Mysql 的子目录构造就是上文中提到的八大目录。

ansible-galaxy
疾速创立 Role

从上文可知，每创立一个 role 都必须至多含有八大目录之一。所以 Ansible 中已内置了一个命令行工具 ansible-galaxy 疾速创立 role 的八大目录，加重咱们的工作量。

假如该 role 名称是 flink，用如下命令生成相干目录：

ansible-galaxy init flink
应用 tree 命令看到 ansible-galaxy 生成的目录正是 role 所要求的规范的八个目录。

➜ tree flink
flink
├── README.md
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── tasks
│ └── main.yml
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars

└── main.yml

ansible-galaxy init 其余几个实用的参数：

ansible-galaxy init -force role_name，默认状况下创立的 role 与当前工作目录下存在的文件重名的话，会抛出异样。应用 -force 选项会强制创立 role 目录，并对 role 目录下重名的目录或文件进行替换。

ansible-galaxy init –role-skeleton=/path/to/skeleton role_name，应用过 Maven 的同学应该晓得，Maven 反对以其余我的项目做骨架创立新我的项目。ansible-galaxy 同样反对该性能，以 /path/to/skeleton 门路下的 role 为骨架，把所有的文件都进行拷贝来创立新的 role。

Galaxy：role 在线分享社区

此外与 Docker Hub、Grafana Dashboards 相似，Ansible Galaxy 也有一个在线社区 Galaxy[https://galaxy.ansible.com/home]，下面有开发者分享的各种曾经开发好的 roles。不便咱们搜寻现成的 role 下载，也能够上传本人开发的 role 到 Galaxy。

下载或上传 role 到 Galaxy 网站，同样须要应用命令行工具 ansible-galaxy。默认状况下 ansible-galaxy 调用的 Galaxy 服务端的地址是 https://galaxy.ansible.com, 能够通过 -server 选项或在 ansible.cfg 文件中重新配置 Galaxy 的地址。

下载 roles

下载 roles 的语法模板是：

$ ansible-galaxy install username.role_name
默认状况下 ansible-galaxy 会把 role 下载到环境变量 ANSIBLE_ROLES_PATH 中，ansible-galaxy 提供了参数 –role_path 指定 role 下载的地址。

ansible-galaxy 其余命令速览

ansible-galaxy search elasticsearch，查找 Galaxy 网站中的 role elasticsearch

ansible-galaxy info username.role_name，查看 username.role_name 的详细信息

ansible-galaxy list，查看已装置的 roles

ansible-galaxy remove username.role_name，卸载装置的 username.role_name

ansible-galaxy login，登录 Galaxy 网站

整体布局：Suit is best
如果你保持读完上述局部，那么你必定对于如何应用 role 了然于心，简略来讲就是以后 Ansible 利用下须要存在一个叫做 roles 的目录。接下来咱们聊聊 Ansible 利用下除了 roles 目录外，其余目录该如何布局呢？Ansible 最佳实际官网文档 [https://docs.ansible.com/ansi…] 中是这样倡议的：

Your usage of Ansible should fit your needs, however, not ours, so feel free to modify this approach and organize as you see fit.

One crucial way to organize your playbook content is Ansible’s“roles”organization feature, which is documented as part of the main playbooks page. You should take the time to read and understand the roles documentation which is available here: Roles.

Ansible 整体的目录构造没有一定之规，适宜你的以后需要就好。然而 Roles 这个概念至关重要。

良心的 Ansible 官网在 Github 上开了一个我的项目 ansible-examples[https://github.com/ansible/an…]专门用来收集优良的最佳实际。大家能够依据理论需要排汇借鉴，上面我分享一下我罕用的我的项目布局：

.
├── Makefile
├── README.md
├── deploy.retry
├── deploy.yml
├── files
│ ├── apache-maven-3.8.3-bin.tar.gz
│ ├── apache-zookeeper-3.7.0-bin.tar.gz
│ ├── flink-1.14.0-bin-scala_2.11.tgz
│ ├── hadoop-2.7.5.tar
│ ├── hadoop-3.3.1.tar.gz
│ ├── mysql-connector-java-8.0.26-1.el7.noarch.rpm
│ ├── mysql-connector-java-8.0.26.jar
│ └── openjdk-11.0.2_linux-x64_bin.tar.gz
├── inventories
│ └── hosts
└── roles

├── flink
├── hadoop
├── hadoop3
├── hive
├── java
├── linux
├── mvn
├── mysql
└── zookeeper

Makefile，用来封装 Ansible 的发布命令

deploy.ym，是执行 Ansible 命令时的入口文件

files，用来寄存 role 相干的部署包，个别体积较大，不会应用 git 进行版本治理。

inventories，用来治理部署机器。

roles，用来部署的组件。从下面的目录可知，以后次要是用来部署大数据相干的组件。