デプロイを更新する

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

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

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

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

始める前に

更新を準備する

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

  • 新しいリソースをプロジェクトに追加するようにデプロイを更新する場合は、リソースが存在していないことを確認してください。

    追加するリソースがプロジェクトに存在していると、そのリソースが取得され、新しいリソースは作成されません。既存のリソースを取得しない場合は、構成でリソースの properties セクションを変更する必要があります。

    リソースのタイプによって、変更するプロパティが異なります。ほとんどのリソースでは、name または zone プロパティを変更します。変更可能なプロパティの完全なリストについては、リソースの API リファレンスと API の get メソッドをご覧ください。

    デプロイの更新中にリソースを取得する方法については、リソースの追加ポリシーをご覧ください。

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

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

    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-adependsOn ステートメントで、vm-depends-onvm-a よりも前に作成することを要求しています。しかし、vm-depends-on では vm-a のゾーンへの参照が使用されています。つまり、vm-avm-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 は、更新リクエストで提供された構成と既存のマニフェストを比較し、その差異を利用してデプロイを更新します。

例として、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 は、このプロパティを使用して正しいリソースを取得します。

ACQUIRE - Deployment Manager は、既存のリソースを検索して、デプロイに追加します。リソースが存在しない場合、デプロイは失敗します。作成時と同様、このリソースの必須プロパティを構成で指定する必要があります。Deployment Manager は、このプロパティを使用して正しいリソースを取得します。

異なる GCP Console プロジェクトに属するリソースは追加できません。

取得したリソースのプロパティを更新する場合は、まず、デプロイを更新してリソースを取得し、別の更新でリソースのプロパティを変更します。

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

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

DELETE - (デフォルト)対象リソースへのすべての参照をデプロイから削除し、基盤リソースを削除します。この処理を元に戻すことはできませんが、同じプロパティを持つ新しいリソースを作成するよう選択できます。

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

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

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

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

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

gcloud コマンドライン ツールや API を使用すると、変更を commit する前に更新をプレビューできます。Deployment Manager サービスは、完全な構成を展開して "shell" リソースを生成し、構成をプレビューします。

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

gcloud

gcloud コマンドライン ツールでは、--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-7-wheezy-v20140619\n    networkInterfaces:\n    - network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default"
  }
 },
 "name": "example-deployment"
}

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

gcloud deployment-manager deployments update example-deployment

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

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

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

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

gcloud

gcloud コマンドライン ツールで、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

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

gcloud deployment-manager deployments update my-first-deployment \
    --config my-updated-config.yaml \
    --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-7-wheezy-v20140619\n    networkInterfaces:\n    - network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default"
  }
 },
 "name": "example-deployment",
 "fingerprint": "nU2v7bzeA7gBBI8bdbtmFg=="
}

更新を停止する

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

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

gcloud

gcloud コマンドライン ツールで、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=="
 }

次のステップ

このページは役立ちましたか?評価をお願いいたします。

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

Cloud Deployment Manager のドキュメント