Deployment Manager を使用するためのベスト プラクティス

このページでは、Deployment Manager を使用してデプロイを作成するためのベスト プラクティスについて説明します。このページは、Deployment Manager に精通しているユーザーを対象としています。Deployment Manager の使用方法は記載されていません。

Deployment Manager を初めて使用する場合は、代わりにクイックスタートをお試しください。

テンプレートの作成

❑  
Python を使用してテンプレートを作成します。テンプレートを作成するには Python または Jinja2 を使用できます。Jinja は簡単に始めることができますが、Python はより柔軟かつ効率的であり、テンプレートの作成におすすめの方法です。
❑  
1 つのタイプのみを使用するように設定ファイル(YAML ファイル)を構成し、そのタイプとして最上位テンプレートを使用して、他のすべてのテンプレートを呼び出します。このプラクティスには次のようなメリットがあります。
  • 一連のテンプレートを複合タイプに簡単に変更できます。
  • gcloud ツールを使用して API を簡単にスクリプト化することができます。その際、--config パラメータを使用して最上位テンプレートを渡した後、--properties フラグを使用してテンプレート プロパティを指定できます。
❑  
スキーマ ファイルを使用します。少なくとも、最上位テンプレートのスキーマ ファイルを定義します。スキーマは、特定のテンプレートを使用するために設定ファイルが満たすべき一連のルールを定義したものです。スキーマを定義し、その中で定義された要件を他のユーザーが確認できるようにすることで、ユーザーはそれぞれのテンプレートで設定可能な、または必要なプロパティを簡単に理解できます。これにより、ユーザーはテンプレートの詳細を調べなくても設定を簡単に使用できるようになります。
❑  
テンプレートのプロパティ出力を使用します。プロパティと出力を使用すると、ゾーン、マシンサイズ、マシン数、アプリケーションの状態(テスト、本稼働、ステージング)などの変数をテンプレートに渡して、IP アドレスや selfLink などの出力値を VM インスタンスに戻すことができます。プロパティと出力を使用すると、基礎となるテンプレートを変更せずに、柔軟にテンプレートを再利用できるようになります。
❑  
組み立て可能ないくつかの設定を作成します。単一の設定ファイルを作成するのではなく、設定ファイルにインポートされる個別のテンプレート ファイルを使用します。これにより、設定作業を管理しやすくなります。
❑  
設定をいくつかの論理単位に分割します。たとえば、データベースやバケットなどのステートフル サービス用と、フロントエンド インスタンスなどのより過渡的なサービス用として別々の設定を作成します。
❑  
参照を使用します。参照は、リソースの selfLink、IP アドレス、システム生成 ID など、リソースが作成されるまで定義されない値に使用されます。参照がなければ、Deployment Manager はすべてのリソースを並行して作成するため、依存リソースが正しい順序で作成される保証はありません。参照を使用すると、リソースの作成順序が固定されます。
❑  
デプロイをプレビューして、デプロイの更新による影響を評価します。設定のプレビュー時に、Deployment Manager は実際のリソースをインスタンス化する代わりに、フル設定を拡張して「シェル」リソースを作成します。これにより、デプロイを commit する前に変更内容を確認できます。
❑  
特定のリソースの API メソッドを確認して、更新による影響を把握します。デプロイの更新時に更新ポリシーを設定することにより、Deployment Manager がそれぞれの更新をどのように適用するかを制御できます。
❑  
リソース用のラベルを使用します。定義するリソースがラベルをサポートしている場合は、そのようなリソースにラベルを付けます。ラベルは、さまざまなデプロイに属しているリソースを分類するのに役立ちます。また、リソースが本番環境とテスト環境のどちらをサポートしているかなど、リソースがどの段階にあるかを区別する手段にもなります。

権限

デフォルトで、Deployment Manager は Google API サービス アカウントの認証情報を使用して他の API を認証します。Google API サービス アカウントは、内部の Google プロセスを自動的に実行するように特別に設計されています。

他のユーザーに Deployment Manager プロジェクトへのアクセスを許可するには、Deployment Manager を使用するための適切な権限を持つ IAM 役割をユーザーに付与する必要があります。事前定義の IAM 役割がいくつか用意されており、これらを使用すると Deployment Manager を呼び出すためのユーザーのアクセス権を決定できます。

