デプロイを更新する

デプロイを作成した後、アプリケーションやサービスの変化に合わせてデプロイを更新できます。Deployment Manager を使用すると、次の方法でデプロイを更新できます。

  • デプロイに対してリソースの追加や削除を行います。
  • デプロイ内の既存リソースのプロパティを更新します。

さまざまな変更を組み合わせて、単一の更新として実行できます。たとえば、既存のリソースのプロパティを変更できます。同じリクエストで新しいリソースを追加することもできます。デプロイを更新するには、次の操作を行います。

  1. 変更内容に合わせて構成ファイルを変更、作成します。
  2. 必要に応じて、更新で使用するポリシーを選択するか、デフォルト ポリシーを使用します。
  3. Deployment Manager に更新リクエストを送ります。

始める前に

更新を準備する

デプロイを更新する前に、次のガイドラインに沿って更新を準備します。

  • プロジェクトに新しいリソースを追加するためにデプロイを更新する場合、追加するリソースがすでに存在しているかどうか確認してください。

    デフォルトでは、追加するリソースがすでにプロジェクト内に存在する場合、それらのリソースがデプロイによって取得され、新しいリソースは作成されません。既存のリソースを取得したくない場合は、更新で使用するポリシーを変更する必要があります。

    デプロイを更新する際に使用できるポリシーについては、リソースの追加ポリシーをご覧ください。

  • デプロイを更新した結果としてリソースが置き換えられる場合は、その依存関係を確認してください。

    デプロイのリソースを置き換える場合は、最初に、そのリソースを削除した結果としてデプロイ サイクルが引き起こされないことを確認する必要があります。デプロイ サイクルが発生するのは、あるリソースが自分自身に、直接か間接かを問わず依存しているときです。たとえば、次のデプロイがあるとします。

    resources:
- name: vm-a
  properties:
    zone: us-central1-f
    ...
    metadata:
      dependsOn:
      - vm-depends-on

# The second VM
- name: vm-depends-on
  properties:
    zone: $(ref.vm-a.zone)
    ...

    このデプロイでは、vm-a の dependsOn ステートメントで、vm-depends-on を vm-a よりも前に作成することを要求しています。しかし、vm-depends-on では vm-a のゾーンへの参照が使用されています。つまり、vm-a が vm-depends-on よりも前に作成されている必要があります。このようなシナリオでは、依存関係がループしているため、デプロイに失敗します。

    あるリソースが、他のリソースに依存すると同時に他のリソースから依存されている場合は、そのリソースを置き換えるとデプロイ サイクルが発生する可能性があります。

    たとえば、あるデプロイに disk-a という永続ディスク、vm-a という VM、ig-a というインスタンス グループがあるとします。vm-a の構成の中には disk-a への参照があり、ig-a の構成の中には vm-a への参照があります。更新された構成で、vm-a を削除し、vm-b と置き換えることもできます。このようなシナリオでは、vm-a と vm-b の依存関係を解決するとデプロイ サイクルが発生する可能性があり、デプロイに失敗します。

    依存関係のチェーン内のリソースを置き換えるときのデプロイ サイクルを回避するには、次のいずれかを行います。

    • 置き換え対象のリソースの依存関係を削除します。それには、dependsOn 句を削除するか、他のリソースへの参照を削除または変更します。このような変更を反映してデプロイを更新した後に、別の更新を行ってリソースを置き換えます。

    • 依存リソースのチェーンを削除し、デプロイを更新します。その後の更新で、使用したいリソースを再作成します。

  • 更新をサポートする API があることを確認してください。

    Deployment Manager は、各サービスの API を使用してデプロイの作成や変更を行います。Deployment Manager でリクエストが完了しているかどうかを確認するには、更新するリソースの Cloud Platform サービスの API ドキュメントをご覧ください。

    たとえば、デプロイメントの BigQuery データセットを更新する場合は、使用可能なメソッドを Datasets API リファレンスで確認します。このメソッドの update メソッドを使用すると、Deployment Manager でデータセットを更新できます。

    一部の API には、リソースを更新できるカスタム メソッドがあります。たとえば、Compute Engine の場合は、インスタンスのメタデータを更新するためのカスタム メソッドとして setMetadata が用意されています。この場合、Deployment Manager はカスタム メソッドの使用を試みます。

  • 更新するリソースが変更可能かどうか確認してください。

    作成後に更新できないリソースもあります。リソースが変更不可かどうか確認するには、そのリソースの API リファレンスをご覧ください。通常、変更不可のリソースには、リソースのプロパティを更新する update API メソッドやカスタム メソッドはありません。

