Tech Sketch Bucket of Technical Chips by TIS Inc.

Cloudifyを用いた環境自動構築

Pocket

AWS CloudFormation, OpenStack Heat, Hashicorp社のTerraformなど、 システム構成全体をTemplateに記述し、クラウド等の環境に自動構築することは珍しくなくなりつつあります。 しかしこれらのTemplateはどちらかといえばIaaSや一部のPaaSに相当するインフラ構成の記述が中心であり、 個別のミドルウェアやアプリケーションレイヤの管理は別途行う必要があったり、別のクラウドへの移行時に再利用が難しいといった課題もありました。

今回はこうした課題の解決に役立つかもしれない、OASIS TOSCAの仕様に準拠したTemplateをもとに構築を行うCloudifyを実際に動かしてみました。

Cloudifyとは

Cloudifyは、 GigaSpaces Technologies社が開発しているオープンソースのクラウドオーケストレーションフレームワークです。 Cloudifyの大きな特徴として、標準化団体である Organization for the Advancement of Structured Information Standards (OASIS)が定めた Topology and Orchestration Specification for Cloud Applications (TOSCA)という仕様に従って書かれた システム構成のTemplateをもとに、多様な環境上に自動構築を行える点が挙げられます。

TOSCA Version 1.0の仕様、およびドラフト版のYAML形式の仕様は以下で公開されています。 CloudifyではTOSCAのYAML形式の仕様に準拠したcloudify_dslに従って記述されたシステム構成を自動構築することができます。

TOSCAがどのようなものかを知るには実際に触ってみるのが一番だと思いますので、実際にCloudifyを使って環境を構築してみましょう。

Cloudifyを用いた環境構築

Cloudify CLIのインストール

まずはCloudify CLIをインストールしてみましょう。 CLIという名前ですが、これ単独で一通りの構築機能は試すことができます。

今回はCentOS 7.2の環境上に導入しました。 前提として、Python 2.7.xとpip 6.0+が必要となります。条件を満たしていない場合は事前に導入しておきましょう。 実行したインストール手順は以下の通りです。

Cloudify CLIを用いた環境構築

Cloudify CLIだけでも最低限の構築機能は利用できます。 Cloudifyでは、TOSCAの仕様に従ってシステム構成を記述したService TemplateのことをBlueprintと呼びます。 まずは動作確認を兼ねて、simple-python-webserver-blueprintという小さなサンプルを動かしてみましょう。

このBlueprintには、Inputとして"webserver_port"と"host_ip"を受け取り、 指定されたサーバ上で"python -m SimpleHTTPServer ${webserver_port}" のコマンドを実行して Webサーバを稼動させる構成が記述されています。早速動かしてみましょう。

cfy local initでBlueprintや付随するパラメータを登録し、 cfy local executeで構築処理を実行するという流れになっています。 実行すると、inputsで指定したポートでWebサーバが稼動していることが確認できます。

このBlueprintには"install"の処理の他に、"uninstall"の処理も記述されています。 試しに先ほど構築したWebサーバを削除してみましょう。

先ほどTCP:8000で稼動していたWebサーバが停止していることが確認できます。

Cloudify Managerの導入

先ほど試したように、CLIだけでもBlueprintを用いた構築を行うことはできます。 しかしCLI単独で利用した場合、Blueprintの管理情報は操作を行ったカレントディレクトリ内に保存されているため、 複数のBlueprintを使い分けたり、同一のBlueprintから複数の環境を構築するといった管理を行なうには不便です。

Cloudifyにはこうした管理を容易に行うためのモジュールとして、Cloudify Managerが用意されています。 Cloudify Managerを導入することで、複数のBlueprintや環境の管理、またWeb-UIやAPIによる操作などが可能になります。

Cloudify Managerの導入自体も、Cloudifyを用いて行うことができます。 Cloudify CLIを用いてCloudify Manager Serverを構築してみましょう。

公式に用意されているCloudify Manager用のBlueprintはAWS, OpenStack, vSphereなど 様々な環境に対応していますが、今回はAWS EC2上にCloudify Manager Serverを構築してみます。 AWSのAccessKeyはEC2の基本的な操作のみ許可したものを用意しておきましょう。

実行するとAWS EC2上にInstance, SecurityGroup, KeyPair等が作成され、Cloudify Managerの構築処理が行われます。 構築が完了すると、最後に以下のようなログが出力されますので、そのIPアドレスにアクセスすればCloudify ManagerのWeb-UIを利用できます。

Cloudify ManagerにSSH接続したい場合は、以下のコマンドで簡単に接続できます。

なお、デフォルトの設定ではCloudify ManagerにはどこからでもHTTP/HTTPS接続が可能な状態になっていたので、 速やかにSecurityGroupの設定を書き換えて、自身のIPからの接続のみ許可するようにしましょう。 放っておくと誰でもCloudify Managerが操作できるので、先ほどinputs.yamlに記載したAccessKeyの権限で誰でも構築を行える状態になってしまいます。

