Tech Sketch Bucket of Technical Chips by TIS Inc.

様々なインフラ自動化ツールを組み合わせたCloudConductorを使って、Webシステムを自動構築してみよう

Pocket

クラウドを利用する場合、システムの構築や運用にはインフラ自動化ツールの利用が不可欠です。 OSSのインフラ自動化ツールとして、仮想マシンイメージを作成するpacker、ネットワークやインスタンスを自動作成するTerraform、ミドルウェアのインストールや設定変更が可能なChef、インフラのテストを実行できるServerspecなどがよく使われています。

しかし、システムの構築から設定、テスト、その後の運用まで統合的に自動化するためには、いくつかのツールを組み合わせて利用する必要があり、どうしても実行タイミングの制御やパラメータの連携などが必要になります。

CloudConductorは、これらのインフラ自動化ツールを連携させ、定義されたパターンに従ってインフラの自動化、自律化を実現するOSSのクラウドオーケストレーションツールです。 CloudConductorを利用する事で、利用者から見ると、個別のツールを意識することなく統合的にインフラを自動構築、自律運用することができます。

今回は、CloudConductorを使ってサンプルのJavaアプリケーション実行環境を構築する方法を紹介します。

インフラの自律運用を実現するCloudConductor

CloudConductorは、さまざまなインフラ自動化ツールを連携させて、クラウド上にシステムを自動構築し、自律的な運用を実現するオーケストレーションツールです。 CloudConductorを利用する事で、システムの構築、設定、テストを統合的に実施することができます。

下図のように、CloudConductorからの命令はオーケストレーションツールであるConsul、Metronomeを経由してシステムを構成するインスタンスで共有され、実行順序の制御やパラメータの連携が行われます。

cloud_conductor_v2_orchestration_process

CloudConductorでは、ネットワークやインスタンス、ミドルウェアの設定などを「パターン」として定義し、その「パターン」に従ってシステムを構築します。 「パターン」の実体は、前述したような各種インフラ自動化ツールのテンプレートやスクリプトの集合です。

「パターン」にはアプリケーション実行環境を定義したプラットフォームパターンと、監視やバックアップ機能などを追加するオプショナルパターンがあり、必要に応じていくつかの「パターン」を組み合わせて利用できます。

最新のv2.0に対応するサンプルパターンとして、以下のものが公開されています。

「パターン」の詳細については、CloudConductor公式サイトのOverviewのページをご覧ください。

CloudConductorのセットアップ

CloudConductorのセットアップ方法は、公式サイトのGetting Startedに記載されています。AWSを利用できる場合はインストール済みのAMIが用意されているので、今回はそちらを利用します。インストール済みAMIの情報はUsing CloudConductor AMIのページに記載されています。

インスタンスの作成

インストール済みAMIは東京リージョンで公開されているので、東京リージョンのEC2でインスタンスの新規作成を選択します。Community AMIsで「CloudConductor」と検索するとインストール済みAMIが一覧に表示されるので、v2.0のAMI(ami-d90516b7)を選択します。

インスタンス作成のセキュリティグループの設定で、SSH接続できるよう22番ポートを許可しておきます。また、GUIを利用する場合は8000番ポートを許可しておきます(接続元は環境に合わせて適宜設定してください)。

アカウントの確認

インスタンスの作成が完了したら、インスタンス作成時に指定したキーペアを使ってSSH接続します。 ログインのユーザ名はec2-userです。

インストール済みのCloudConductorには管理者アカウントが作成されています。 以下のコマンドを実行すると、作成済みのアカウントが確認できます。

CLIの認証情報は環境変数に設定されています。アカウントを切り替える場合は、適宜変更してください。

プロジェクトの設定

ここまでで、CloudConductorを利用する準備が整いました。 続いて、プロジェクトの設定を行っていきます。

Project

最初にプロジェクトを作成します。 利用するクラウドやパターン、構築した環境の情報は、このプロジェクト単位で管理されます。

以下のコマンドを実行して、プロジェクトを作成します。

プロジェクトを作成したアカウントは自動的にそのプロジェクトのメンバーとして割り当てられます。 また、自動でシステム監視用のアカウントが作成され、メンバーに追加されます。

Role

ロールには、プロジェクト配下のリソース(クラウドやパターンなど)に対して、作成、参照、更新、削除の操作権限が設定されています。 プロジェクトを作成したアカウントには、プリセットのロールが自動的に付与されます。

注意事項として、ロールの制御範囲はプロジェクトごとになります。 アカウントが複数のプロジェクトに所属する場合は、プロジェクトごとにロールを割り当てる必要があります。

アカウントに付与されているロールは、以下のコマンドで確認できます。

