把知识玩起来：Ansible（一）快乐的入门

问渠那得清如许，唯有源头活水来。

问题的出现

随着现在互联网公司业务越来越多，流量越来越多，需要越来越多的服务器提供计算，存储等服务资源。

很多公司的服务器都有成千上万台。那么问题来了，如何管理，运维这些机器呢？一台一台的部署显然是费时费力。因此 ansible, slatstack, puppet 等工具应运而生。本文主要讲述 ansible 以及如何把 ansible 玩出花来。

架构

Ansible 的架构图如上，这个图很经典，几乎所有讲 Ansible 的文章都会有。文本的角度与常见的 ansible 的教程不同。大多数人喜欢上来扔出一个架构图，然后开讲。但这不是我的美学。我的设计方法论为 期望与边界-概念与问题-逻辑与组合 详见： https://xie.infoq.cn/article/41a98604994203e3e5c014e9b

依照这个方法论的指引，我们看一下如果我要做 ansible 应该怎么设计？然后再看 ansible 的作者是否和我设计的一致。

根据方法论，第一步就是描述期望与确定边界。有点尴尬的是，我好像不完全清楚 ansible 的蓝图是什么，没有关系，看一下 ansible 的 github 上的 readme。我们大体可以得出期望：需要一个工具，在中心节点上操作，可以一次运维多台机器，可以积累运维经验。

第二步，提出问题。描述完期望后，看一下我们会面临什么问题。1. 采用那种模式链接机器？agent 还是 agentless 或者称之为 C/S or Not，2. 如何下发命令。3. 如何积累运维经验。4. 如何提供扩展功能。从简单，快速上手的角度设计，使用非 agent 模式，即无需提前在机器上安装任何程序，直接链接机器执行运维命令这里剧透一下（saltstack 使用 agent 模式，ansible 默认使用非 agent 模式，dao 使用 agent 模式）。一般使用 ssh 下发命令。如何积累运维经验？暂时还没想法往下看。

第三步，抽象概念。整个事情，对待问题中的各个实体，我们使用抽象的概念来描述。我们会面对机器，机器上可能有各种 tag 来执行对应的运维脚本。所以抽象出 Inventory。执行节点需要和其他机器沟通链接，那么抽象出 Connnect Plugins 一层（ssh 只是链接方式的一种）。为了执行复杂的任务，用 playbook（剧本）描述（软件工程常用的几种命名方式 1. 电影系列，常见的 movie， playbook 等 2. 厨房系列, cook 等）。 代表机器的 Inventory，代表机器之间连接的 Connection Plugin，代表机器执行剧本的 Playbook 构成了 Ansible 的三角式。

后面的 Core Modules 和 Custom Modules，Plugins 包括 task, roles，vars 等概念，都是对 Playbook 的细化。使得 ansible 更加灵活，更方便积累运维经验。

概念

如上图所示 Ansible 的架构图中有 HostInventory, Playbook， CoreModules， Custom Modules，Plugin，Connection Plugins 的概念。

Inventory

Host Inventory 是配置文件，用来告诉 Ansible 需要管理哪些主机。并且把这些主机根据按需分类。

172.168.151.150aserver.example.orgbserver.example.org

playbook

ansible 可以不使用 playbook 运维机器，但是官方推荐使用 playbook，可以理解为一次运维的剧本。anible 会照着剧本，找到对应 host 的 inventory，默认使用 ssh connect 链接机器，开启他们的表演。为了丰富功能 ansible 提供了多种 module。

module

module 是为了丰富功能，不仅可以执行 shell 命令，也提供了更丰富与功能，比如 apt，template，service, copy, docker 等功能。Core Module 和 Custom Module 区别是一个是 Build-in，健壮的 module，一个是需要额外安装，没有不够健壮的 module。

task

为了丰富语义，ansible 使用 task 为单位执行任务。通常都是在 playbook 中 Triger task。

为了让 ansible 更方便的积累运维经验，playbook 中可以引用别的 playbook，后来觉得这种方式也不够低耦合高内聚，进而引出了 roles，采用以 roles 为单位，playbook 不相互调用而是 playbook 调用 roles。

roles

运维经验积累的核心单位，在 playbook 引入后会默认调用 roles/XXX/tasks/main.yaml。roles 中包含 vars, default, handler，template 等文件。

vars

为了让 ansible 更加灵活，在 playbool，inventory 上还引入了 vars，可以更加方便的在 playbook 和 inventory 中引用变量

ansible 中设计比较漂亮的点是，ansible 提供原子能力，各个概念之间是正交的，不耦合，比如 vars 概念贯穿 inventory, playbook。比如相互调用的 Include，在 playbook 和 roles 都适用等。

本章只是 ansible 的一个小入门，通过我的设计方法论分析 ansible 的期望，其中的概念，但是没有涉及到如何把 ansible 玩出花来。

我们可以使用 ansible 部署服务，比如 mysql, 或者运行 docker container。 但是 ansible 站在部署运维的角度看待机器和部署服务的，能否使用 ansible 达到 k8s 那样部署服务呢？

敬请期待下一篇：《把 ansible 玩成 k8s》