今回は省略してしまいましたが、aws-ec2-manager-blueprint-inputs.yaml内には、SecurityGroupを新規作成するのではなく既存のものを利用するuse_existing_manager_groupなどの設定項目もありますので、実際に利用する際には適宜設定しておきましょう。

Cloudify Managerを用いた環境構築

Cloudify Managerを導入すると、Web-UIから操作を行うことができるようになります。 URLは http://(ManagerサーバのIP)/ でアクセスできます。 次はこのCloudify Managerを用いて、同じくCloudifyが提供している cloudify-nodecellar-exampleという以下のBlueprintを構築してみましょう。

Blueprintの登録

まずは利用するBlueprintをCloudify Managerに登録します。 ブラウザからCloudify Managerに接続し、左側のメニューからBlueprintsを選択して"Upload Blueprint"を選択すると、 登録するBlueprintの情報を聞かれます。

upload_blueprint

今回利用するBlueprintの場合、以下の情報を入力します。

  • Blueprint file or URL: https://github.com/cloudify-cosmo/cloudify-nodecellar-example/archive/3.3.1.zip
  • Blueprint ID: (任意の名前)
  • Blueprint filename: aws-ec2-blueprint.yaml

登録処理が終わると、Blueprintの構成図が表示されます。 今回のBlueprintの場合、Node.js用のHostとMongoDB用のHostの2台構成で、 nodejs上で稼動するnodecellarというアプリケーションがmongodに接続しており、 それぞれ個別のSecurityGroupを持ち、Node.js用のHostはElasticIPを持つことが確認できます。

blueprint_topology

Deploymentの実行

登録したBlueprintを実際に構築するためには、Deploymentというリソースを作成する必要があります。 先ほどのBlueprintsの画面からCreate Deploymentを選択すると、 Deployment nameと、Blueprintの構築に必要な各種パラメータを聞かれます。 一見パラメータの説明が無いように見えますが、パラメータ名の所にマウスカーソルを合わせるとDescriptionが表示されます。

create_deployment

今回のBlueprintの場合、Ubuntuへの導入が前提になっているように見えたので、以下のようにパラメータを設定しました。 確認していませんが他のOSでも動くかもしれません。

  • agent_user: ubuntu
  • image: ami-fce3c696 (AWS公式のUbuntu Server 14.04のAMI(東京リージョン))
  • flavor: t2.micro

Create Deploymentを実行すると何やら色々な処理が開始されますが、まだこの時点では実際の環境はAWS上に構築されません。 おそらくBlueprintを解析して依存関係にある他のプラグイン等の解決を行っているのだと思われます。

実環境の構築

最後に、Deploymentsの画面からExecute Workflowを選択し、 プルダウンメニューから"install"を選択して実行すると、AWS上での構築処理が開始されます。 先ほどのパラメータ入力の際にAWSのCredentials情報を何も聞かれなかったことを疑問に思われたかもしれませんが、 この構築処理ではCloudify Managerを構築する際に指定したAccessKeyが使用されています。 処理の途中でCloudify Managerから構築したサーバへPrivate IPアドレスを指定してアクセスしている箇所もあるため、 現時点ではこのBlueprintは構築先がCloudify Managerと同じSubnet内であることが前提となっているようです。

deploy_completed

構築が完了すると、Node Cellarのアプリケーションにアクセスできるようになります。 Inputs & Outputsのタブに切り替えるとOutputsの欄に構築した環境のIPアドレスとポート番号が記載されているので、 そのアドレスにアクセスすると以下の画面が確認できると思います。

nodecellar

動作確認が終わったら、Execute Workflowを選択し、プルダウンメニューから"uninstall"を選択して実行すると、 自動構築した環境を全て削除してくれます。

まとめ

Cloudifyを使うことで、用意されたサンプル構成を簡単にAWS上で動かすことができました。

今回は提供されている簡単なサンプルを動かしてみただけなので、TOSCAの仕様に沿って書かれたBlueprintのメリットはこれだけではあまり実感できなかったかもしれません。 しかしアプリケーションレイヤまで含めて構成要素の接続関係を一目で確認できるのは他のTemplateには無い魅力だと思いますし、 今回AWSで稼動させた構成を別のクラウドへ移行するといった作業が必要になった場合、各構成要素の結合度が低く部分的な再利用性が高いTOSCAの特性が大いに実感できるのではないかと思います。 また今回実行したWorkflowはinstallとuninstallだけですが、その他にも様々なWorkflowに対応したBlueprintを記述しておけば、構築時だけでなく運用時にも役に立つと思います。

実際にBlueprintを自作しようとするとTOSCAについてもう少し詳しく知る必要がありますが、 Cloudifyはオープンソースで公開されており、様々なクラウドに対応したプラグインも公開されていますので、 興味を持った方は実際に試してみてはどうでしょうか。

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