めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

Aeolus（アイオロス）でRHELonEC2を利用する(その1)

変更履歴

2012/08/04

  • 既知の問題修正手順追加
  • aeolus-audrey-agentのRPMバイナリを変更。
  • RHEL6.3AMIへのaudrey-agent導入手順修正。

何の話かというと。

レッドハットが最近発表したCloudFormsには、「System Engine」と「Cloud Engine」の2種類のソフトウェアコンポーネントが含まれています。

超絶に簡略化して説明すると、System Engineは、RHELのサブスクリプションやリポジトリ（Errata/Update配信）を管理する機能を提供するもので、Cloud Engineは、仮想化基盤やパブリッククラウド上にRHELイメージを配信して、RHEL上のアプリケーション環境を自動セットアップする機能を提供します。

イメージとしては、「システムテンプレート（VMイメージの構成情報）」「アプリケーションブループリント（VMイメージ起動後のアプリケーションセットアップ手順）」の2種類の設定ファイルを事前に用意することで、下図のような一連のシステム構築/メンテナンス作業を全部自動化するような仕組みになります。

現行バージョン（v1.0）では、RHEV/VMware/Amazon EC2の3種類の環境に対応しているので、共通の設定ファイルから複数の環境に対して、同じアプリケーション環境を自動構築することができるようになります。

そして、CloudFormsを構成するコンポーネントは、すべてオープンソースでできており、System Engineは「Katello」、Cloud Engineは「Aeolus」がアップストリームのプロジェクトになります。Katello/Aeolusは、Fedora17に同梱されていますので、Fedora17上であれば簡単に試してみることができます。

ここでは、Fedora17のAeolusを利用して、Amazon EC2上にRHELのアプリケーション環境を自動セットアップする手順を紹介します。AWSの従量課金で提供されるRHELインスタンスを使用するので、RHELのサブスクリプションを購入しなくても試していただくことが可能です。

※Fedora17同梱のKatello/Aeolusは、製品版のCloudFormsよりも新しい機能（と新しいバグ・・・）が含まれていますので、サポート付きの安定版が必要な場合は、CloudFormsをご利用ください。

導入手順

KVMが使えるサーバにFedora17を入れて、「yum update」で最新にあげておきます。iptablesは、TCP443（https）を開けておきます。現バージョンでは、SELinuxは残念ながら、permissiveモードにする必要があります。（製品版CloudFormsは、enforceモードでOKです。）

（参考） Frequently Asked Questions (FAQ)

その後、次を実行すると、Aeolusの実行に必要なコンポーネントが全部まとめて入ります。

# yum install aeolus-all

ここで、既知の問題の修正を行なっておきます。（このような修正は、製品版CloudFormsでは必要ありません。）

# sed -i.bak -e "s/contains    =>/#\0/" /usr/share/aeolus-configure/modules/aeolus/manifests/conductor/provider.pp
# sed -i.bak -e "s/Conductor.prefixedPath(self.urlRoot/(self.urlRoot/" /usr/share/aeolus-conductor/public/javascripts/backbone/models.js
# sed -i.bak -e "s/@deployment.create_and_launch/@deployment.save \&\& \0/" /usr/share/aeolus-conductor/app/controllers/deployments_controller.rb
# sed -i.bak -e "s/service.id/service.name/" /usr/share/aeolus-conductor/app/views/deployments/launch_time_params.html.haml
# sed -i.bak -e 's/"-S", self.ec2_secret_key/\0, "-a", self.tdlobj.arch/' /usr/lib/python2.7/site-packages/imgfac/builders/Fedora_ec2_Builder.py

上記の修正は次の問題に対応します。

これらは、新しいバージョンで修正されていくと思います。この記事を書いている時点での主要コンポーネントのバージョンを示しておきます。

aeolus-all-0.10.4-1.fc17.noarch
aeolus-conductor-0.10.4-1.fc17.noarch
aeolus-configure-2.6.1-1.fc17.noarch
deltacloud-core-1.0.0-7.fc17.noarch
imagefactory-1.1.1-1.fc17.noarch

続いて、次のコマンドを叩くと、puppetが動いてもろもろの初期設定を行なってくれます。

# aeolus-configure

万一、puppetの機嫌が悪くてエラーが発生した場合は、次を実行すると初期設定前の状態に戻るので、再度、初期設定を試してみてください。

# aeolus-cleanup
# service postgresql stop

ここで、Webブラウザから「https:///conductor」にアクセスすると、ログイン画面が表示されるので、「admin/password」でログインできることを確認します。ユーザ設定画面を見つけ出して、必要に応じてadminユーザのパスワードを変更しておいてください。

