最近的Ansible使用方法（从2017年底到2018年初）

Ansible先生化

最近大约半年，我一直只写Ansible。完全没有写产品代码，完全变成了Ansible老师傅。

我正在创建用于主要进行环境构建的Playbook/Role。

在做了一些事情之间，我进行了几次重大的方向转变，现在感觉有些找到了轨道，所以我打算整理一下自己的想法并把它写下来。

在此之后，我们根据以下前提进行描述。

• Ansible 2.4

 

Ansibleを実行するhostはAmazon linux

文件夹结构

目录结构基本上遵循了Ansible的最佳实践。不过，由于过于严格会很麻烦，所以我们实际上是按照以下方式进行的。

├── ansible.cfg
├── decrypt.sh
├── encrypt.sh
├── hosts
├── playbooks
│   ├── common.yml
│   ├── ap-server.yml
│   ├── database.yml
│   ├── deployer.yml
│   └── batch.yml
├── requirements.txt
├── roles
├── run-test.py
├── site.yml
└── test

在playbooks中放置的playbook，都被包含在site.yml中，如果要实际执行，如下所示。

$ ansible-playbook -i [対象ホスト] site.yml

此外，基本上我們將給每個任務都設定了標籤，這樣您可以使用“-t”選項，只執行特定的任務/角色。

group_vars策略的中文翻译选项：团体变量策略。

当前的项目有一个非常多环境（包括生产和验证环境）的特点。因此，把所有代码写在一个文件中是相当困难的。

目前情况结构如下所示。（以下hosts的部分与前述相同）

├── ansible.cfg
├── decrypt.sh
├── encrypt.sh
├── hosts
│   ├── prod
│   │   ├── prod1
│   │   ├── prod2
│   │   ├── prod2
│   │   └── prod2
│   └── verify
│       ├── verify1
│       ├── veirfy2
│       └── verify3
├── playbooks
│   ├── common.yml
│   ├── ap-server.yml
│   ├── database.yml
│   ├── deployer.yml
│   └── batch.yml
├── requirements.txt
├── roles
├── run-test.py
├── site.yml
└── test

通过采用这样的结构，旨在实现以下效果。

• 環境毎のinventoryを管理できる

 

• 環境毎、group毎の変数管理が（ある程度）わかりやすい

 

• 似た環境でもあえて分けることで、環境毎に変更内容が独立させられる

group_vars以下がいい感じに肥大していくのとトレードオフですが。。。

使用保险库

我之前已经使用过Ansible，但没有使用过ansible-vault。然而，这次如果不使用它，管理工作可能会变得麻烦。

• 環境が多い上に、諸事情でRDBのパスワードをAnsibleで持っておく必要がある

 

• SSHでのアクセスが公開鍵ではなく、パスワード認証（・・・）

 

いくつか作成するユーザーのパスワードを保存する必要がある

当ansible-vault的目标文件过多时，会在变更时带来繁琐和耗时的问题，因此，我采取以下方式（去应对）。

# secrets.yml
---

secrets:
  user_secret_key: hogehoge

# main.yml
user_secret_key: '{{secrets.user_secret_key}}'

将所有的变量写在角色的默认值中

在role的范围内，如果需要传递任何类型的变量，务必要在 defaults/main.yml 中写入默认值。

• roleで利用する変数は defaults/main.yml を見ればわかる

 

defaults/main.yml に説明を書くことで、将来のドキュメントにもなる

后来，我们规定在使用“role”时，变量的命名必须以“role”的名称作为前缀。基本上，在除了基于meta的依赖设置的role之外，我们制定这样的规则是为了防止变量被覆盖。

由于这不是一个需要在项目外共享的角色，所以我们尽量让它们独立，避免刻意建立隐含的依赖关系。当然，有一些角色之间存在实质性的依赖，但我们在playbook中明确地进行了记录和覆盖。

可以让Jenkins（或其他方式）执行ansible-playbook。

为了避免在个人电脑上执行Ansible本身（当然除了创建角色/剧本时），我们采取了措施。

在解决这个问题的过程中，我们迎来了受大家喜爱的Jenkins叔叔的登场。我们将ansible-vault的密码文件配置到Jenkins中，并从Github拉取相应的仓库，然后执行ansible-playbook。此外，我们使用构建参数和流水线来实现以下功能。

• stage（本番・検証）を選択できるように

 

• 対象の環境を選択できるように

 

実行するtagを指定できる。Pipelineのinputを使って、実行対象のtask一覧を確認してから実行させるようにしている

因为大多数人都使用Windows PC，所以选择通过Jenkins执行Ansible，而不是选择其他繁琐的方法，这样任何人都可以执行并查看执行历史。

如果能更加仔细地做的话，或许考虑引入Ansible Tower之类的工具会更好。但是，目前只是在环境构建方面使用，所以这样已经勉强应付了。

使用Docker进行角色测试

由于Ansible在其官方上提供了用于与Docker连接的插件，因此我们可以利用这个插件在Docker + Amazon Linux镜像上进行测试。

---

- hosts: "[コンテナの名前]"
  connection: docker
  gather_facts: False
  roles:
    - role: ...

Docker容器需要进行预先启动。我认为只要使用docker模块，测试playbook就可以完成，但是由于清理工作等不方便，所以我们使用脚本来执行。

我正在创建一个脚本，以便在执行角色之后，使用Testinfra来运行测试用例。

当你真正尝试一下，你会发现可以很好地进行测试。因为Ansible本身要求具有幂等性，所以你可以轻松地编写测试。

顺便一提，我们使用的是Testinfra而不是Serverspec，原因是目前不能使用Ruby（但Python是可以的）。

改善之路漫长。

我正在做各种各样的事情，但个人而言，还不太满意。换句话说，角色的表述方式缺乏统一感，有很多地方变得含混不清，所以需要改进这些地方。

由于将环境搭建全部交给了Ansible，并且可以从Jenkins进行执行，因此我们得以顺利进行。

• 誰かがいないと動かせない、ということが激減

 

新しい環境が増えても、group_varsだけ確認すればOK

由于项目的特性以及应用程序的构建方式，环境配置变得非常复杂。因此，这让我感到非常感激。

然而，因为还有一些地方保留着手工制作的温暖感，所以我也想把这些部分全部卷起来。

请参考以下网站

规划角色、清点库存和制定指南

在Ansible的清单文件中切换阶段

在开始使用Ansible之前，我想要了解最佳实践的目录结构。

如何在ansible中切换执行目标