第2回「システムを作るコンピューター」
Tweet
前回のコラムで抽象的に「自動化システム」と表現しました、自動化に使うツールについて詳しく説明します。
自動化では「自動化システム」で「プログラム」を動かすと書きました。つまり「プログラム」を動作させるハードウェアのような位置付けになります。一般的にハードウェアが異なればソフトウェアも異なるように、「自動化システム」が変われば、その上で動作する「プログラム」も変えなくてはなりません。ハードウェアそれぞれに得手不得手があるように、「自動化システム」もそれぞれに得手不得手があります。よって利用する「自動化システム」を選ぶ時は、実現したい自動化の内容にマッチする「自動化システム」を選定するのが大事です。
「自動化システム」なんて構築するだけなのに、そんな機能に差が出るのか疑問に思われた方もいらっしゃる事でしょう。確かに基本機能はおおむね「どんぐりの背比べ」ですが、OSや開発言語の差異と似たような話で、同じ作業を実行する「プログラム」を書くのに、一方は数行で記述できるのに、もう一方は数十行記述しないと実現できなかったり、そもそも補助する機能が無いのでユーザー側で用意しなければならなく、労力が倍以上掛かったりするような事もあります。
では、具体的なツールを紹介する前に「自動化システム」に求められる機能を考えてみます。
「自動化システム」を初期構築と運用で使う事を考えた時、「プログラム」を時それぞれに合わせて作り替えていたのでは、あまりに効率が悪すぎます。初期構築の時に「あるべき姿」を定め、それに合わせて「プログラム」を作り、運用に入ってシステムに変更を加える時は「プログラム」に修正を入れる事で対応できるのが望ましいでしょう。
ここでもし同様の「プログラム」を一般的なスクリプトで実装したとして考えてみます。初期構築にて、あるパッケージの「インストール」、「設定ファイル作成」、「サービス起動」作業を実装したとします。運用に入って設定ファイルに変更が入る時、スクリプトを変更内容に沿って修正後、再度実行すると「インストール」作業から実行してしまいます。これだと既にインストールされているパッケージに対して上書いてしまい、環境を壊してしまうかもしれません。
こういった問題が起きないよう、「冪等性(べきとうせい)」という概念があります。冪等性とは「何度同じ操作をしたとしても同じ結果を得られる」というものです。例えば「abcというユーザーを指定の属性で作成せよ」という「プログラム」をあったとします。この「プログラム」を何回実行したとしても、「abc」というユーザーが指定の属性で作成されているという結果に変わりはないという事です。つまり先の例で言えば、パッケージがインストール済みならば「何もしない」のが望ましい動きになります。
ただ「自動化システム」がサポートしていても、全ての操作で冪等性を保証できる訳ではありません。代表的な例は外部コマンドの実行です。一般的に外部コマンドは何度実行しても常に結果が変わらない事を保証できません。つまり複数回実行すると、「あるべき状態」であったものを、わざわざ「修正を要する状態」に変更してしまう可能性があり、冪等性が保証されていない事になります。
このような冪等性が保証されない操作に対して、冪等性が保証できるよう実行前に「実行しても良いか」を判定し、必要が無ければスキップするような機構が「自動化システム」側に備わっているものもあります。
次にシステムでは一般的に、ある特定のOS単独使用であることは少なく、多くの場合は複数のOSが混在しているでしょう。OSが異なれば操作に使うコマンドやそのオプションが異なります。「プログラム」を作成する時、同じ操作は同じ「命令」でプログラミングできると、OS毎に別々の「プログラム」を用意する必要がなくなり、複数OS混在のシステムの場合はとても効率がよくなります。そのため「自動化システム」はOSの違いを吸収するための仕組みを持っている事が望まれます。
また「プログラム」を作る上で、システムから情報を取得してパラメーターを決定したり、挙動を変えたりする場面があるでしょう。そのような時にシステムから情報を取得する機能があり、また「プログラム」での読み出しが簡単にできる事が重要です。さらに個別の情報を管理格納し、簡単に読み出せる仕組みがあるのが望ましいです。
最後に求められる機能として、作業と作業の「依存関係」があります。例えばApache HTTPD Server(以下Apache)をインストールし設定する作業を実行しようとします。Apacheの設定をするためには、当たり前ですがApacheがインストール済でなければなりません。同様にApacheを起動するにはApacheの設定が完了してないとなりません。この場合、設定作業はインストール作業が完了している事に依存し、同様にApache起動は設定作業が完了している事に依存していると見ます。つまり「プログラム」では、この作業と作業の依存関係を記述できる事が求められるのです。
それでは構築、保守・運用のフェーズを自動化する代表的な「自動化システム」として、「Puppet」「Chef」「Ansible」の機能や特徴を下表にまとめます。
Puppet | Chef | Ansible | ||
---|---|---|---|---|
プログラム | 名称 | manifest(マニフェスト) | recipe(レシピ) | playbook(プレイブック) |
記述言語 | 独自のPuppet言語(外部DSL) | Ruby(内部DSL) | YAML | |
実行順序 | コンパイル時に決定されるため記述順通りにはならない | 基本的にプログラムの記述順 | プログラムの記述順 | |
環境依存性 | 抽象化レイヤーによりターゲット環境の違いをツール側で吸収 | ターゲット環境の違いをツール側で吸収 | 環境定義ファイル(Inventory)に記載、もしくはInventory自身の切り替えにより対応 | |
依存関係の記述 | 可能 | 可能 | 可能 | |
冪等性(べきとうせい)の担保 | 担保されている(コマンド実行など例外はある) | 担保されている(コマンド実行など例外はある) | 担保されている(コマンド実行など例外はある) | |
情報管理 | システム情報の取得 | facterにより取得する | Ohaiにより取得する | facterにより取得する |
パラメーター管理の機構 | Hiera | Data Bag | Inventory | |
ツール の構成 |
ターゲットでのツール導入 | Puppetのインストールが必須 | Chefのインストールが必須 | sshにより制御するため不要 |
クライアントサーバー構成 | 可能(agent-master方式) | 可能(client-server方式) | 可能(sshによるリモート制御) | |
スタンドアロン構成 | 可能(apply) | 可能(chef-solo) | 可能 | |
その他 | 作業時のサービス閉塞制御 | プログラムにて明示的に記述 | 可能 | 可能 |
一時的なパラメーター指定 | 可能 | 可能 | 可能 | |
標準GUI | Puppet Dashboard Puppet Enterprise(有償) |
Chef Server | 14-5Ansible Tower(有償) |
表をご覧頂くとわかりますように、機能的にはどれも大差はありませんが構成や記述方法などで差異があります。それは「どれも同じ事は実現できるが記述方法は異なる」という一般的なプログラミング言語の差異とも、どこか似ていると思います。
次回は上表の“プログラム”欄の内容について、詳細をお話します。
Tweet