2021年のAnsible

私は、よくAnsibleを好む、と言われます。
実はAutoMation Platformとして一番使い勝手が良いので使ってるだけで
そこまで拘りはないのですが、愛着というものは湧くもので（ツンデレ）
少しAnsibleって何だろうって事を書いておきます。

間違っている所があれば、その事を教えてください。
多少は詳しいつもりですが、実は全然そんな事ないかもしれません。
丁寧なマサカリは歓迎です。

Ansible とは

2012年に作られた、シンプルなIT自動化プラットフォームです。https://github.com/ansible/ansible

Ansible is a radically simple IT automation system. It handles configuration management, application deployment, cloud provisioning, ad-hoc task execution, network automation, and multi-node orchestration. Ansible makes complex changes like zero-downtime rolling updates with load balancers easy. More information on the Ansible website.

よく、Ansibleを構成管理の為のツールという文脈で
紹介される事があります。
https://ja.wikipedia.org/wiki/Ansible_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)
wikipediaにもそのように記載されてますね。
これは全くの間違いなのですが、多少は仕方ないでしょう。
RedHatのページにもそういう紹介をされている事がありました。
今はきちんとIT自動化ツールと紹介されていますね。
https://www.redhat.com/ja/technologies/management/ansible
（今見て少し驚きました）

もしかしたら、今Ansibleを自動化ツールと言わず構成管理ツールと思っている人は非常に特殊な間だけインフラエンジニアだったのかもしれません。
なぜなら、そのような期間も一時期存在したからです。

最初、Ansibleはただの並列可能SSHのAPIとして存在しました。

Update README.md to reflect that this is a tool, not just an API. Th窶ヲ ツキ ansible/ansible@c8fe53c

2012年2月24日のこのコミットで説明されてますね。

この時、構成管理 or デプロイ用のツールになりました。

そして、自動化プラットフォームになったのが、このコミット。
Ansible 1.8の時ですね。

Update README.md 揃 ansible/ansible@56b9039

Ansible is a radically simple IT automation system. It handles configuration-management, application deployment, cloud provisioning, ad-hoc task-execution, and multinode orchestration - including trivializing things like zero downtime rolling updates with load balancers.

このコミットは2014年9月29日。
なので、この2年半の間は構成管理＆デプロイシステムと呼べましたが
今は”IT自動化プラットフォーム”がAnsibleとなります。

Ansibleの自動化

とはいえ、Ansibleの自動化が構成管理システムとして
相性が良かったのも事実です。
それは、Ansibleエンジンの仕組みが実行稼働中に設定を変えたり
少しの設定でSSHを介して新規サーバの構築に向いているからです。
それを何故か、を簡単に説明します。

まず、Ansibleは実行すると、私の知っている多くの状態で、factとinfoと呼ばれる "情報" を集めます。
そして、Ansibleの実行タスクで行われる定義……これは殆どの場合で一部例外はありますが、と比較をします。
そして差分を比較して、違いがあればokを、変更があればchangeを、何かしらのエラーがあればerrorを返します。
この仕組みはコンテナの中以外での仕組みにとても良く利用出来たのです。
逆を返せば、コンテナ内部で持つポータビリティとは
これと全く逆のアプローチになります。
（しかし、コンテナ内部以外……コンテナの運用サーバやコンテナのユーザ管理には未だに有効と思っています）
また、Beyond the Twelve-Factor Appなどにも非常に親和性が高く、運用が広まったのでしょう。

ここまで読んで頂いた貴方には伝わったかもしれないのですが、Ansibleは構成管理だけのものではないのです。
（もちろん構成管理で使われるケースがとても多いのですが）
以前業務ではAWSのIAMの管理をしていたり（Cloud Provisioning）Jenkinsの設定が複雑になっているタスクをjinja2で数百task作った事などもあります。（私の過去記事で恐縮ですが）

Jenkinsのジョブをまじめにいい感じに管理してみた（Ansible編） - Qiita

Jenkinsのタスクを手で数百を設定するなんてしたら発狂する上に絶対ヒューマンエラーを起こすのですが（そもそも手でタスク定義する事をしないと思いますが）Ansibleでできる事がわかったのでまぁ非常に短期間で終わりました。（その時は今より詳しくなかったので調べつつではありましたが）

Ansible のメリット

大きく分けて2つあると思います。

一つは冪等。
これは、Ansibleが持つ自動化の仕組みから必然と生まれるもので、何回実行しても同じ結果になる事です。
これはAnsibleの自動化エンジンの仕組み上必然なのですが、自動化ツールで冪等が得られるのは大きい事だと思っています。
また、これは関数型言語の副作用とも近いなと感じていて、綺麗にかけば安全でとてもシンプルな自動化を行えると感じているからです。

もう一つは状態を持たない事
状態を持たない事の利点はBeyond the Twelve-Factor Appにも度々出てきますので、割愛しましょう。
私がAnsibleで特に気に入っているのはこの点ですね。
ただ、これにはデメリットもあります。
それは、速度ですね。自動化実行時に取得するので、モジュールによっては遅かったりオーバーヘッドは必然的に発生します。
それでも、そのデメリット以上に状態を持たないというのは利点になっていると感じています。

Ansible のこれから

最近少し諸事情により終えてなかったのですが、益々Ansibleの範囲は加速しそうです。
なぜなら、今まではAnsibleでできる事が多すぎてPRが非常に多くさばけていない状態が続いていました。
インフラエンジニアたるもの、自分が考えた自動化を使いたいですもんね。
しかし、PR投げたものの返事がなく、思い切ってIRCに突撃して拙い英語で「今PRどうなってる？」って聞いた所「なんか通知機能がバグってるから教えて、どれ？」みたいな感じになってました。
完全に人的なリソース不足ですね。
まぁ、その時はIBMがRedHatに買収される前のAnsibleがRedHatに買収される前の話だったので、今は多少違うかもしれないのですが、PRの処理に時間がかかっているのは事実だと思います。

そこで、ansible collectionという機能が入り、今までのモジュールは大半が別のリポジトリに分離されました。
旧クラウドプロビジョニングのAWSモジュールであれば、以下ですね。
https://github.com/ansible-collections/amazon.aws
これによってansible本家のコントリビューターではなくなってしまい自慢できる事が一つ無くなってしまったのですが、ansible-lintの方は残っているのでまだ少し詳しいフリが出来そうです。

さて、これで本家とモジュールが分離され、出来る事と品質が向上するのでしょう。
個人的にはクラウドモジュールに興味があったので、そのコントリビューターを目指すかなぁ。