システム自動管理ツールとSCMの活用(前回の続き)

前回のブログでは、システム自動管理ツールとSCMを利用して、環境設定のバージョン管理が行えることを紹介しました。今回は、任意の環境(開発・テスト・本番など)を、任意のバージョンに更新するときの作業(例えば、開発環境をバージョン2にするなど)の自動化を紹介します。

自動化に使用するツールとその使い方はいろいろあると思いますが、ここでは、CIツール：Jenkins、自動管理ツール：Puppet、SCM：Gitを使用した例を紹介します。

以下に、全体像と処理の流れを示します。

上記の例では、開発環境、テスト環境、本番環境の３つの環境があり、それぞれの環境ごとにJenkinsのSlave(Masterから指示されたジョブを実行する役割)と、PuppetのMaster(Agentに環境の定義情報を配信する役割)を用意しています。JenkinsのMaster(Slaveに指示を出す役割)とGitは、全環境で共有しています。

図中の番号に沿って処理の流れを説明します。運用者は、環境ごとに用意されたJenkinsのジョブを実行します(１)。その際、環境の定義情報のバージョンを指定します。指定されたバージョン情報はJenkinsのMasterに送信され(２)、環境ごとのJenkinsのSlaveにジョブが指示されます(３)。JenkinsのSlaveは、Gitから、指定されたバージョンの定義情報をチェックアウトし(４)、PuppetのMasterに処理を指示します(５)。PuppetのMasterは、PuppetのAgentに定義情報を配信し(６)、PuppetのAgentは定義情報に沿って各サーバの環境を更新します。
※５と６の部分は、実際にはMCollectiveというツール(複数サーバにRPCを実行できるツール。Puppetを開発しているPuppet labsが推奨している)を仲介しています

図の例では、開発環境の更新の流れを示していますが、テスト環境や本番環境も同様です。自動化によって、作業負荷やケアレスミスの軽減が期待できます。

導入時の課題

サーバやソフトウェア間の連携が複雑になるため、ソフトウェアを始めOSやネットワークの知識がある程度必要になります。運用していて何か問題が起きたときに、問題個所を特定できなければなりません。
また、更新が適切に反映されたかどうかの判別を見誤りやすくなるのも課題です。例えば、JenkinsからPuppetに処理を指示する際、仲介役のMCollectiveは、指示ができた時点で正常終了となり、指示の後、実際に更新が反映されたかどうかは関与しません。そのため、Jenkinsの画面上は正常終了になっていても、実際には更新が失敗している可能性があります。更新の成否を判別する手段(Puppetのログを見るなど)を確立する必要があるでしょう。