为什么使用Ansible和Serverspec而不使用ansible_spec？

2 年 ago

科, 雅

1 minute

你好。我是 @katsuhisa__。
这篇文章是“Ansible Advent Calendar 2017”的12/5(星期二)的部分。

我将介绍我非常喜欢的ansible_spec。

这篇文章的目标读者

Ansible とServerspec をどちらも使用しているが、いろいろとつらみを感じている方

ansible_spec 是什么？

ansible_spec是一个Gem，可以共同管理Ansible配置文件和Serverspec配置文件。
是的，您无需将Ansible和Serverspec的不同方面分开管理。

如何分别管理Ansible和Serverspec？

现在让我们再次简要提及与引入ansible_spec相关的问题。我将简单地在流程中解释如果只是直接使用Ansible和Serverspec会发生什么。

让我们想象一下，在这里制作一个用于构建MySQL环境的Ansible Playbook，并通过Serverspec进行测试的情景。

创建 Ansible Playbook

如果超简单地制作，就会变成以下这样。

Ansible_sample
├─hosts
├─site.yml
└─roles
    └─mysql
        ├─handlers
        │  └─main.yml
        ├─tasks
        │  └─main.yml
        └─templates
           └─my.cnf.j2

我们使用hosts来管理目标主机，
并且使用roles/mysql目录来管理与MySQL环境构建相关的信息。

使用Serverspec来编写测试

如果我们也用非常简单的方法来制作的话，就会像下面这样。

Serverspec_sample
├── Rakefile
└── spec
    ├── www.example.jp
    │   └── mysql_spec.rb
    └── spec_helper.rb

这里使用spec目录下的子目录名称来管理目标主机，使用spec目录下的mysql_spec.rb来管理MySQL的测试代码。

如果在同一目录下管理Ansible和Serverspec会发生什么？

让我们将上述的两个文件夹合并到一个文件夹中进行管理。

Ansible_Serverspec_sample
├─hosts
├─site.yml
├─roles
│   └─mysql
│       ├─handlers
│       │  └─main.yml
│       ├─tasks
│       │  └─main.yml
│       └─templates
│          └─my.cnf.j2
├── Rakefile
└── spec
    ├── www.example.jp
    │   └── mysql_spec.rb
    └── spec_helper.rb

你对想做的事情感到有些难以理清构思吗？

只需要一个选项，原生中文改写以下内容：
目标主机为

Serverspec ➔ spec 配下のサブディレクトリ名で管理

必要に応じて個別に管理する必要がありますし、MySQL に関連するコードは個別に管理しなければなりません。

Serverspec ➔ spec 配下のmysqld_spec.rb で管理

必须在不同的目录下管理与MySQL相关的基础架构代码。

Ansible和Serverspec是两个不同的开源软件，所以很自然地他们的管理被分割开了。

使用ansible_spec的结果如下

让我们来看看使用ansible_spec有什么好处。它会变成这样。

ansible_spec_sample
├── hosts                        
├── site.yml                     
├── roles
│   └── mysql
│       ├── handlers
│       │   └── main.yml
│       ├── spec                 
│       │   └── mysql_spec.rb
│       ├── tasks
│       │   └── main.yml
│       └── templates
│           └── my.cnf.j2
├── Rakefile                    
└── spec                        
    └── spec_helper.rb

为了简化对与重复管理相比的解释，请省略部分文件内容。

一看就感觉清爽舒适啊，真开心。使用ansible_spec的话，

Ansible のroles 配下にServerspec のspec ファイルを置けるので、インフラコードを一元管理できる

这样，就有以下的好处。

不需要分散管理！太棒了！这就是最好的结果。

不使用ansible_spec派别的人在考虑什么？

正如上述，我决定（实际上是在发现它的瞬间就决定引入）使用 ansible_spec 的原因是因为世界上存在着许多不同主义思想的人。

那么，让我们最后来看看那些不使用的人是如何思考的。

如果本来就使用Ansible的话，那么不需要Serverspec吧？派

這是那些尊重 Ansible「fail-fast」設計理念的人們的意見，他們認為測試並不一定是必要的。
此外，如果在 Ansible 中已經定義了完成後伺服器的狀態，為什麼還需要用另一種基礎架構程式碼來管理呢？

只要有测试代码，就能为开发过程增添灵活性和便利性，这是我个人的观点。

手动测试派

我认为这些人和”刚刚解释的那种，你用Ansible干嘛还要用Serverspec呢？”的人有着相同的基本思想，他们认为既然已经在Ansible中定义了服务器的最终状态，为什么还需要编写测试代码呢？

只是，为了确认一下，因为不放心，不如干脆手动做好了吧？个人感兴趣，在服务器数量增加时，想了解一下您是如何做出适应性调整的。如果有手动测试派的话，请告诉我。

我属于使用Ansible的assert模块的一方。

这个我从来没有用过，不知道怎么样。如果有人知道的话，请告诉我。我经常看到写起来很难的意见，不知道是不是这样。

比重复管理更重要的事情派

对于那些不愿意接受ansible_spec的基本限制条件（尽管它们非常有限），他们不希望与他们本来想要的测试方式产生分歧。详细内容略去。

然而，我感觉大部分的批评都可以通过改变site.yml和Playbook的写作方式来解决。如果你有像”烦人的小子，那根本不是这个原因”这样的理由，请务必告诉我。

总结

Ansible_spec非常棒。

由于我非常喜欢这个Gem，所以我希望让更多的人使用它，并希望通过各种人的OSS贡献来让ansible_spec长久存在。因此，我写了一篇文章。当我发现具体的改进方案或错误时，我也想提交PR。（➔恰巧我今天发现了一个，所以我提交了PR。➔前几天已经合并了我的PR。）

非常感谢您的阅读！我也期待着其他2017年Ansible Advent Calendar的文章。

@katsuhisa__ ：请用中文重新表达以下内容，只需要给出一个选项：

@katsuhisa__ ：题目