Amazon EC2を管理対象クラウドとして登録

ここからは、EC2を使用する場合の手順です。次を実行すると、EC2の各リージョンが管理対象として登録されます。

# aeolus-configure -p ec2

この際に表示される次のエラーは無視して構いません。

err: /Stage[main]/Aeolus::Conductor/Aeolus::Conductor::Site_admin[admin]/Exec[create_site_admin_user]/returns: change from notrun to 0 failed: /usr/bin/rake dc:create_user[admin,password,root@localhost.localdomain,Administrator,] returned 1 instead of one of [0] at /usr/share/aeolus-configure/modules/aeolus/manifests/conductor/site_admin.pp:9

この後、Web管理画面で、画面上部の「管理」タブ選択⇒「クラウドのプロバイダー」を選ぶと、「プロバイダーの選択」のプルダウンメニューからEC2の各リージョンが選択できるようになっています。


AWSアカウントを登録

続いて、自分の持っているAWSアカウントを登録します。まずは、AWSのセキュリティ証明書管理サイトに行って、「アカウントナンバー、アクセスキーID、シークレットアクセスキー、X.509証明書（証明書ファイルと対応するプライベート鍵ファイル）」を入手します。（アカウントナンバーはAWSの画面右上で「口座番号」と記載されている番号のことです。）

次に、Web管理画面で「プロバイダーの選択」で使用するリージョンを選びます。ここでは例として、「ec2-ap-northeast-1」（Tokyoリージョン）を選びます。そして、「アカウント」⇒「新規のアカウント」を選択すると、下記の登録画面に進みます。

各項目を入力して、「保存」を押すと登録完了です。登録完了画面から、そのまま「ロールの割り当て」⇒「アクセスの付与」を選んで、adminユーザに「プロバイダーの管理者」ロールを割り当てておきます。

アプリケーションを展開する際に、展開先のリージョンを指定できるように、「領域」の定義を行なっておきます。「管理」タブ⇒「コンテンツ」⇒「領域」⇒「新規の領域」で、任意の名前（ここでは「Tokyo Region」とします）の「領域」を作成した後に、「プロバイダーにマッピングを追加」を選んで、Tokyoリージョン「ec2-ap-northeast-1」を追加します。

最後にインスタンスサイズを選択するための「ハードウェア・プロファイル」を登録します。「管理」タブ⇒「コンテンツ」⇒「ハードウェア」を開くと、既存で「small-x86_64」というプロファイルがm1.smallにマッピングされています。ここでは、例として、「c1.medium」に対応するプロファイルを追加しておきます。

「新規のハードウェアプロファイル」を選んで、下記の内容を入力して、「一致をチェック」を押すとc1.mediumが選択されますので、そのまま「保存」を押します。


EC2だけ利用するのであれば、ダイレクトにc1.mediumなどを選択できるようにして欲しくなりますが、複数のクラウド環境に対応するためにこのような仕組みになっています。たとえば、RHEVとEC2の両方をプロバイダーに登録した環境では、同じ「medium-x86_64」というプロファイルを指定すると、展開先の環境に応じて、対応するサイズのインスタンスが選ばれるようになります。

プールファミリーの登録

事前登録作業が長くて大変ですが・・・、次は「プールファミリー」を登録します。これは、一般ユーザにインフラのリソースを配分するために使う概念になります。

「プールファミリー」は、複数のクラウド環境を1つにまとめた概念です。たとえば、RHEVとEC2を含むプールファミリーを作ると、そのプールファミリーを利用するユーザは、アプリケーションを展開する際に、RHEVとEC2のどちらを使うのかが選択できるようになります。

また、実際に各ユーザに割り当てるのは、1つのプールファミリー内に複数作成した「プール」の単位になります。プールごとに利用できるアプリケーションの種類や起動できるインスタンス数の上限などを指定することができます。

ここでは、次のような環境を用意します。

手順は次のとおりです。画面遷移が若干意味不明な場合がありますが、見慣れない画面が出た場合は、「管理」タブ⇒「環境」を選ぶと上記画面に戻ります。

まずは、「管理」タブ⇒「環境」⇒「新規のプールファミリー」で、「Amazon EC2」を作成します。このプールファミリーで利用できるインスタンス数の上限を設定できるので、クラウド破産しないように、ここでは「20」を指定します。

作成された「Amazon EC2」プールファミリーの枠の左上の「Amazon EC2」をクリックして、「アカウント」を選択すると、このプールファミリーにひもづけるインフラが登録できます。先に作成したEC2 Tokyoリージョンのアカウント（この例では「enakai-Tokyo」）を追加します。その後、「Amazon EC2」プールファミリーの枠にある「新規のプール」で、「EC2 Test Pool」を作成します。

