Google Cloud Deployment Manager は、クラウド環境の管理と自動化にとても役立つツールです。一連の宣言的なテンプレートを作成しておけば、Google Compute Engine や Google Container Engine、Google BigQuery、Google Cloud Storage、Google Cloud SQL といったリソースのデプロイ、アップデート、削除を Deployment Manager が統一的に行ってくれます。

この投稿では、Google Cloud Platform（GCP）のなかの Deployment Manager について紹介します。

Deployment Manager は次の 3 種類のファイルを使用します。
Deployment Manager の推奨される使い方はテンプレートを用いることですが、最低でも設定ファイルが必要です。設定ファイルには、デプロイするリソースと、そのリソースのゾーンやマシン タイプといったプロパティを定義します。

Deployment manager は、非常に広い範囲の GCP リソースをサポートします。サポートされるリソースとそのプロパティのリストについては、こちらに掲載されています。このリストは、次の gcloud コマンドでも参照できます。

$ gcloud deployment-manager types list

多くの場合、Deployment Manager はバージョン管理システムと併用されます。インフラストラクチャの定義をチェックインできるからです。このアプローチは “Infrastructure as Code” と呼ばれています。gcloud コマンドで Deployment Manager に直接プロパティを渡すことも可能ですが、それではあまりスケーラビリティがありません。

Deployment Manager の仕組み

それでは、リソースはどのようにしてデプロイされるのでしょうか。例として、2 つのサブネットを持ち、1 つのインスタンスがデプロイされている単純なネットワークの作り方を見てみましょう。


このネットワークは次の 3 つのファイルから構成されます。
  • net-config.yaml : 設定ファイル
  • network.jinja : テンプレート ファイル
  • instance.jinja : テンプレート ファイル
テンプレート ファイルは、構成を再利用可能な小さい部品に分割する論理ユニットとして使用します。テンプレートを組み合わせれば、大規模なデプロイが可能になるわけです。この例では、全体をネットワークの構成とインスタンスのデプロイに分割し、それぞれに専用のテンプレートを用意しています。

テンプレートを使う理由

テンプレートには次のような機能と利点があります。

  • テンプレートで宣言すると、クラウド リソース定義の管理やメンテナンス、再利用が簡単になります。テンプレートを再利用すれば、設定ファイルでリソースを最初から最後まで定義することを繰り返さなくて済みます。これにより、確実に統一された形でリソースを定義できます。
  • テンプレートの記述言語は Python と Jinja2 から選べます。Jinja2 のほうが Python よりもシンプルですが、そのぶん非力です。Jinja2 は、YAML と同じ構文を使いつつ、条件分岐やループを使用できるようにしたものです。それに対し、Python テンプレートは Jinja2 よりも強力で、テンプレートのコンテンツの生成方法をプログラムのように記述できます。
  • テンプレート変数を使用すると、テンプレートに渡せる値を設定ファイルで宣言できるので、テンプレートを再利用しやすくなります。テンプレートをいちいち書き直さなくても、設定ファイルごとにパラメータの値を変えられるのです。たとえば、本番インスタンスに対して別々のゾーンのテスト インスタンスをデプロイしたい場合は、ゾーン値を表す変数をテンプレートに宣言します。そして、実際のゾーン値は設定ファイルから渡すようにするわけです。
  • 環境変数も、さまざまなプロジェクトやデプロイでテンプレートを再利用するうえで便利です。環境変数は、デプロイしようとしているリソースではなく、プロジェクト ID やデプロイ名といったものを定義します。
テンプレート変数と環境変数はどのように使い分ければよいのでしょうか。たとえば、同じインスタンスを別々のゾーンにデプロイする 2 つのプロジェクトがあったとしましょう。この場合、環境変数のプロジェクト ID とデプロイ名でインスタンスを定義し、テンプレート変数で各ゾーンを設定します。

Deployment Manager によるサンプル リソースのデプロイ

ここでは、Jinja2 で記述された単純なテンプレートを使ってリソースをデプロイしてみましょう。

ネットワークのテンプレート ファイル

network.jinja ファイルはネットワークとそのサブネットを作ります。サブネットの名前と範囲は、設定ファイル net-config.yaml で宣言された変数によって定義されます。


サブネットの “for” ループは、“subnets” プロパティをすべて読み出すまで反復されます。後述するように、設定ファイルでは 2 つのサブネットを次の値で宣言しています。
サブネット名 IP の範囲
web 10.177.0.0/17
data 10.178.128.0/17

このネットワークは us-central1 リージョンにデプロイされますが、設定ファイル内の “region” プロパティを書き換えれば、テンプレート自体を書き換えずにデプロイ先を変更できます。

インスタンスのテンプレートファイル

instance.jinja ファイルはインスタンスのテンプレートであり、インスタンスのマシン タイプ、ゾーン、サブネットについては設定ファイルで定義されます。

設定ファイル

設定ファイル net-config.yaml は、上述したテンプレート ファイルを用いて、1 台の VM を持つネットワークを作成します。


設定の一部としてテンプレートを取り込むため、設定ファイルでは “imports” プロパティを使用しています。この設定ファイルの例では、15 行目から 17 行目において 2 つのテンプレートをインポートしています。

ネットワーク リソースは network.jinja テンプレートによって定義され、ウェブ インスタンス リソースは instance.jinja テンプレートによって定義されます。

その下の行では、各テンプレートに渡すテンプレート変数を宣言します。19 行目から 27 行目において、network.jinja テンプレートに渡されるネットワーク パラメータを定義しています。


28 行目から 33 行目では、インスタンスのテンプレート変数を定義しています。


設定したリソースをデプロイするには、gcloud コマンドか API を使用して、Deployment Manager に設定ファイル net-config.yaml を渡します。gcloud コマンドを使用する場合のコマンドラインは次のとおりです。

$ gcloud deployment-manager deployments create net --configuration net-config.yaml

すると、デプロイが成功したことを示す、次のようなメッセージが表示されるはずです。


デプロイは Google Cloud Console で確認できます。


instance.jinja で定義した名前がデプロイ後のインスタンスに使われていることに注意してください。



“deployment” 変数の値は、上述した gcloud コマンドの “create net” の部分で渡されています。この “net” がデプロイ名です。 デプロイの内容は、ネットワークを選択し、Compute Engine メニューから確認できます。


デプロイを削除するには、Cloud Console において Delete ボタンをクリックするか、次の gcloud コマンドを実行します。

$ gcloud deployment-manager deployments delete net

本当に削除してよいか、確認のプロンプトが表示されます。


次のステップ

Deployment Manager の基本をマスターすれば、このツールの応用範囲はもっと拡がります。ここで紹介したサンプル コードを使えば、たとえばオンプレミス環境と接続する VPN の実装など、より複雑なシナリオを組み立てることも可能です。GitHub には、他にも多くの Deployment Manager サンプル設定が掲載されています。

さらに一歩進んで、テンプレート モジュールやスキーマといった Deployment Manager の高度な機能を試してみるのもよいでしょう。得られた成果は、ぜひ私たちにお知らせください。


* この投稿は米国時間 11 月 21 日、Solutions Architect である Grace Mollison によって投稿されたもの（投稿はこちら）の抄訳です。

- Posted by Grace Mollison, Solutions Architect