Ansibleのアーキテクチャー: 構成管理を超えて¶
すでに2月ほど経っていますが、2013/11/29にAnsible WorksのCTOであるMichael DeHaanさんが、 Ansible’s Architecture: Beyond Configuration Management という記事を書いています。
この記事はAnsibleのアーキテクチャを説明するのにとても良い記事だと思いましたので、DeHaanさんの許可を得て、翻訳したものを公開します。
ただ、いかんせんこの人は一文が長いのと言い回しが詩的で意味が取りにくいのとで、うまく訳せていないところが多々あります。間違っている箇所がありましたらご指摘ください。
Ansibleのアーキテクチャー: 構成管理を超えて¶
Ansibleがなにものなのか、というあまりよろしくない議論があり、とても奇妙 だったので、ここでAnsibleとはなんなのかを分類しよう。
Ansibleはよく"構成管理(configuration management)" システムだと紹介されている。しかし、これは本当に正しい説明なのだろうか？
生粋の 構成管理 システムは、遠隔マシンを厳格なモデルで定義する。これらは15年前に始まったCFEngine 2から派生した。PullモードやPushモードで動いたり、管理されるマシンがそれ自身の変数(私達は"facts"と呼んでいる)でチェックするなどして、モデルはそのサーバーがどうあるべきかを決定する。エンドユーザーは自動化はとても歓迎するが、構成管理やそのアーキテクチャーについては別に興味がない。だいたいにおいては、ファイルを送ってサービスがちゃんと動いているかを確かめるだけだ。コンパイルするアーキテクチャーは構成管理にとって良いが、DB、Webサービス、アプリケーションなどを持つ多段のアプリケーションに取っては柔軟性に欠ける。最近の分散アプリケーションをデプロイする典型的なケースでは、多くの人々は他のアプリケーションデプロイツールを使い、他の自動化ツールを起動する。古典的な構成管理 -- "/sbin/service foo start"の代わりに "サービスが動いて起動時に立ち上がること"という宣言的な リソースモデル 、つまりサービスの実装を隠蔽するモデル -- はもちろん正しく動く。 Ansibleはこれらを持っている。たくさん。 170以上のモジュールがcoreに付属しており、 「バッテリー同梱(batteries included)」 だ。モジュールは、あなたの 道具箱 の中にあるツールのようであり、 Ansibleは6 foot tall NASCAR-garage-worth ツールボックスのようだ(訳注: このたとえちょっと良くわからない)。
対照的に、 アプリケーションデプロイシステム (CapistranoやFabricは古典的な構成管理ユーザーにはとても有名だ)は、一連の対象に対する操作を記述したスクリプトを与えて、そのとおりに実行する。スクリプトは、抽象化された(sshなどの)接続機構と豊富な機能を通じて、リモートのマシンを並列で実行する。リモートシステムの硬直したモデルを単にコンパイルするだけではない、システムとサービスの間にある溝を飛び越える機能は、ボックス(訳注: 各サーバーのことを言ってると思われる)の間の溝を超えてアプリケーションを送ることを可能にする。しかしながら、典型的なこれらのツールは、構成管理システムで必要とされている 宣言的な抽象化 の機能がない。でも、Ansibleは宣言的なリソースモデルを使っているため、構成管理もアプリケーションデプロイも同じように簡単に実行できる。また、データ志向の自動化言語(訳注:YAML)を使っているため、自動実行のルールをコードで実装する必要がなく、そしてソフトウェアプロジェクトを複雑化させる危険性もない。開発者にとって、Ansibleは構成管理のバックグラウンドを持つ誰かが書いたアプリケーションデプロイシステム、というようにおそらく感じるだろう。なぜなら、あなたのアプリケーションを自動化するための設定から、すべてのリソース -- git repo、サービス、設定ファイル、ロードバランサーなど-- を扱えるから。 スクリプトの問題はあなたが書いた「素晴らしい」ことそのままが実行されること、ではなく、ソフトウェアコードだ、ということだ。ソフトウェアのコードは、書くこととメンテナンスすることに努力が必要であり、読むのに大変になるほどに成長していく可能性がある。-- そして、壊れやすい状態を避けるリソースモデルを支援してはくれない。だからAnsibleはアプリケーションデプロイシステムのようなものを実行するために、自動化のプロセスをRubyやPythonを使って書くのではなく、構成管理の世界から持ってきた信頼できる宣言的モデルと抽象化レイヤーを使うことにしたのだ。
さて、両方について語ったところで、２つを一緒に持ってこよう。私達は 構成管理 と アプリケーションデプロイ を分けることはやや恣意的だと信じている。 -- 実際の世界では、最終的なゴールはビジネスアプリケーションをデプロイすることだから。そのため、この境を曖昧にしている。みんなこの方向を考えている。私達は普段 "構成管理" ユーザーグループを持っておらず、 DevOps と自動化ユーザーグループを持っている。これがアプリを展開するすべてであり、製品でハッピーになることだ。Ansibleは構成管理ツールでもありアプリケーションデプロイツールでもあります。 両方の世界のいいところ を取り込み、それぞれのシステムのレガシーな面を取り除いてハイブリッドなソリューションを実現している。
さらに オーケストレーション (Orchestration) というコンセプトがある。これは多くの異なる物事に対して使われている言葉で、私はもう少しやわらかい言葉が必要だと思っているが、しかし、他に適切な言葉がない。これは文脈によって以下のまったく異なる物事のどれかを意味している。
コマンドをリモートシステムに送りつける基本的な機能
リソースに対する指示をリモートシステムに送りつける基本的な機能
構成管理内の自動化されたものを実行するトリガー
他のシステムの前に、そのシステムがどう構成されているかを指示する
例えば、ITプロセスの書くステップに依存するパイプラインなど、多くの目的に使えるワークフローシステムを構築する機能
Ansibleはこれら全部をできる。もっと言うと、Ansibleは上記すべてをできるだけでなく、最後の種類 -- 多くの目的に使えるワークフロー -- をテキストベースで自動化し、構築できる。あなたはおそらくグラフィカルなITプログラム(例えば Cisco Process Orchestrator のような)というパワフルだけど古くて大きすぎるツールを使っており、テキストエディタでとても簡単に扱えるソースコード管理システムのベストプラクティスを用いる、最近のDevOpsには合わない。
多くの人々が Orchestrationはいくつかの接続レイヤー(glue layer)の上に構築された、すでにあるものごとに対して指示するというコンセプトだと思っている。Ansibleにとって、 Orchestrationはすべての心臓部分である。 -- あなたのコンピューターリソースとサービスをオーケストラのように扱う。 バイオリンと組み合わさった金管楽器セッションを演奏し、弦楽器を演奏し、第一クラリネットのソロに戻ってくる。これらを記述することはとても自然である。
この理由により、Ansibleは 即時のローリングアップデート のような継続的デプロイに秀でている。 -- 物事をとっても簡単にするために多くの機能を言語に焼き付けている。私達は "host loops"や、"delegation"、ローリングアップデートなどのコンセプトを当初からのコンセプトの中に含んでいるし、また、これらすべては言語の第一級(first class)である。Ansibleプロジェクトを立ち上げることになった時の一番最初のユースケースは、会議室の誰もがローリングアップデートをできるようにする、というものだった。Ansibleはページ半分以下のテキストで、ボタンの1クリックでローリングアップデートができる。
Provisioning についても忘れてはいけない。 -- このフェイズはソフトウェアをデプロイするときに使われるが、もっとよく使われる場面としては、ハードウェアを含む計算機資源がない、あるいは変更する必要がある場所にサーバーを要求するというときだ。これはつまり、基盤システムの設定やビジネスアプリのデプロイの前に、システム自体をデプロイする必要がある、ということだ。AnsibleはクラウドProvisioningのモジュールをたくさん持っている。これはすでに存在するものに対して動く、構成管理アーキテクチャでは実現が難しい機能だ。一方、Ansibleは柔軟性があり、Provisioningは簡単にできる。結果として、多くの種類のクラウドサービスを管理する、40のモジュールを持っている。Amazon Web Service上のS3やElastic Load Balancerから始まり、Rackspace Cloudにisolated networkを作ることまでできる。あなたはこの機能をAnsibleに必要としないかもしれないが、多くの人々は必要としている。私達のユーザーの多くは、クラウド業者上にサービスをデプロイする方法をシンプルにするためにAnsibleを使っている。
今まで述べてきたことをすべて網羅する方法にどうやってたどり着いたかって？ -- 偉大な構成管理システムになるために、 Ansibleはたったひとつのユースケースを解決するために作られたわけではなく、また、革新的なプロセスの結果できたものではない 。Ansibleは最初から構成管理システム、アプリケーションデプロイシステム、ワークフローに基づくOrchestrationシステムという３つを合成した、ハイブリッドなアーキテクチャーとして作られた。そして、これらのシステムに対する豊富な経験に基づいている。 -- 以前のRed Hatでのいくつかの自動化システムなどがあるが(訳注: DeHaanさんは以前RedHatにいた)、実際のところ、IT自動化はまだ解決されていない問題だ。Ansibleが採用したハイブリッドなアプローチは任意のスクリプトをAnsibleで実行でき、CMSで述べている、モデルと1-system-at-a-timeなコンパイルアーキテクチャーを意味している(訳注:この文意味が取れない)。あなたは任意のbash scriptからはじめて、システムトポロジーの素晴らしいモデルへと徐々に移っていける。一方、構成管理システムからOrchestrationシステムに移行するのは簡単ではない。私達が作ったものは Orchestrationをするもの(Orchestrator) であり、すべてをそこにくっつけている。 -- どんな任意のITワークフローでも自動化することはAnsibleの魂の一部である。
もちろんこれで終わりじゃない。私たちは 全てに対してエージェントを必要としない アプローチも採用している。これは安全なトランスポートであるSSHと(SSHを鍵交換に使う)accelareted modeのようなユニークな機能の実装によって実装されている。エージェントを必要としないアプローチは、リモートノードに対する要求を少なくし、必要な人にだけ権限を与えるというビジネスに対する安全性を気にする顧客に対して、安全な push-by-default なアーキテクチャとなっている。これがなぜAnsibleが Big Dataの領域においてポピュラーになりつつあるかの理由だ。維持管理、安全性、管理アーキテクチャーについて考える必要がない、というのも大きなボーナスポイントだ。私達は暗号や自家製の安全レイヤーを発明したり管理することに興味がない。そのため、最も安全で信頼でき、多くの人々が製品に使っているSSHを使っている。
最後に、私達は 自動化におけるコンピューターサイエンスの領域を少なくしたい 。私達はたくさんの人々が実際のアプリケーションの複雑なコンセプトに辟易していると感じている。私達は 自動化ツールを忙しい人々のために作りたい と願っている。私は開発者だが、複雑なデプロイシステムを簡単に扱えるようにしたい、というアイデアに夢中になっている。Ansibleの言語はワークフローのOrchestratorに多くの影響を受けている -- 基本的な機能をたくさん (現在coreには170以上のモジュールがある)用意し -- 高度な、とても簡単に(loop、condition、role、role dependenciesなどを使い)基礎的な機能を結びつけて大きな機能にするという部分だ。
全てがテキストベースだから、どういうことをしてきたかという確認できる履歴を持つことができる。しかし、確認できるシステムで動作させるためには、特に明確な言語を使う必要がある。-- これがAnsible は一行一行のdiffが読める、100%純粋なデータフォーマットを使っている理由だ。あなたが自動化部分を書いたのではない場合でも、あなたのインフラの振る舞いに対して、その履歴を読んでなにが起きているかを知ることができる。Ansibleのアーキテクチャの機能はこれを可能にする。私達は 言語が一番大事 だと考えている。なぜなら、あなたが毎日触るインタフェースだから。
Ansibleは 多くの用途に使える自動化パイプライン である。 マウスでクリックする世界でなく、100%純粋な機械が読める世界で、ソース管理された自動化が生きているデータ志向のパースペクティブで作られている。私達が作ったハイブリッドなアーキテクチャーだけでなく、 Infrastructure-as-codeというアイデアを忙しいITショップがこれ以上コードを扱わなくてすむようにしている。私はこれを"ハイブリッド DevOps"と呼ぶのには抵抗するが、これが私のインフラ自動化に対する考えだ。
私の考えはこうだ。 -- 人々やチームが毎日のサイクルで使う道具の、すべてのものから学ぼう。 -- そして、ツールと 実際に起きること の間を掘り下げていく。 "構成管理"と"アプリケーションデプロイ"といったなにかではなく、アプリケーションをドアの外に連れ出すもの、私があえて言うなら、 ... すべてのものを自動化する 。
翻訳をおえて¶
つたない翻訳ではありますが、
構成管理
Provisioning
Orchestration
という3つすべてをできるように設計されていることが分かると嬉しいです。
Comments
comments powered by Disqus