制限事項

  • デプロイごとに、同時に 1 つの更新を適用できます。更新が実行中の場合は、現在の更新を停止してから、新しい更新を開始する必要があります。

  • Deployment Manager を使用せずにデプロイメント内のリソースを変更した場合（Google Cloud コンソールや gcloud で更新した場合）、更新でリソースを変更するときにエラーや予期しない問題が発生する可能性があります。

構成を変更する

既存の構成を保存している場合は、構成内容を変更して、更新リクエストで使用します。

既存の構成を保存していない場合は、新しい構成を作成します。構成ファイルの作成手順については、構成ページをご覧ください。

Deployment Manager は、更新リクエストで指定された構成と以前のマニフェストを比較し、その違いに基づいてデプロイメントを更新します。

例として、2 つの構成を下記の表に示します。一方は既存のデプロイを記述するもので、もう一方は更新後のデプロイの状態を記述しています。更新された構成が提供されると、Deployment Manager は差異を検証し、該当する更新を実行します。

この例では、既存のインスタンス リソースを更新し、カスタム メタデータの一部を追加して、新しい仮想マシンリソースをデプロイに追加します。太字の部分は、テンプレート間の違いを表します。

現在のテンプレート 更新後のテンプレート 
resources:
- name: vm-created-by-cloud-config
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: machine-type-url
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        diskName: disk-created-by-cloud-config
        sourceImage: image-url
    networkInterfaces:
    - network: network-url
 
resources:
- name: vm-created-by-cloud-config
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: machine-type-url
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      initializeParams:
        diskName: disk-created-by-cloud-config
        sourceImage: image-url
    networkInterfaces:
    - network: network-url
    metadata:
      items:
      - key: 'foo'
        value: 'bar'
      - key: 'dev'
        value: 'vm'

- name: a-new-vm
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: machine-type-url
      - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: false
      initializeParams:
        diskName: a-new-vm-disk
        sourceImage: image-url
    networkInterfaces:
    - network: network-url

（省略可）更新に使用するポリシーを決める

次に、更新に使用するポリシーを決めます。ポリシーにより、デプロイメント更新時のリソースの更新方法が決まります。

Deployment Manager は、次のデフォルト ポリシーを使用します。

  • リソース追加用のデフォルト ポリシーは CREATE_OR_ACQUIRE です。
  • リソース削除用のデフォルト ポリシーは DELETE です。
  • リソース更新用のデフォルト ポリシーは UPDATE です。

各ポリシーの詳細については、以降のセクションをご覧ください。

リソース追加用のポリシー

リソースを追加する場合、新しいリソースを作成してデプロイに追加するか、既存のリソースを取得するかを選択できます。

  • CREATE_OR_ACQUIRE - （デフォルト） Deployment Manager は、プロジェクト内に存在するリソースを取得します。リソースが存在しない場合は、リソースを作成します。リソースを取得するため、Deployment Manager は、作成するリソースのプロパティの構成を確認します。同じプロパティのリソースがすでに存在する場合、Deployment Manager はそのリソースをデプロイの一部として取得します。

    Deployment Manager が確認するプロパティは、作成するリソースのタイプによって異なります。たとえば、次のようなものがあります。

    • リソースの name
    • リソースの type
    • リソースの zone または region（該当する場合）

    プロパティは、リソースに対する GET API リクエストの URL の一部になります。Deployment Manager がリソースの取得に使用するプロパティについては、リソースの GET メソッドに関する API ドキュメントをご覧ください。たとえば、Compute Engine インスタンスの場合、instances.get メソッドのリクエスト URL には、resourceId（構成内の name）、zone、project が含まれます。

  • CREATE - Deployment Manager は、存在しないリソースを作成します。プロジェクトにすでに存在するリソースが構成に含まれていると、デプロイに失敗します。

  • ACQUIRE - Deployment Manager は、CREATE_OR_ACQUIRE と同じ条件で既存のリソースを取得します。

    プロジェクト内にすでに多数のリソースが含まれている場合、それらのリソースを 1 つのデプロイとして管理するには、ACQUIRE ポリシーを使用します。

    リソースを作成する場合と同じく、テンプレートまたは構成で、リソースの必須プロパティを指定する必要があります。プロジェクトに存在しないリソースが構成に含まれていると、デプロイに失敗します。