ロールの権限設定は、以下のコマンドで確認する事ができます。 manageは、そのリソースに対して全ての操作が許可されます。

Cloud

次にプロジェクトで利用するクラウドの情報を登録します。

以下は、AWSの東京リージョンを登録するコマンドです。 entry-pointにはAWSのリージョンコードを指定します(東京リージョンはap-northeast-1)。 keyとsecretにはAWSのアクセスキーとシークレットアクセスキーを指定します。 AWSのアクセスキーについてはこちらをご覧ください。

クラウドがAWSの場合、インスタンスのベースになるマシンイメージの情報が自動で読み込まれます。 プライベートクラウドであるOpenStackやWakame-vdcを利用する場合は、別途マシンイメージのIDを登録する必要があります。

ベースイメージの情報は、以下のコマンドで確認できます。

Pattern

プロジェクトで利用するパターンを登録します。 今回は、JAVAアプリケーションの実行環境を構築するtomcat_patternと、共用ネットワークを構築するcommn_network_patternを登録します。

以下のコマンドを実行して、パターンを登録します。 revisionにはGitのブランチ名、タグ名、コミットのハッシュ値が指定できます。

システムの構築

CloudConductorによるシステム構築は、プレビルドイメージの作成、環境構築、アプリケーションデプロイの順に実行します。 構築のフェーズが分かれているため、プレビルドイメージを流用して同じ環境をいくつも用意したり、バージョンの異なるアプリケーションを乗せ変えたりすることが可能です。

CloudConductorでは、システムの構築・運用のフェーズに応じてライフサイクルイベントと呼ばれるイベントが定義されています。 パターンにはライフサイクルイベントに応じたタスクが定義されており、イベントが発生した際に自律的に実行されます。

システム構築時に発生するライフサイクルイベントは以下の通りです。

  • Setup(プレビルドイメージ作成時に発生)
    • 各種ミドルウェアのインストール
    • 環境に依存しないパラメータ設定を実施
  • Configure(環境構築時に発生)
    • インスタンスのIPアドレスのように、実際に構築するまで確定しない値を必要とする設定
    • ユーザーのパラメータ指定による設定変更
  • Deploy(アプリケーションデプロイ時に発生)
    • アプリケーションファイルの展開
    • アプリケーションに応じた設定変更
  • Spec(Configureイベント、Deployイベントと同時に発生)
    • 設定変更された環境のテストを実施

この他にもBackupやRestoreという運用のためのイベントが用意されています。 また、パターンにタスクを定義しておけば、ユーザが任意のイベントを定義して発生させることも可能です。 詳しくは、公式サイトのタスク定義のページをご覧ください。

プレビルドイメージの作成

システム構築に利用するパターンを選択して、クラウド上にプレビルドイメージを作成します。

Blueprint

ブループリントとは、利用するパターンの組み合わせやリビジョン、利用するOSのバージョンを定義したものです。

以下のコマンドで、ブループリントを作成します。

続いて、システム構築に利用するパターンをブループリントに追加します。 ここでは、tomcat_patternとcommon_networkを追加します。 このとき、ベースイメージのOSプラットフォームとOSバージョンを指定できます。

以下のコマンドで、ブループリントにパターンを追加します。

ブループリントに登録されているパターンは、以下のコマンドで確認できます。

利用するパターンを追加したら、ブループリントのビルドを実行します。 ビルドを実行すると、プロジェクトに登録されているクラウドにプレビルドイメージの作成が開始されます。

以下のコマンドで、プレビルドイメージのステータスを確認できます。ステータスがCREATE_COMPLETEになっていれば、作成完了です。作成にかかる時間は環境次第ですが、AWS東京リージョンと今回のパターンの組み合わせの場合、15分程度で完了します。

もしステータスがERRORになった場合は、設定やパターンの組み合わせを変更して再度ビルドすることで、プレビルドイメージを再作成できます。

環境構築

プレビルドイメージの準備が整ったので、続いて、実際に利用する環境を構築します。

System

システムのグループを作成します。 システムのドメイン名を指定することで、構築した環境のIPアドレスをDNSに登録したり、複数の環境を切り替えて利用したりすることができます。

今回はDNSの設定を行っていないため、ドメインを指定せずに作成します。

Environment

利用するブループリントを指定して、クラウド上に環境構築を行います。

以下のコマンドで環境構築を実行しますが、パラメータが多いため、必要な情報を個別に確認しておきます。

blueprintとversion

blueprintとversionには、ブループリント名とプレビルドイメージのバージョンを指定します。 ビルドを複数回実行した場合は複数のプレビルドイメージが作成されているので、任意のバージョンを指定します。 バージョンは以下のコマンドで確認できます。