❑  
IAM 役割を使用して、Deployment Manager を使用するためにユーザーに与えられる権限を制限します。
❑  
ユーザーが Deployment Manager によって作成されたリソースにアクセスできるようにするには、リソースの使用に必要な役割をユーザーに付与しますが、リソースを直接デプロイするための権限は付与しないでください。
❑  
メンバーに所有者役割を付与すると、そのメンバーは IAM ポリシーを変更できるようになります。このため、そのメンバーに IAM ポリシーを管理する正当な理由がある場合にのみ、所有者役割を付与してください。これは、機密性の高いアクセス制御データがポリシーに含まれているためです。ポリシーを管理するユーザー数を最小限に抑えることで、必要となる監査が簡略化されます。
❑  
Deployment Manager は、Google API サービス アカウントを使用して、リソースの作成と管理を行います。プロジェクトやカスタム IAM 役割などの重要なリソースを Deployment Manager で管理する場合には、デフォルトの Google API サービス アカウントに追加の IAM 役割を割り当てる必要があります。たとえば、Deployment Manager でカスタム IAM 役割の作成と管理を行う場合には、Google API サービス アカウントに役割管理者の役割を割り当てます。

Google API サービス アカウントの概要については、Google が管理するサービス アカウントをご覧ください。

役割をサービス アカウントに割り当てる手順については、サービス アカウントへの役割の付与をご覧ください。

自動化

プロジェクトの作成に加えて、プロジェクト内に含まれるリソースの作成も自動化することを検討してください。これにより、プロジェクト プロビジョニングに infrastructure-as-code アプローチを採用できます。このアプローチには、次のような多くのメリットがあります。

  • Google Cloud Platform リソースへのアクセスが必要なチームにプロジェクトを提供する際に、企業要件を適用できます。
  • 事前定義のプロジェクト環境一式が揃っているため、プロビジョニングをすばやく簡単に行うことができます。
  • バージョン管理を使用して、基本プロジェクト設定を管理できます。
  • 再現可能で一貫性のあるプロジェクト設定のデプロイが保証されます。
  • 自動プロビジョニング プロセスの一部としてプロジェクト作成を組み込むことができます。
❑  
GitHub で利用可能な Deployment Manager テンプレートを出発点として使用して、プロジェクトの作成を自動化できます。

継続的インテグレーション(CI) / 継続的デプロイ(CD)

CI / CD パイプラインの一部として Deployment Manager を使用します。

❑  
テストおよび QA プロジェクト全体を作成および削除するために CI / CD パイプラインを使用しないでください。
  • 余分なコストがかかる VM インスタンスやリソースを破棄するよう選択できますが、このようなリソースを削除するとビルド パイプラインの完成までに長い時間を要する可能性があるため、再作成に時間がかかる再利用可能なアセットを残すことを考慮してください。ネットワーク、サブネット、およびファイアウォール ルールを設定するにはコストがかかりません。
  • プロジェクトの削除を実行しても、それが完全に削除されるまで数日間はプロジェクト割り当ての一部として残ることに注意してください。つまり、数週間はプロジェクト名を再利用できません。
  • Deployment Manager を使用すると、プロジェクトからリソースを簡単に削除できるため、リソース割り当てを超過しなくなります。
❑  
Deployment Manager を使用して、プロジェクト設定とネットワーク設定のステートフルな部分を作成し、それらを初期設定の一部として CI / CD プロセスの外部にデプロイします。テストが終了したら、パイプラインの一部としてデプロイしたステートレス リソースのみを含むデプロイを削除できます。
❑  
CI / CD プロセスの一部として、テストおよび QA プロジェクトにリソースをデプロイするための個別の設定を使用します。テストが終了したら、Deployment Manager を使用して、テストおよび QA プロジェクトからリソースを削除できます。
デプロイをテストします。リソース プロビジョニングを CI / CD パイプラインの一部として組み込む機能を持つ Deployment Manager を使用すると、プロジェクト設定をコードとして扱うことができ、現在の本番環境、または密かにテストに変更を適用した現在の環境の一貫性のあるコピーを簡単に再現できます。
❑  
バージョン管理を使用します。デプロイの開発プロセスの一部としてバージョン管理システムを使用すると、次のことが可能になります。
  • 正常に機能することがわかっている、以前の設定に戻すことができます。
  • 変更内容の監査証跡が得られます。
  • 構成を継続的デプロイ システムの一部として使用できます。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud Deployment Manager のドキュメント