リソース削除用のポリシー

リソース削除用のポリシーとして次のいずれかを指定します。

  • DELETE - （デフォルト）対象リソースへのすべての参照をデプロイメントから削除し、基盤リソースを削除します。この操作を元に戻すことはできませんが、同じプロパティを持つ新しいリソースを再作成できます。

  • ABANDON - 対象リソースへのすべての参照をデプロイから削除しますが、基盤リソースは削除しません。たとえば、インスタンスを放棄した場合、デプロイからは削除されますが、インスタンス自体は存在しているため使用できます。

    ABANDON ポリシーは、リソース全体を削除する場合にのみ適用されます。リソースのプロパティを削除する場合や、リソースを新しいプロパティで更新する場合は適用されません。リソースのプロパティを保持するには、更新された構成に元のすべてのプロパティを持つリソースを含める必要があります。新しい構成ファイルを使用して更新する場合は、元の構成からリソースの定義をコピーすることをお勧めします。

既存リソース更新用のポリシー

既存リソースを更新するときに UPDATE メソッドが存在すると、Deployment Manager はこのメソッドを使用します。

カスタム メソッドが存在する場合、Deployment Manager はカスタム メソッドを使用します。Deployment Manager では、動詞 set を使用するカスタム メソッドがサポートされています。たとえば、setMetadata() は有効なカスタム メソッドですが、addAccessConfigs() は違います。

（省略可）更新後の構成をプレビューする

Google Cloud CLI や API を使用すると、変更を commit する前に更新をプレビューできます。Deployment Manager サービスは、完全な構成を展開して "shell" リソースを生成し、構成をプレビューします。

構成のプレビュー時、Deployment Manager は、実際のリソースのインスタンス化は行いません。そのため、commit する前にデプロイを確認できます。

gcloud

Google Cloud CLI で、--preview パラメータを使用して update リクエストを送信します。

gcloud deployment-manager deployments update example-deployment \
    --config configuration-file.yaml \
    --preview

API

API で、既存のデプロイに対する PUT() リクエストを作成し、preview=true クエリ パラメータを指定します。リクエスト本文には intent フィールド、target フィールド、name フィールドを含める必要があります。URL とリクエスト本文の両方でデプロイ名を指定する必要があります。

たとえば、次の API リクエストはシンプルな更新をプレビューします。

PUT https://www.googleapis.com/deploymentmanager/v2/projects/myproject/global/deployments/example-deployment?preview=true

{
 "target": {
  "config": {
   "content": "resources:\n- name: vm-created-by-cloud-config\n  type: compute.v1.instance\n  properties:\n    zone: us-central1-a\n    machineType: https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/machineTypes/n1-standard-1\n    disks:\n    - deviceName: boot\n      type: PERSISTENT\n      boot: true\n      autoDelete: true\n      initializeParams:\n        diskName: disk-created-by-cloud-config\n        sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-9-stretch-v20180716\n    networkInterfaces:\n    - network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default"
  }
 },
 "name": "example-deployment"
}

デプロイのプレビュー後、構成と preview クエリ パラメータの部分を除外して、同じ PUT() リクエストを実行することで、構成を完全にデプロイできます。Deployment Manager は、最後のプレビューを使用して更新を実行します。次に例を示します。

gcloud deployment-manager deployments update example-deployment

更新リクエストの作成方法については、更新リクエストの作成をご覧ください。

更新を続行しない場合は、別の更新またはプレビュー リクエストの前に現在のプレビューをキャンセルします。

プレビューをキャンセルする

更新のプレビュー後、更新を続行するかどうか決める必要があります。続行しない場合、あるいは別の構成ファイルでデプロイを更新する場合は、現在のプレビューをキャンセルします。

gcloud

Google Cloud CLI で、deployments cancel-preview リクエストを行います。

gcloud deployment-manager deployments cancel-preview my-first-deployment

API

