Deployment Manager を使用するためのおすすめの方法

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

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

リソースの管理

デプロイでリソースを作成した後でリソースの変更が必要になった場合、Deployment Manager を使用します。Deployment Manager ではなく、GCP Console や gcloud を使用してリソースを変更すると、元のデプロイのリソースを変更するときにエラーが発生することがあります。

リソースを削除せずにデプロイからリソースを削除する場合は、次の手順に従います。

  1. デプロイ構成で、リソースの定義を削除します。
  2. デプロイメントを更新します。gcloud コマンドに --delete-policy ABANDON を追加します。これにより、デプロイメントとリソースの関連付けが解除され、GCP Console や gcloud でリソースを変更できるようになります。
Compute Engine インスタンスがデプロイされていて、そのインスタンスに永続ディスクを接続する場合は、インスタンスとは別にディスクを定義すると管理が簡単になります。たとえば次のデプロイメントでは、インスタンス example-instance とは別にディスク example-disk が定義されています。ディスクを接続するため、構成にディスクへの参照があります。

    resources:
    # instance
    - name: example-instance
      type: compute.v1.instance
      properties:
        disks:
          - type: PERSISTENT
            source:$(ref.example-disk.selfLink)
   # disk
   - name: example-disk
     type: compute.v1.disk
     properties:
       zone: us-central1-a
       sizeGb: 10
       type: ...
    

Deployment Manager を使用して限定公開の Google Kubernetes Engine(GKE)クラスタの作成および管理を行う場合は、デプロイメントで次の privateClusterConfigipAllocationPolicy オプションを設定します。


     privateClusterConfig:
        enablePrivateNodes: true
        enablePrivateEndpoint: true
        #  Configure the IP range for the hosted master network
        masterIpv4CidrBlock: IP_RANGE
      ipAllocationPolicy:
        useIpAliases: true
        createSubnetwork: true
    

GKE で限定公開クラスタを作成する場合の要件とその他の考慮事項については、限定公開クラスタの設定をご覧ください。

テンプレートの作成

テンプレートの定義を迅速に行うには、Cloud Foundation Toolkit プロジェクトから、本番環境で使用できるサンプル テンプレートを利用してください。
複数の環境を作成するなど、複雑なインフラストラクチャ要件がある場合は、大規模な Deployment Manager の使用にあるチュートリアルとサンプルをご覧ください。
Python を使用してテンプレートを作成します。テンプレートを作成するには Python または Jinja2 を使用できます。Jinja のほうが簡単に使用できますが、Python を使用すると、より柔軟なデプロイが可能になります。たとえば、複数のリソースを複数の環境に分散できます。
1 つのタイプのみを使用するように構成ファイル(YAML ファイル)を構成し、そのタイプとして最上位テンプレートを使用して、他のすべてのテンプレートを呼び出します。この方法では、一連のテンプレートを簡単に複合タイプに変更できます。
スキーマ ファイルを使用します。スキーマは、特定のテンプレートを使用するために構成ファイルが従うべき一連のルールを定義します。スキーマを定義し、その中で定義された要件を他のユーザーが確認できるようにすることで、ユーザーはそれぞれのテンプレートで設定可能なプロパティや必要なプロパティを簡単に理解できます。これにより、テンプレートの詳細を調べなくても構成を使用できるようになります。少なくとも、最上位テンプレートのスキーマ ファイルを定義します。
テンプレートのプロパティ出力を使用します。プロパティと出力を使用すると、ゾーン、マシンサイズ、マシン数、アプリケーションの状態(テスト、本稼働、ステージング)などの変数をテンプレートに渡して、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 で利用可能なテンプレートを出発点として使用して、プロジェクトの作成を自動化できます。

継続的インテグレーション(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 のドキュメント