続いて、「管理」タブ⇒「コンテンツ」⇒「カタログ」で新規のアプリケーションカタログを作成します。ここでは、「EC2 Test Catlogue」を作成します。この際、ひもづけるプールの選択があるので、先に作成した「EC2 Test Pool」を指定します。

マシンイメージの作成

いよいよRHELのマシンイメージをビルドして、クラウドに配信します。

ただし。。。。

本来は、マシンイメージの構成を指定する設定ファイル（システムテンプレート）を用意して、好みの構成のイメージをビルドすることができるのですが、RHELの場合は、事前にSystem Engine（Katello）を利用して、イメージビルド用のリポジトリを用意する必要があります。（この際、RHELのサブスクリプション登録が必要になります。商用ディストリビューションなので仕方ないですね。。。許して下さい。）

これは面倒なので、ここでは、AWS上で一般公開されているRHELのAMIをAeolusにインポートすることで、Aeolusから該当AMIのインスタンスを起動できるようにします。この時、この後で利用するConfigServerによる自動設定機能を使うために1つだけ仕込みをしておきます。

まず、EC2のTokyoリージョンで、RHEL6.3のインスタンスを起動します。QuickStartからRHEL6.3を選択するか、ami-5453e055を選択してください。インスタンスサイズは、t1.microで構いません。起動して、ここで入手したRPM（aeolus-audrey-agent-0.4.10-1.el6.noarch.rpm）をインスタンスにsftpで転送しておいて、次を実行します。

# yum install http://mirror.cogentco.com/pub/linux/epel/6/i386/epel-release-6-7.noarch.rpm
# yum install aeolus-audrey-agent-0.4.10-1.el6.noarch.rpm
# echo 'CLOUD_TYPE="ec2"' > /etc/sysconfig/cloud-info
# rm ~/.ssh/authorized_keys

この後、このインスタンスからAMIを作成します。このインスタンスはこれで破棄して構いません。

次に「管理」タブ⇒「環境」の画面で、「Amazon EC2」プールファミリーの枠にある「イメージをインポート」を押します。下記の画面で、イメージIDに先に作成したAMIのIDを入れて、適当なイメージ名（ここでは「RHEL6.3 with audrey-agent」）を指定します。

「続ける」を押してインポートに成功すると、下記の画面になります。

続いては、このイメージを利用したアプリケーションを定義することになりますが、まずは、テストとして、単純にこのイメージのインスタンスを1つ立ち上げるだけのアプリケーションを定義します。先の画面の右上にある「イメージから展開可能な新規アプリを作成」を押して、アプリ名（ここでは「RHEL6.3」）、ハードウェアプロファイル（ここでは「small-x86_64」）、カタログ（ここでは「EC2 Test Catalogue」）を指定して、「保存」を押します。

すると下記のあやしい（？）画面が出ますが、これでアプリケーションの定義はできているので、この画面は一旦無視してください。


インスタンス起動テスト

Web管理画面の「モニター」タブを選択します。このタブは、一般ユーザが使用するメニュー画面になります。下図のように「EC2 Test Pool」の右側のプルダウンを開いて、「EC2 Test Catalogue」を選びます。

このプールで利用可能なアプリケーション一覧が表示されます。今は、先ほどつくった「RHEL6.3」だけがありますので、これの「選択」ボタンを押すと下記の画面になります。ここで任意のアプリケーション名（ここでは「RHEL6.3 Test」）をつけて、実行する領域（ここでは「Tokyo Region」）を選んで、「起動」を押します。

下記のような画面が表示されて、EC2でインスタンスの起動が開始します。起動が完了すると、この画面上にIPアドレスが表示されます。

この画面から認証鍵がダウンロードできるので、これを利用してインスタンスにログインすることが可能です。EC2のセキュリティグループは「default」が使用されるので、必要なポートの開放は事前に行なっておいてください。

画面右上の「削除」を押すと、インスタンスはTerminateして、デプロイしたアプリケーションの情報も削除されます。

この次は・・・

今回はただインスタンスを起動しただけですが、Aeolusの本当の目的は、複数インスタンスからなるアプリケーション実行環境を自動デプロイすることです。これには、ConfigServerを利用する必要があります。具体的な手順は、また次回に・・・。

最後のおまけに、Aeolus関連サービスの起動/停止コマンドを紹介しておきます。

次は、Aeolus関連サービスをまとめて再起動します。

# aeolus-services-restart

関連サービスの稼動状態の確認は次です。

# aeolus-check-services

関連サービスの起動/停止は次になります。

# aeolus-services stop|start