API で cancelPreview メソッドに対する PUT() リクエストを作成し、最新のデプロイ フィンガープリントを指定します。フィンガープリントは、更新リクエストごとにランダムに生成される値です。更新中のエラーを防ぐため、リクエストに最新のフィンガープリントを指定します。

デプロイメントの最新のフィンガープリントを取得するには、get() メソッドを使用してデプロイメントを取得し、フィンガープリント値を見つけます。フィンガープリント値は次のようになります。

"fingerprint": "nU2v7bzeA7gBBI8bdbtmFg=="

cancelPreview() リクエストは次のようになります。

POST https://www.googleapis.com/deploymentmanager/v2/projects/myproject/global/deployments/example-deployment/cancelPreview

{
 "fingerprint": "nU2v7bzeA7gBBI8bdbtmFg=="
 }

更新リクエストを行う

更新を行うには:

gcloud

Google Cloud CLI で deployments update サブコマンドを使用して新しい構成を指定します。必要に応じて、更新ポリシーを指定することもできます。

gcloud deployment-manager deployments update my-first-deployment \
    --create-policy POLICY \
    --delete-policy POLICY

以前に構成をプレビューした場合は、構成の部分を省略します。Deployment Manager は、最後にプレビューした構成を使用して更新を実行します。

gcloud deployment-manager deployments update my-first-deployment

API

API で update リクエストを作成し、最新のデプロイメント フィンガープリントを指定します。フィンガープリントは、更新リクエストごとにランダムに生成される値です。更新中のエラーを防ぐため、リクエストに最新のフィンガープリントを指定します。

デプロイメントの最新のフィンガープリントを取得するには、get() メソッドを使用してデプロイメントを取得し、フィンガープリント値を見つけます。フィンガープリント値は次のようになります。

"fingerprint": "nU2v7bzeA7gBBI8bdbtmFg=="

次に、新しい構成と更新ポリシーとともに、フィンガープリントをリクエストに指定します。以前に構成のプレビューを行っていた場合は、構成と更新ポリシーの部分を除外します。Deployment Manager は、最後にプレビューした構成を使用して更新を実行します。

URL とリクエスト本文の両方でデプロイ名を指定する必要があります。

PUT https://www.googleapis.com/deploymentmanager/v2/projects/myproject/global/deployments/example-deployment?createPolicy=ACQUIRE&deletePolicy=ABANDON

{
 "target": {
  "config": {
   "content": "resources:\n- name: vm-created-by-cloud-config\n  type: compute.v1.instance\n  properties:\n    zone: us-central1-a\n    machineType: https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/machineTypes/n1-standard-1\n    disks:\n    - deviceName: boot\n      type: PERSISTENT\n      boot: true\n      autoDelete: true\n      initializeParams:\n        diskName: disk-created-by-cloud-config\n        sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-9-stretch-v20180716\n    networkInterfaces:\n    - network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default"
  }
 },
 "name": "example-deployment",
 "fingerprint": "nU2v7bzeA7gBBI8bdbtmFg=="
}

更新を停止する

stop() メソッドを使用すると、進行中の更新を停止できます。 更新の進行はキャンセルされますが、すでに実行済みの変更については元に戻すことはできません。

プレビューをキャンセルする場合は、プレビューをキャンセルするをご覧ください。

gcloud

Google Cloud CLI で、deployments stop リクエストを行います。

gcloud deployment-manager deployments stop my-first-deployment

API

API で stop メソッドに対する POST() リクエストを作成し、最新のフィンガープリント プロパティを指定します。フィンガープリントは、更新リクエストごとにランダムに生成される値です。変更の競合を防ぐため、リクエストでは最新のフィンガープリントを指定して、楽観的ロックを実行し、一度に 1 つの更新のみを実行するようにする必要があります。

デプロイメントの最新のフィンガープリントを取得するには、get() メソッドを使用してデプロイメントを取得し、フィンガープリント値を見つけます。フィンガープリント値は次のようになります。

"fingerprint": "nU2v7bzeA7gBBI8bdbtmFg=="

リクエストは次のようになります。

POST https://www.googleapis.com/deploymentmanager/v2/projects/myproject/global/deployments/example-deployment/stop

{
 "fingerprint": "nU2v7bzeA7gBBI8bdbtmFg=="
 }

次のステップ