何をするかというと。
前回に続いて、ConfigServerを構成して、アプリケーション環境の自動デプロイ機能を使ってみます。
イメージのビルドと配信(プッシュ)について
今回、「ConfigServer」の機能を提供するAMIを作成して、EC2上で起動します。このAMIは、OSとしてはFedora16を使います。この際、前回できなかった、システムテンプレートによるマシンイメージの自動ビルド機能でAMIを作成します。
前回はRHELのAMIを作りたかったので、インストール用リポジトリの用意にSystem Engine(Katello)が必要という事情がありました。今回は、Fedoraのイメージなので、一般公開されているインストール用リポジトリが使用できます。
システムテンプレートからマシンイメージを作成する操作は、「ビルド」と「配信(プッシュ)」の2段階に分かれます。「ビルド」は、Aeolusサーバ上で事前にマシンイメージを作成する作業です。Aeolusサーバ上のKVMで仮想マシンを起動して、システムテンプレートで指定されたOSのインストール作業を行います。
「配信(プッシュ)」は作成したマシンイメージを使用するクラウドに対応した形式に変換して、クラウド上で利用可能にする作業です。EC2を使用する場合であれば、イメージファイルをS3にアップロードして、AMI登録するという作業が行われます。
ちなみに、システムテンプレートは次のようなXMLファイルです。
fedora16ConfigServer.xml
<template> <name>Fedora 16 ConfigServer Template</name> <description>Fedora 16 Image Factory ConfigServer Template</description> <os> <name>Fedora</name> <version>16</version> <arch>x86_64</arch> <install type='url'> <url>http://download.fedoraproject.org/pub/fedora/linux/releases/16/Fedora/x86_64/os/</url> </install> <rootpw>p@ssw0rd</rootpw> </os> <repositories> <repository name="fedora16"> <url>http://download.fedoraproject.org/pub/fedora/linux/releases/16/Fedora/x86_64/os/</url> </repository> </repositories> <packages> <package name="aeolus-configserver"/> </packages> <commands> <command name="F16 updates">yum update -y</command> </commands> </template>
「os」タグで指定された情報に従って、最小構成のOSのインストールが行われた後、「repositories」タグのリポジトリから「packages」タグで指定されるパッケージを追加導入します。最後に「commands」タグのコマンド群を実行して、好みのカスタマイズ処理を行います。この例では、Fedora16に、aeolus-configserverのパッケージを追加して、最後に「yum update」で全パッケージを最新に上げています。
ただし・・・
実は、配信先としてEC2を使う場合に限って、これとは少し違う「snapshot」方式のイメージ作成が可能です。というか、デフォルトではsnapshot方式が利用されるようになっています。
先に説明した、「snapshot」方式でない方のやり方は「upload」方式と呼ばれます。snapshot/uploadのどちらを使うかは、設定ファイル/etc/imagefactory/imagefactory.confの"ec2_build_style"オプションに指定します。変更後は、imagefactoryサービスを再起動します。
# service imagefactory restart
snapshot方式の場合、「ビルド」作業は実際には何も行いません。「配信(プッシュ)」を実行したタイミングで、システムテンプレートで指定されたOSのAMIをEC2上で起動して、パッケージ追加やカスタマイズ処理を実施した後に、それを再度AMIとして登録します。この処理において、最初に起動する(最小構成の)AMIは、/etc/imagefactory/jeos_images/以下の設定ファイルに記載されています。
/etc/imagefactory/jeos_images/以下のファイルを見ると、RHELとFedoraのマイナーバージョンごとに細かく対応するAMIのIDが指定されています。これらは、Aeolusの開発陣が事前にEC2上で作成してパブリックAMIとして公開しているものです。
snapshot方式、upload方式のどちらにおいてもイメージ作成/配信は、ImageFactory、およびozと呼ばれるツールがバックエンドで使用されています。イメージを作成できるゲストOSとしては、現状では、Fedora7〜16とRHEL5、RHEL6のみが対応しています。
ConfigServerイメージの作成と配信
前掲のシステムテンプレート「fedora16ConfigServer.xml」からConfigServerのイメージを作成してみます。下図の画面(「管理」タブ⇒「環境」)で「Amazon EC2プール」の「新規のイメージ」をクリックします。
イメージに適当な名前(ここでは「Fedora16 ConfigServer」)を指定して、先に用意したシステムテンプレート(fedora16ConfigServer.xml)をアップロードして、「続ける」を押します。
アップロードしたXMLの編集画面がでるので、必要に応じて変更したら「保存して続ける」を押します。すると、下記の画面になります。画面左の「ビルド」を押すとビルド処理が始まりますが、先述のsnapshot方式なので、これは一瞬で終わります。画面右に「push」ボタンが出るので、これを押すと配信(プッシュ)処理が始まります。
EC2でインスタンスが起動して、システムテンプレートで指定されたカスタマイズ処理が始まります。「yum update」は結構時間がかかるので、ImageFactoryのログファイル/var/log/imagefactory.logを眺めながら気長に待ちます。AMIができてpush処理が完了すると、その旨が画面に表示されるので、画面上部の「イメージから展開可能な新規アプリを作成」を押して、前回同様に、このインスタンスを起動するだけのアプリケーションを登録します。ここでは、アプリケーション名を「Fedora16 ConfigServer」としています。
最後に「モニター」タブの一般ユーザ画面から登録したアプリケーションをデプロイして、ConfigServerのインスタンスを起動します。
ConfigServerの初期設定とAeolusへの登録
ConfigServerのインスタンスが起動したら、SSHログインして、次のコマンドを実行します。
# aeolus-configserver-setup
「Do you wish to continue [y/N]」にyで答えたら、その他の質問は空エンターで進みます。途中で表示される、下記のようなAuth KeyとAuth Secretをメモしておきます。
Conductor Auth Key: 069682683747315236488543 Conductor Auth Secret: MNT0TxB9oJ8Rq7PFWteEsJLSmiBc0y8O5MNDYiksBS2tuyb6
コマンドの実行が完了したら、次は、このConfigServerをAeolusに登録します。「管理」タブ⇒「クラウドプロバイダー」⇒「ec2-ap-northeast1」⇒「アカウント」で、先に登録したAWSのアカウント(ここでは「enakai-Tokyo」)をクリックすると、下記の画面になります。
「設定サーバー」の「追加」をクリックすると、ConfigServer登録画面になるので、先にメモしておいたKeyとSecretを入力して、さらに「Endpoint」には、「https://<起動インスタンスのPublic IP>」を指定して、「保存」を押します。このインスタンスには、外部からTCP443で接続できる必要がありますので、EC2のセキュリティグループ(defaultが使用されているはずです)で、TCP443の接続を許可しておいてください。
これで、Tokyoリージョンにデプロイするアプリケーションは、ConfigServerによる自動設定機能が利用できるようになりました。
ご存知のようにConfigServerのインスタンスを停止/起動するとPublic IPが変化します。この場合は、再度、「Endpoint」を設定し直す必要があります。
自動設定機能のテスト
起動するインスタンスが1つのシンプルな例で、自動設定機能の動作を確かめてみましょう。
「管理」タブ⇒「環境」⇒画面上部の「イメージ」で、既存イメージの一覧を表示して、前回作成した「RHEL6.3 with audrey-agent」を選択します。画面上部の「イメージから展開可能な新規アプリを作成」を押して、新しいアプリケーション「RHEL6.3 my motd」を「EC2 Test Catalogue」に作成します。
ただし今回は、下記の画面が表示されたところで、「XMLの編集」を押して、XMLの編集画面に移ります。
このXMLが「アプリケーションブループリント」です。ここでは、既存の内容に対して、下図の「services」タグ以下を追加します。
<?xml version="1.0"?> <deployable version="1.0" name="RHEL6.3 my motd"> <description/> <assemblies> <assembly name="RHEL6-3-with-audrey-agent" hwp="small-x86_64"> <image id="c0d6f20f-6e7a-4835-b41e-7b16a8cdbe35"/> <!-- ここから追加 --> <services> <service name="config_motd"> <executable> <contents><![CDATA[#!/bin/bash echo "$AUDREY_VAR_config_motd_message" >> /etc/motd echo '-----' >> /etc/motd]]> </contents> </executable> <parameters> <parameter name="message"> <value>Hello, World!</value> </parameter> </parameters> </service> </services> <!-- ここまで追加 --> </assembly> </assemblies> </deployable>
これは、インスタンス起動後に/etc/motdに任意の文字列をセットするという処理を定義しています。
この後、一般ユーザ画面(「モニター」タブ)から、前回と同じ手順でアプリケーション「RHEL6.3 my motd」を起動すると、次の設定画面が表示されます。ここで、/etc/motdに設定する文字列をカスタマイズできます。
任意の文字列を指定して、アプリケーションをデプロイした後に、起動したインスタンスにSSHログインすると、/etc/motdに仕込んだ文字列が表示されます。
この後は・・・
この後は、さらに複雑なアプリケーションブループリントを作成することで、複数インスタンスを同時に起動して連携させるような設定を行うことも可能です。が・・・これは上級編の課題ということで、本記事はここまでにしておきます。
ちなみに下記は、製品版のCloudFormsで、4ノード構成のGlusterFS環境を自動デプロイするデモ映像です。
そして、最後の補足となりますが、ConfigServerの仕組みはざっくりと次の通りです。
Aeolusからアプリケーションをデプロイしたタイミングで、各インスタンスの設定情報がAeolusからConfigServerに送られます。Aeolusは、同時に、各インスタンスの(EC2の機能である)「ユーザデータ」にConfigServerへの接続情報を入れておきます。
その後、インスタンスが起動して「audreyサービス(/usr/bin/audrey)」が起動すると、これは「ユーザデータ」からConfigServerへの接続情報を入手します。そして、ConfigServerから自分が行うべき設定内容を取得した後に、その設定を実施します。この際、ConfigServerを仲介して、複数インスタンスがお互いの構成情報をやりとりすることも可能になります。