Patch を使用して、仮想マシン(VM)インスタンスのグループ全体にオペレーティング システムのパッチを適用できます。
VM にパッチを適用する手順は次のとおりです。
準備
- OS Config の割り当てを確認します。
-
まだ設定していない場合は、認証を設定します。認証とは、Google Cloud サービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のように Compute Engine に対する認証を行います。
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- Set a default region and zone.
- 1 つの Google Cloud プロジェクト内の VM に対してのみ、パッチジョブをデプロイして実行できます。VM が共有 VPC 内にある場合でも、Google Cloud プロジェクト間でパッチジョブを実行することはできません。ただし、プロジェクト間でパッチ コンプライアンス データを表示することはできます。
- マネージド インスタンス グループ(MIG)の一部である VM にパッチを適用する場合は、次の制限が適用されます。
- MIG が VM を修復すると、インスタンス テンプレートに基づいて VM が再作成されます。これにより、パッチが適用されていない状態に VM が戻る可能性があります。
- VM にパッチを適用すると、自動スケーリングが有効になっている MIG で予期しない結果が発生する可能性があります。オートスケーラーは、負荷が低下するとパッチ適用済みの VM を削除し、負荷が増加すると、MIG のインスタンス テンプレートを使用して、パッチなしで新しい VM を作成します。たとえば、平均 CPU 使用率が自動スケーリングに指定した目標使用率よりも低い場合、MIG はスケールイン中にパッチ適用済みの VM の一部を削除できます。
- すべての VM に VM Manager を設定します。
- Windows VM の場合、VM で自動更新を無効にすることをおすすめします。これにより、Windows の自動更新と Patch サービスの間の競合が軽減されます。
roles/osconfig.patchJobExecutor
: パッチジョブを実行、キャンセル、取得、一覧表示する権限が含まれています。また、パッチジョブのインスタンスの詳細を表示する権限も含まれています。roles/osconfig.patchJobViewer
: パッチジョブを取得して一覧表示するための読み取り専用アクセス権限が含まれています。また、パッチジョブのインスタンスの詳細を表示する権限も含まれています。project-id
: プロジェクト ID。user-id
: ユーザーの Google Workspace のユーザー名。- Google Cloud コンソールで、[Compute Engine] > [VM Manager] > [パッチ] ページに移動します。
- [新しいパッチのデプロイ] をクリックします。
[ターゲット VM] セクションで、パッチを適用する VM を含むゾーンを選択します。すべてのゾーンを選択することもできます。
ゾーンを選択したら、そのゾーン内の VM をさらにフィルタできます。
たとえば、次のような名前とラベルのフィルタを入力して、選択したゾーン内の特定の VM にパッチを適用します。
- 名前の接頭辞:
test-
- ラベル:
env=dev
とapp=web
- 名前の接頭辞:
[パッチ構成] セクションで、パッチを構成します。
- パッチの名前を指定します。
- オペレーティング システムに必要なアップデートを選択します。詳細については、パッチの構成をご覧ください。
[スケジュール] セクションで、次の操作を行います。
- スケジュールを選択します。パッチジョブをすぐに実行するには、[今すぐ開始] を選択します。
- (省略可)期間またはメンテナンスの時間枠を設定します。
[ロールアウトのオプション] セクションで、パッチ ロールアウトのオプションを構成します。
- 一度に 1 つのゾーンのみにパッチを適用するか、複数のゾーンに同時にパッチを適用するか選択します。
- 停止予算を設定します。停止予算とは、パッチプロセスによって一度に中断されるゾーン内の VM の数または割合です。
(省略可)[詳細オプション] セクションで、次の操作を行うことができます。
- 再起動オプションを選択します。
- パッチ適用前スクリプトとパッチ適用後スクリプトをアップロードします。パッチ適用前スクリプトとパッチ適用後スクリプトの詳細については、パッチ適用前スクリプトとパッチ適用後スクリプトの指定をご覧ください。
[デプロイ] をクリックします。
- インスタンス名:
instance-1
- ゾーン:
us-east1-b
説明:
patch for instance-1
次のコマンドを実行します。
- パッチは、プロジェクト内のすべてのインスタンスで実行する必要があります。
- パッチジョブは 1 時間 30 分後にタイムアウトして停止する必要があります。
- 更新をインストールした後、システム設定に基づいてマシンを再起動する必要があります。
- Apt を実行している VM では、
apt dist-upgrade
を使用してパッチを適用します。 - Windows を実行している VM では、
KB4339284
の更新にのみパッチを適用します。 - Yum を実行している VM では、
yum update-minimal --security
ユーティリティを使用してパッチを適用します。 project-id
: 実際のプロジェクト ID。instance-filter
: 必要なフィルタ パラメータ。インスタンス フィルタの詳細については、インスタンス フィルタをご覧ください。env=dev
ラベルとapp=web
ラベルがあります。asia-east1-b
またはasia-east1-c
にあります。- 接頭辞は
test-
です。 - パッチは、プロジェクト内のすべてのインスタンスで実行する必要があります。
- パッチジョブは 1 時間 30 分後にタイムアウトして停止する必要があります。API では時間は秒単位で指定する必要があるため、5400 秒に設定します。
- 更新をインストールした後、システム設定に基づいてマシンを再起動する必要があります。
- Apt を実行している VM では、
apt dist-upgrade
を使用してパッチを適用します。 - Windows を実行している VM では、
KB4339284
の更新にのみパッチを適用します。 - Yum を実行している VM では、
yum update-minimal --security
ユーティリティを使用してパッチを適用します。 名前でフィルタ: 特定の名前のインスタンスにパッチジョブを制限します。インスタンス名は完全な URI を使用して指定する必要があります。サポートされている URI 形式は次のとおりです。
zones/zone/instances/instance-name
projects/project-id/zones/zone/instances/instance-name
https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/instance-name
名前の接頭辞でフィルタ: 名前に特定の接頭辞を持つインスタンスにパッチジョブを制限します。
ゾーンでフィルタ: 特定のゾーンにあるインスタンスにパッチジョブを制限します。
ラベルでフィルタ: 特定のラベルを持つインスタンスにパッチジョブを制限します。
- Windows の場合、適用するパッチの分類(
Security
とCritical
)を指定するか、除外する特定の KB を対象とします。パッチ分類の詳細については、Microsoft のサポート ドキュメントをご覧ください。 RHEL、Rocky Linux、CentOS の場合、基盤となるシステムは
yum
です。- RHEL と Rocky Linux の VM をターゲットとするパッチの場合は、
security
パッケージとminimal
パッケージを指定できます。 - CentOS VM の場合、CentOS
yum
リポジトリにsecurity
メタデータはありません。したがって、セキュリティ パッケージの更新時にsecurity
オプションを指定する必要はありません。パッケージを指定しない場合、パッチジョブはセキュリティ アップデートがあるパッケージを含むすべてのパッケージを更新します。 - 特定のパッケージを除外することもできます。詳細については、
yum
のマニュアル ページをご覧ください。
- RHEL と Rocky Linux の VM をターゲットとするパッチの場合は、
Debian と Ubuntu の場合、基盤となるシステムは
apt
です。これらの VM を対象とするパッチの場合は、dist-upgrade
または標準アップグレードを指定できます。特定のパッケージを除外することもできます。詳細については、Debian のマニュアル ページまたは Ubuntu のマニュアル ページをご覧ください。SuSE の場合、基盤となるシステムは
zypper
であり、特に zypper パッチを使用します。これらの VM をターゲットとするパッチの場合、次のようなオプションを指定できます。with update
: パッチの対象ではないすべてのパッケージを更新するwith optional
: 必要に応じてオプションのパッチを処理する- 適用するパッチのカテゴリまたは重大度
特定のパッチを除外することもできます。
- デフォルト: エージェントによって、各 OS の既知のシグナルがチェックされ、再起動が必要かどうかが判別されます。パッチの適用中に複数の再起動が行われる場合があり、パッチがインストールされる前に行われる可能性もあります。
- 常に実行: 更新の完了後にマシンが再起動されます。
- 実行しない: 更新の完了後にマシンは再起動されません。場合によっては、一部のパッチが完全には適用されない可能性があります。
- パッチ適用前スクリプトは、パッチ適用が開始される前に実行されます。パッチ適用を開始する前にシステムの再起動が必要な場合、再起動前にパッチ適用前スクリプトが実行されます。
- パッチ適用後スクリプトは、パッチ適用が完了した後に実行されます。パッチ適用の一部としてシステムの再起動が必要な場合は、再起動後にパッチ適用後スクリプトが実行されます。
- パッチの適用時にパッチ適用オペレーションが失敗する
- パッチ適用前または変更後のステップを実行すると、パッチ適用オペレーションが失敗する
- パッチ適用オペレーションがタイムアウト前に成功通知で応答しない
- プロジェクト内のすべての VM にパッチを適用する
- ゾーンごとに VM にパッチを適用する
- 同じゾーン内の 10 を超える VM が同時に中断されないようにする
- プロジェクト内のすべての VM にパッチを適用する
- 複数のゾーンに同時にパッチを適用する
- 同じゾーン内の 50% を超える VM が同時に中断されないようにする
- ゾーン
us-central1-a
、us-central1-c
、us-central1-f
内のすべての VM にパッチを適用する - 複数のゾーンに同時にパッチを適用する
- 同じゾーン内の 25% を超えるインスタンスが同時に中断されないようにする
- Windows のスタート メニューで、[設定] > [更新とセキュリティ] > [Windows Update] を選択します。
- [詳細オプション] セクションで、[Receive updates for other Microsoft products when you update Windows] をオンにします。
影響を受けるパッチジョブのインスタンスの詳細を確認します。これにより、失敗したインスタンスや、どのような状態でインスタンスが停止しているかを特定できます。インスタンスの詳細リストには、各インスタンスの簡単なエラー メッセージも含まれています。
パッチが
NO_AGENT_DETECTED
またはTIMED_OUT
のステータスで失敗した場合は、サービスがエージェントにパッチ適用を開始するリクエストを送信したものの、エージェントからの応答がないことを通常意味しています。次の考えられる原因と解決方法を確認してください。- インスタンスが実行されていません。これを修正するには、VM インスタンスを起動します。
- 確認チェックリストで設定を確認します。
- VPC ネットワークまたはインスタンスのネットワーク設定により、OS Config エージェントが OS Config API と通信できませんでした。この問題を解決するには、ネットワーク設定を確認します。
インスタンスの詳細で十分な情報が得られない場合は、Cloud Logging のログまたはシリアルポート コンソールを確認してください。OS Config エージェントはログエントリを両方の場所に書き込みます。Cloud Logging では、パッチジョブ ID を使用してフィルタリングし、そのパッチジョブに関連するすべてのログエントリを表示できます。VM または Google Cloud プロジェクト レベルで
osconfig-log-level=debug
メタデータ値を設定し、デバッグ ロギングを有効にすることもできます。- Patch の詳細を学習する。
- パッチジョブを管理する。
- パッチジョブをスケジュールする。
REST
このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
詳細については、Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。
制限事項
サポートされているオペレーティング システム
Patch をサポートしているオペレーティング システムとバージョンの完全なリストについては、オペレーティング システムの詳細をご覧ください。
VM を設定する
Patch 機能を使用する手順は次のとおりです。
権限
Google Cloud プロジェクトのオーナーは、パッチジョブの実行と管理を行うための完全アクセス権を持っています。他のすべてのユーザーには、権限を付与する必要があります。次のいずれかの詳細な役割を付与できます。
たとえば、パッチジョブを実行するためのアクセス権をユーザーに付与するには、次のコマンドを使用します。
gcloud projects add-iam-policy-binding project-id \ --member user:user-id@gmail.com \ --role roles/osconfig.patchJobExecutor
以下を置き換えます。
パッチジョブを実行する
パッチジョブは、Google Cloud コンソール、Google Cloud CLI、または REST を使用して実行できます。
パッチジョブを実行すると、インスタンス フィルタで指定されたすべてのインスタンスで VM のパッチ適用が同時に開始されます。
パッチジョブを開始したら、Patch ダッシュボードを使用してパッチをモニタリングできます。パッチジョブの開始後、ダッシュボードにデータが入力されるまでに約 30 分かかります。
コンソール
gcloud
パッチジョブを実行するには、
os-config patch-jobs execute
コマンドを使用します。instance-filter
は、目的のインスタンス フィルタに置き換えます。インスタンス フィルタの詳細については、インスタンス フィルタをご覧ください。gcloud compute os-config patch-jobs execute instance-filter
適用される更新の詳細については、OS パッチジョブの内容をご覧ください。更新をカスタマイズするには、オプションのフラグを使用します。
例
例 1 次の構成でパッチジョブを実行するには:
gcloud compute os-config patch-jobs execute \ --instance-filter-names="zones/us-east1-b/instances/instance-1" \ --description "patch for instance-1"
例 2 次の構成でパッチジョブを非同期的で実行するとします。
次のコマンドを実行します。
gcloud compute os-config patch-jobs execute \ --instance-filter-all \ --duration="1h30m" --reboot-config="DEFAULT" \ --apt-dist --windows-exclusive-patches=4339284 \ --yum-minimal --yum-security \ --async
REST
API で、新しいパッチジョブを実行するための
POST
リクエストを作成します。patchJobs.execute
API ドキュメントで説明されているように、必要なすべての構成フィールドを明示的に定義する必要があります。適用される更新の詳細については、OS パッチジョブの内容をご覧ください。更新をカスタマイズするには、
PatchConfig
パラメータを使用します。たとえば、必須フィールドのみを含むパッチジョブは次のようになります。
POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute { "instanceFilter": instance-filter }
以下を置き換えます。
例
例 1
us-east1-b
にある、instance1
という名前のインスタンスでパッチジョブを実行するとします。この例では、説明を追加し、ジョブを 1 時間 30 分間実行するように指定します。project-id
は実際のプロジェクト ID に置き換えます。POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute { "description":"patch instance1 in us-east1-b", "duration":"5400s", "instanceFilter":{ "instances":[ "zones/us-east1-b/instances/instance1" ] } }
例 2 次のパッチジョブは、次の構成を持つ VM を選択します。
次のコマンドを実行します。
project-id
はプロジェクト ID で置き換えます。POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute { "instanceFilter":{ "groupLabels":[ { "labels":{ "env":"dev", "app":"web" } } ], "instanceNamePrefixes":[ "test-" ], "zones":[ "asia-east1-b", "asia-east1-c" ] } }
例 3
次の構成でパッチジョブを実行するとします。
次のリクエストを作成します。
次のコマンドを実行します。
project-id
はプロジェクト ID で置き換えます。POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute { "duration":"5400s", "instanceFilter":{ "all":true }, "patchConfig":{ "rebootConfig":"DEFAULT", "apt":{ "type":"DIST" }, "yum":{ "security":true, "minimal":true }, "windowsUpdate":{ "exclusivePatches":"4339284" } } }
インスタンス フィルタ
フィルタを使用して、パッチジョブに含めるインスタンスを指定できます。パッチジョブでは次のフィルタがサポートされています。
instanceFilter
のall
フィールドをtrue
に設定することで、Google Cloud プロジェクトのすべてのインスタンスでパッチジョブを実行することもできます。詳細については、インスタンス フィルタの例をご覧ください。インスタンス フィルタの例
事例 gcloud フィルタ API フィルタ Google Cloud プロジェクト内のすべてのインスタンス --instance-filter-all
{ "instanceFilter":{ "all":"true" } }
us-east1-b
ゾーンにあるinstance1
という名前のインスタンス。--instance-filter-names="zones/us-east1-b/instances/instance1"
{ "instanceFilter":{ "instances":[ "zones/us-east1-b/instances/instance1" ] } }
接頭辞が app-
のインスタンス--instance-filter-name-prefixes="app-"
{ "instanceFilter":{ "instanceNamePrefixes":[ "app-" ] } }
us-east1-b
ゾーンまたはus-east1-c
ゾーンのインスタンス--instance-filter-zones="us-east1-b","us-east1-c"
{ "instanceFilter":{ "zones":[ "us-east1-b", "us-east1-c" ] } }
env=dev
とapp=web
の組み合わせラベルを持つインスタンスと、env=dev
とapp=worker
を持つインスタンス。--instance-filter-group-labels="env=dev,app=web" --instance-filter-group-labels="env=dev,app=worker"
{ "instanceFilter":{ "groupLabels":[ { "labels":{ "env":"dev", "app":"web" } }, { "labels":{ "env":"dev", "app":"worker" } } ] } }
インスタンス フィルタの組み合わせ
インスタンス フィルタも組み合わせることができます。たとえば、接頭辞が
test-
であり、us-east1-c
ゾーンにある、ラベルがenv=dev
とapp=web
のインスタンスに対してパッチジョブを実行するには、次のコマンドを実行します。gcloud compute os-config patch-jobs execute \ --instance-filter-name-prefixes="test-" \ --instance-filter-zones="us-east1-c" \ --instance-filter-group-labels="env=prod,app=web"
パッチ構成
パッチジョブを実行するときに、VM に適用されるパッチを制御するパラメータを指定できます。パッチ構成パラメータはプラットフォームに依存しており、多くの場合、基盤となるシステム アップデート ツールに渡されます。実際のパッチは、VM で構成されている Package Repository(Linux)または Windows Update サーバー(Windows)から提供されます。
VM に次のパッチ構成を指定できます。
必要に応じて、サポートされているすべてのオペレーティング システムでこれらの更新を指定することで、承認済みパッチのみがインストールされるように選択できます。これにより、承認済みのパッケージまたはパッチのリストを入力できるようになります。これらの承認済みパッチを選択すると、承認済みのパッケージまたはパッチのみがインストールされます。その他のパッチ構成パラメータはすべて、更新時にスキップされます。
例
コンソール
gcloud
たとえば、異なるオペレーティング システムの特定のパッチ構成で
northamerica-northeast1-a
ゾーン内のすべてのインスタンスでパッチジョブを実行するには、gcloud compute os-config patch-jobs execute
コマンドを実行します。gcloud compute os-config patch-jobs execute \ --instance-filter-zones="northamerica-northeast1-a" \ --apt-dist \ --yum-security \ --yum-minimal \ --zypper-categories=security \ --windows-classifications=critical,security \ --reboot-config=default
サポートされているオプションの詳細を確認するには、次のコマンドを実行します。
gcloud compute os-config patch-jobs execute --help
REST
たとえば、異なるオペレーティング システムの特定のパッチ構成で
northamerica-northeast1-a
ゾーン内のすべてのインスタンスでパッチジョブを実行するには、次のコマンドを実行します。POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute { "instanceFilter":{ "zones":[ "northamerica-northeast1-a" ] }, "patchConfig":{ "apt": { "type": "dist-upgrade" }, "yum": { "security": true, "minimal": true }, "zypper": { "categories": ["security"] }, "windowsUpdate": { "classifications": ["CRITICAL", "SECURITY"] }, "rebootConfig": "DEFAULT" } }
サポートされているパラメータの詳細については、
PatchConfig API
のドキュメントをご覧ください。メンテナンスの時間枠
メンテナンスの時間枠とは、パッチジョブの実行を許可する合計時間です。パッチジョブは、指定されたメンテナンスの時間枠内に完了しなければタイムアウトします。
たとえば、メンテナンスの時間枠を
60 minutes
に設定した場合、開始時間から 60 分が経過すると新しいパッチジョブは開始されません。ファイルのダウンロードや再起動などの一部のプロセスがこのメンテナンスの時間枠外で発生する可能性はありますが、パッチジョブが新しく始まることはありません。再起動オプション
パッチジョブを実行するときに、パッチの再起動オプションを指定できます。次のオプションが用意されています。
パッチ適用前スクリプトとパッチ適用後スクリプト
パッチジョブを実行するときに、パッチ適用プロセスの一部として実行するスクリプトを指定できます。これらのスクリプトは、アプリケーションのシャットダウンやヘルスチェックの実行などのタスクを実行するのに役立ちます。
パッチジョブは、Linux 用の 1 つのパッチ適用前スクリプトと 1 つのパッチ適用後スクリプトを受け入れ、Windows 用の 1 つのパッチ適用前スクリプトと 1 つのパッチ適用後スクリプトを受け入れます。Linux と Windows のスクリプトが Google Cloud CLI、REST、または Google Cloud コンソールから指定された場合、それぞれ適切なフラグ、パラメータ、セクションを使用して提供される必要があります。Linux スクリプトは Linux VM でのみ実行され、Windows スクリプトは Windows VM でのみ実行されます。
これらのスクリプト ファイルは、VM またはバージョニングされた Cloud Storage バケットに保存できます。Cloud Storage オブジェクトが一般公開されていない場合は、Google Cloud プロジェクトのデフォルトの Compute Engine サービス アカウントに、Cloud Storage オブジェクトの読み取りに必要な IAM 権限があることを確認してください。適切な権限があることを確認するには、Cloud Storage オブジェクトの権限設定を確認します。
Cloud Storage バケットを使用してスクリプトを保存する場合は、Cloud Storage バケットを作成し、バケットにスクリプトをアップロードします。
例
コンソール
gcloud
たとえば、Linux インスタンスと Windows インスタンス用のパッチ適用前スクリプトとパッチ適用後スクリプトの両方を使用して、
northamerica-northeast1-a
ゾーンにあるすべてのインスタンスにパッチジョブを実行するには、次のコマンドを実行します。gcloud compute os-config patch-jobs execute \ --instance-filter-zones="northamerica-northeast1-a" \ --async \ --pre-patch-linux-executable="/tmp/pre_patch_script.sh" \ --post-patch-linux-executable="gs://my-patch-scripts/linux/post_patch_script#1523477886880" \ --pre-patch-windows-executable="C:\\Users\\user\\pre-patch-script.cmd" \ --post-patch-windows-executable="gs://my-patch-scripts/windows/post_patch_script.ps1#135920493447"
使用可能なファイル形式の詳細を確認するには、次のコマンドを実行してください。
gcloud compute os-config patch-jobs execute --help
REST
たとえば、Linux インスタンスと Windows インスタンス用のパッチ適用前スクリプトとパッチ適用後スクリプトの両方を使用して、
northamerica-northeast1-a
ゾーンにあるすべてのインスタンスにパッチジョブを実行するには、次のコマンドを実行します。POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute { "instanceFilter":{ "zones":[ "northamerica-northeast1-a" ] }, "patchConfig":{ "preStep":{ "linuxExecStepConfig":{ "localPath":"/tmp/pre_patch_script.sh" }, "windowsExecStepConfig":{ "interpreter":"SHELL", "localPath":"C:\\Users\\user\\pre-patch-script.cmd" } }, "postStep":{ "linuxExecStepConfig":{ "gcsObject":{ "bucket":"my-patch-scripts", "generationNumber":"1523477886880", "object":"linux/post_patch_script" } }, "windowsExecStepConfig":{ "gcsObject":{ "bucket":"my-patch-scripts", "generationNumber":"135920493447", "object":"windows/post_patch_script.ps1" }, "interpreter":"POWERSHELL" } } } }
使用可能なファイル形式の詳細については、
PatchConfig
API ドキュメントのExecStepConfig
セクションをご覧ください。パッチ ロールアウトのオプション
一度に 1 つのゾーンに VM にパッチを適用する(ゾーン別)か、すべてのゾーンを一度にパッチするか(同時実行ゾーン)を選択できます。
ゾーン ロールアウトを選択する際に、VM のゾーン停止予算を指定することもできます。
ゾーン停止予算
停止予算とは、ゾーンあたりの、停止する VM の最大数(または割合)です。
停止したとみなされる VM
パッチ適用中は、OS Config エージェントにパッチ適用の開始が通知されてからが完了するまで、VM が停止したとみなされます。この停止時間には、再起動を完了する時間とパッチ後のステップが含まれます。
VM は、次のいずれかの条件を満たしている場合、停止予算の一部としてもカウントされます。
停止予算の仕組み
ゾーンごとのロールアウトの場合、ゾーン内の停止予算を超過すると、パッチジョブは停止します。これは、次のゾーンに進むには前のゾーンでパッチプロセスを完了する必要があるためです。
たとえば、停止予算の値が 10 で、現在のゾーンの 8 つの VM がパッチ適用に失敗する場合、パッチジョブはゾーンが完了するまで 2 つの VM にパッチを適用します。そのゾーンが正常に完了すると、次のゾーンで一度に 10 の VM にパッチが適用されます。次のゾーンで 10 の VM のパッチ適用に失敗すると、パッチジョブは停止します。
例
コンソール
gcloud
例 1
次の例は、次の仕様でパッチジョブを実行するための
os-config patch-jobs execute
コマンドを示しています。gcloud compute os-config patch-jobs execute \ --instance-filter-all \ --rollout-mode=zone-by-zone \ --rollout-disruption-budget=10
例 2
次の例は、次の仕様でパッチジョブを実行するための
os-config patch-jobs execute
コマンドを示しています。gcloud compute os-config patch-jobs execute \ --instance-filter-all \ --rollout-mode=concurrent-zones \ --rollout-disruption-budget-percent=50
REST
次の例は、次の仕様でパッチジョブを実行するための
patchJobs.execute
メソッドを示しています。POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute { "instanceFilter":{ "zones":[ "us-central1-a", "us-central1-c", "us-central1-f" ] }, "rollout": { "disruptionBudget": { "percent": 25 }, "mode": "CONCURRENT_ZONES" } }
パッチ ロールアウトの詳細については、
PatchRollout
API のドキュメントをご覧ください。Windows VM で Microsoft ソフトウェアへのパッチ適用を有効にする
デフォルトでは、Windows VM でパッチジョブを実行すると、Patch は Windows オペレーティング システムのパッチのみを適用します。
パッチジョブの実行時に、Windows VM で実行されている Microsoft SQL Server、SharePoint Server、.NET Framework などの Microsoft ソフトウェアの更新を適用できます。サービスの中断を避け、これらのソフトウェアの計画的な更新を分けて行えるよう、これらのアプリケーションへのパッチ適用はデフォルトで無効になっています。Microsoft ソフトウェアへの自動でのパッチ適用を有効にするには、Windows UI または PowerShell を使用します。
Windows UI
PowerShell
$service_manager = New-Object -ComObject 'Microsoft.Update.ServiceManager' $service_manager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"")
パッチジョブをデバッグする
パッチが失敗した場合は、次の手順で問題を見つけて解決できます。
次のステップ
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2024-12-22 UTC。
-