このページでは、Google Cloud Deployment Manager を使用してデプロイを作成するためのベスト プラクティスについて説明します。このページは、Deployment Manager に精通しているユーザーを対象としています。Deployment Manager の使用方法は記載されていません。
Deployment Manager を初めて使用する場合は、代わりにクイックスタートをお試しください。
リソースの管理
|
❑
デプロイでリソースを作成した後でリソースの変更が必要になった場合、Deployment Manager を使用します。Deployment Manager ではなく、Google Cloud コンソールや
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）クラスタの作成および管理を行う場合は、デプロイメントで次の
privateClusterConfig:
enablePrivateNodes: true
enablePrivateEndpoint: true
# Configure the IP range for the hosted master network
masterIpv4CidrBlock: IP_RANGE
ipAllocationPolicy:
useIpAliases: true
createSubnetwork: true
GKE で限定公開クラスタを作成する場合の要件とその他の考慮事項については、限定公開クラスタの設定をご覧ください。 |
デプロイでの認証情報の追加
|
❑
Deployment Manager は、認証情報に関連する一部のフィールドを、YAML 構成のプロパティから削除します。この削除は、プロパティのキーに基づいて行われます。次の例に、そのような 1 件の削除を示します。
# Config provided to Deployment Manager
resources:
- name: example-resource
type: gcp-types/service-v1:sample-type-with-password
properties:
zone: us-central1-a
username: test-user
password: hunter2
# Config as surfaced by Deployment Manager
resources:
- name: example-resource
type: gcp-types/service-v1:sample-type-with-password
properties:
zone: us-central1-a
username: test-user
password: (redacted)
|
|
❑
デプロイで認証情報を Jinja または Python テンプレートに含めると、認証情報は、作成された拡張構成とレイアウト ファイルから除外されますが、元のインポート ファイルではまだ表示されます。そのため、シークレットを保持する予定のすべての認証情報を最上位の YAML 構成に配置することを強くおすすめします。テンプレート プロパティを使用することで、そこから参照できます。
|
|
❑
YAML ファイルまたはアイテムのリスト内の Key-Value ペアに含まれる認証情報は、次の例のように、編集されません。そのため、Deployment Manager に、YAML ファイルまたはアイテムのリスト内の Key-Value ペアとして認証情報を提供しないことを強くおすすめします。
# Not a valid instance configuration, used solely for demonstration
resources:
- name: example-resource
type: gcp-types/compute-v1:instances
properties:
zone: us-central1-a
disks:
- autoDelete: true
boot: true
# Will not be redacted
password: hunter2
|
テンプレートの作成
|
❑
テンプレートの定義を迅速に行うには、Cloud Foundation Toolkit プロジェクトから、本番環境で使用できるサンプル テンプレートを利用してください。
|
|
❑
複数の環境を作成するなど、複雑なインフラストラクチャ要件がある場合は、大規模な Deployment Manager の使用にあるチュートリアルとサンプルをご覧ください。
|
|
❑
Python を使用してテンプレートを作成します。テンプレートを作成するには Python または Jinja2 を使用できます。Jinja のほうが簡単に使用できますが、Python を使用すると、より柔軟なデプロイが可能になります。たとえば、複数のリソースを複数の環境に分散できます。
|
|
❑
|
|
❑
スキーマ ファイルを使用します。スキーマは、特定のテンプレートを使用するために構成ファイルが従うべき一連のルールを定義します。スキーマを定義し、その中で定義された要件を他のユーザーが確認できるようにすることで、ユーザーはそれぞれのテンプレートで設定可能なプロパティや必要なプロパティを簡単に理解できます。これにより、テンプレートの詳細を調べなくても構成を使用できるようになります。少なくとも、最上位テンプレートのスキーマ ファイルを定義します。
|
|
❑
テンプレートのプロパティと出力を使用します。プロパティと出力を使用すると、ゾーン、マシンサイズ、マシン数、アプリの状態（テスト、本番環境、ステージング）などの変数をテンプレートに渡して、IP アドレスや
selfLink VM インスタンスなどの出力値を VM インスタンスに戻すことが可能です。プロパティと出力を使用すると、基礎となるテンプレートを変更せずに、柔軟にテンプレートを再利用できるようになります。
|
|
❑
メイン構成ファイルにインポートされる個別のテンプレート ファイルを使用します。これにより、構成作業を管理しやすくなります。
|
|
❑
構成をいくつかの論理単位に分割します。たとえば、データベースやバケットなどのステートフル サービス用と、フロントエンド インスタンスなどのより過渡的なサービス用として別々の構成を作成します。
|
|
❑
参照を使用します。参照は、リソースの
selfLink、IP アドレス、システム生成 ID など、リソースが作成されるまで定義されない値に使用されます。参照がなければ、Deployment Manager はすべてのリソースを並行して作成するため、依存リソースが正しい順序で作成される保証はありません。参照を使用すると、リソースの作成順序が固定されます。
|
|
❑
デプロイをプレビューして、デプロイの更新による影響を評価します。構成のプレビュー時に、Deployment Manager は実際のリソースをインスタンス化する代わりに、フル構成を拡張して「シェル」リソースを作成します。これにより、デプロイを commit する前に変更内容を確認できます。
|
|
❑
特定のリソースの API メソッドを確認して、更新による影響を把握します。デプロイの更新時に更新ポリシーを設定することにより、Deployment Manager がそれぞれの更新をどのように適用するかを制御できます。
|
|
❑
リソース用のラベルを使用します。定義するリソースがラベルをサポートしている場合は、そのようなリソースにラベルを付けます。ラベルは、さまざまなデプロイに属しているリソースを分類するのに役立ちます。また、リソースが本番環境とテスト環境のどちらをサポートしているかなど、リソースがどの段階にあるかを区別する手段にもなります。
|
デプロイのサイズの管理
Deployment Manager は割り当て上限を条件として、多数のリソースで動作できます。デプロイの作成、更新、削除にかかる時間を短縮するには、個々のデプロイ内のリソースの数を減らします。
|
❑
リソースのグループが、そのグループ以外のリソースに依存しない場合、そのリソースのグループを別のデプロイに移動できます。たとえば、デプロイに複数のテンプレートが含まれている場合、各テンプレートを個別のデプロイとしてパッケージ化できる可能性があります。
|
|
❑
構成から不要なリソースを削除します。後でより多くのリソースが必要になった場合は、その時点のデプロイにさらにリソースを追加できます。
|
|
❑
必要に応じて、デプロイのリソース数を 1, 000 以下に制限します。
|
権限
デフォルトで、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 リソースへのアクセスが必要なチームにプロジェクトを提供する際に、企業要件を適用できます。
- 事前定義のプロジェクト環境一式が揃っているため、プロビジョニングをすばやく簡単に行うことができます。
- バージョン管理を使用して、基本プロジェクト構成を管理できます。
- 再現可能で一貫性のあるプロジェクト構成のデプロイが保証されます。
- 自動プロビジョニング プロセスの一部としてプロジェクト作成を組み込むことができます。
|
❑
GitHub で利用可能なテンプレートを出発点として使用して、プロジェクトの作成を自動化できます。
|
継続的インテグレーション（CI） / 継続的デプロイ（CD）
CI / CD パイプラインの一部として Deployment Manager を使用します。
|
❑
テストおよび QA プロジェクト全体を作成および削除するために CI / CD パイプラインを使用しないでください。
|
|
❑
Deployment Manager を使用して、プロジェクト構成とネットワーク構成のステートフルな部分を作成し、それらを初期設定の一部として CI / CD プロセスの外部にデプロイします。テストが終了したら、パイプラインの一部としてデプロイしたステートレス リソースのみを含むデプロイを削除できます。
|
|
❑
CI / CD プロセスの一部として、テストおよび QA プロジェクトにリソースをデプロイするための個別の構成を使用します。テストが終了したら、Deployment Manager を使用して、テストおよび QA プロジェクトからリソースを削除できます。
|
| デプロイをテストします。リソース プロビジョニングを CI / CD パイプラインの一部として組み込む機能を持つ Deployment Manager を使用すると、プロジェクト構成をコードとして扱うことができ、現在の本番環境、または密かにテストに変更を適用した現在の環境の一貫性のあるコピーを簡単に再現できます。 |
|
❑
バージョン管理を使用します。デプロイの開発プロセスの一部としてバージョン管理システムを使用すると、次のことが可能になります。
|