clouds

cloudsには利用するクラウドを優先順に指定します。今回はAWSのみですが、障害など何らかの理由でクラウドが利用できなかった場合、次の優先順位のクラウドに自動的に環境構築が行われます。

template parameters

環境構築のコマンドを実行すると、以下のように対話形式でパラメータの入力を求められます。

パラメータのタイプは、値を直接入力するstaticと、組み合わせた他のパターンから値を取得するmoduleのどちらかを選択します。 moduleを指定する場合は、あらかじめ他のパターンの取得可能なパラメータを確認しておく必要があります。

今回のパターンの組み合わせでは、common_networkで作成されるVPCなどの情報をtomcat_patternで利用しています。 今回入力するパラメータは以下の通りです。

tomcat_pattern parameters

  • vpc_id
    • type: module
    • value: common_network.vpc_id
  • subnet_ids:
    • type: module
    • value: common_network.subnet_ids
  • shared_security_group
    • type: module
    • value: common_network.shared_security_group
  • key_name
    • type: static
    • value: key-name
    • AWS東京リージョンに作成済みのキーペア名を指定します
  • web_instance_type
    • type: static
    • value: t2.small (default)
  • ap_instance_type
    • type: static
    • value: t2.small (default)
  • db_instance_type
    • type: static
    • value: t2.small (default)

common_network parameters

  • subnet_size
    • type: static
    • value: 1 (default)
  • availability_zones
    • type: static
    • value: ap-northeast-1a
    • ※利用可能なアベイラビリティゾーンはAWSアカウントごとに異なります。こちらを参考に利用可能なアベイラビリティゾーンを確認してください。

コマンド実行

コマンド実行、パラメータ入力に必要な情報が確認できたら、以下のコマンドを実行して環境構築を行います。

全てのパラメータを入力すると、実際にクラウド上にネットワークやインスタンスの作成が開始されます。 また、インスタンスの作成が完了すると同時にconfigureイベント、specイベントが発生し、環境の設定とテストが自動的に実行されます。

以下のコマンドで作成した環境の詳細を確認し、ステータスがCREATE_COMPLETEになれば構築完了です(今回の組み合わせの場合、10分程度かかります)。

アプリケーションデプロイ

ここまでで、AWS上にJavaアプリケーションの実行環境が構築できました。 最後にサンプルのアプリケーションをデプロイします。

Application

以下のコマンドでデプロイするアプリケーションの名前を登録します。

Application Release

続いて、アプリケーションのURLを登録して、アプリケーションをリリースします。

アプリケーション取得のプロトコルとしてhttpgitを指定でき、httpの場合ファイルダウンロードが、gitの場合リポジトリのクローンが行われます。

また、json形式でパラメータを追加することができます。 このパラメータはデプロイ時にアプリケーションの情報と同時に環境に渡され、Deployイベントに対応する処理で参照することができます。

以下のコマンドを実行して、アプリケーションをリリースします。

アプリケーションリリースでは情報の登録のみで、まだ構築した環境にアプリケーションは展開されません。 登録されている情報は以下のコマンドで確認する事ができます。

アプリケーションの情報はリリースごとに保持されているので、再度リリースを行うと新バージョンとして履歴が追加されていきます。

Application Deploy

最後に、以下のコマンドで構築した環境にアプリケーションをデプロイします。 アプリケーションリリースのバージョンを指定しない場合は、デフォルトで最新のリリースが利用されます。

デプロイを実行すると構築した環境でアプリケーションファイルが展開され、パターンのDeployイベントに定義された処理が実施されます。 また、合わせてSpecイベントも発生し、アプリケーションが問題なくデプロイできたかテストが行われます。

以下のコマンドでデプロイ先の環境の詳細を確認し、アプリケーションステータスがDEPLOY_COMPLETEになっていればデプロイ完了です。

動作確認として、ブラウザでhttp://52.196.79.101(frontend_address)/jpetsore/にアクセスするとサンプルのペットショップアプリケーションが利用できます。

まとめ

今回は、CloudConductorを利用して、クラウド上へのマシンイメージの作成から、環境構築、アプリケーションのデプロイまで、システム環境の構築を統合的に行いました。 特に、複数の自動化ツール間でパラメータの橋渡しができること、ライフサイクルイベントを軸に自律的に設定変更などが行われることが特長と言えます。

対象とする範囲が広いため理解すべき要素が多く難しく感じると思いますが、単なる自動化ではないオーケストレーションを考える上で、CloudConductorがひとつ参考になればと思います。

エンジニア採用中!私たちと一緒に働いてみませんか?