パッチジョブの作成

OS パッチ管理を使用して、VM インスタンスのグループ全体にわたり、オペレーティング システムのパッチを適用できます。

VM にパッチを適用する手順は、次のとおりです。

  1. VM を設定します
  2. パッチジョブを実行します

始める前に

サポートされているオペレーティング システム

  • Debian 9
  • Ubuntu 16.04、18.04
  • CentOS 6、7、8
  • Red Hat Enterprise Linux(RHEL)6、7、8
  • Windows Server 2012R2、2016、2019、半年ごとのリリースの 1803 と 1809
  • SUSE Enterprise Linux Server(SLES)12 および 15、openSUSE Leap 15

VM の設定

OS Patch Management サービスを使用するには、OS Config Service API を設定し、OS Config エージェントをインストールする必要があります。手順の詳細については、OS Config の設定をご覧ください。

権限

プロジェクトのオーナーは、パッチジョブの実行と管理を行うための完全アクセス権を持っています。それ以外のすべてのユーザーにはアクセス権限を付与する必要があります。次のいずれかの詳細な役割を付与できます。

  • roles/osconfig.patchJobExecutor: パッチジョブを実行、キャンセル、取得、一覧表示する権限が含まれています。また、パッチジョブのインスタンスの詳細を表示する権限も含まれています。
  • roles/osconfig.patchJobViewer: パッチジョブを取得して一覧表示するための読み取り専用アクセス権限が含まれています。また、パッチジョブのインスタンスの詳細を表示する権限も含まれています。

たとえば、パッチジョブを実行するためのアクセス権をユーザーに付与するには、次のコマンドを使用します。

gcloud projects add-iam-policy-binding project-id \
    --member user:user-id@gmail.com \
    --role roles/osconfig.patchJobExecutor

以下を置き換えます。

  • project-id: プロジェクト ID。
  • user-id: ユーザーの G Suite ユーザー名。

パッチジョブの実行

パッチジョブは、Google Cloud Consolegcloud コマンドライン ツール、または Cloud OS Config API を使用して実行できます。

パッチジョブを実行すると、インスタンス フィルタで指定されたすべてのインスタンスで VM のパッチ適用が同時に開始されます。

パッチジョブを開始したら、OS Patch Management ダッシュボードを使用して、パッチをモニターできます。パッチジョブの開始後、ダッシュボードにデータが入力されるまでに約 30 分かかります。

Console

  1. Google Cloud Console で、[OS Patch Management] ページに移動します。

    [OS Patch Management] ページに移動

  2. [新しいパッチのデプロイ] をクリックします。
  3. [ターゲット VM] セクションで、パッチを適用する VM インスタンスを選択します。すべての VM インスタンスを選択することも、インスタンス フィルタを使用することもできます。

    たとえば、接頭辞が test- で、ラベルが env=devapp=web のインスタンスに対してパッチジョブを実行する場合、設定は次のようになります。

    インスタンス フィルタを表示している OS パッチ管理ページ。

  4. [パッチ構成] セクションで、パッチを設定します。

    1. パッチの名前を指定します。
    2. オペレーティング システムに必要なアップデートを選択します。詳細については、パッチの構成をご覧ください。
  5. [スケジュール] セクションでスケジュールを選択します。パッチジョブをすぐに実行するには、[今すぐ開始] を選択します。

  6. (省略可)[詳細オプション] セクションで、次の操作を行えます。

  7. [デプロイ] をクリックします。

gcloud

パッチジョブを実行するには、os-config patch-jobs execute コマンドを使用します。instance-filter は、目的のインスタンス フィルタに置き換えます。インスタンス フィルタの詳細については、インスタンス フィルタをご覧ください。

gcloud compute os-config patch-jobs execute instance-filter

適用される更新の詳細については、OS パッチジョブの内容をご覧ください。更新をカスタマイズするには、オプションのフラグを使用します。

例 1 次の構成でパッチジョブを実行するには:

  • インスタンス名: instance-1
  • ゾーン: us-east1-b
  • 説明: patch for instance-1

    次のコマンドを実行します。

gcloud compute os-config patch-jobs execute \
    --instance-filter-names="zones/us-east1-b/instances/instance-1" \
    --description "patch for instance-1"

例 2 次の構成でパッチジョブを非同期的で実行するとします。

  • パッチは、プロジェクト内のすべてのインスタンスで実行する必要があります。
  • パッチジョブは 1 時間 30 分後にタイムアウトして停止する必要があります。
  • 更新をインストールした後、システム設定に基づいてマシンを再起動する必要があります。
  • Apt を実行している VM では、apt dist-upgrade を使用してパッチを適用します。
  • Windows を実行している VM では、KB4339284 の更新にのみパッチを適用します。
  • Yum を実行している VM では、yum update-minimal --security ユーティリティを使用してパッチを適用します。

次のコマンドを実行します。

gcloud compute os-config patch-jobs execute \
    --instance-filter-all \
    --duration="1h30m" --reboot-config="DEFAULT" \
    --apt-dist --windows-exclusive-patches=KB4339284 \
    --yum-minimal --yum-security \
    --async

API

API で、新しいパッチジョブを実行するための POST リクエストを作成します。patchJobs.execute API ドキュメントで説明されているように、必要なすべての構成フィールドを明示的に定義する必要があります。

適用される更新の詳細については、OS パッチジョブの内容をご覧ください。更新をカスタマイズするには、PatchConfig パラメータを使用します。

たとえば、必須フィールドのみを含むパッチジョブは次のようになります。

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "instanceFilter": instance-filter
}

以下を置き換えます。

  • project-id: 実際のプロジェクト ID。
  • 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 を選択します。

  • env=dev ラベルと app=web ラベルがあります。
  • asia-east1-b または asia-east1-c にあります。
  • 接頭辞は test- です。

次のコマンドを実行します。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

次の構成でパッチジョブを実行するとします。

  • パッチは、プロジェクト内のすべてのインスタンスで実行する必要があります。
  • パッチジョブは 1 時間 30 分後にタイムアウトして停止する必要があります。API では時間は秒単位で指定する必要があるため、5400 秒に設定します。
  • 更新をインストールした後、システム設定に基づいてマシンを再起動する必要があります。
  • Apt を実行している VM では、apt dist-upgrade を使用してパッチを適用します。
  • Windows を実行している VM では、KB4339284 の更新にのみパッチを適用します。
  • Yum を実行している VM では、yum update-minimal --security ユーティリティを使用してパッチを適用します。

次のリクエストを作成します。

次のコマンドを実行します。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":"KB4339284"
   }
 }
}

インスタンス フィルタ

フィルタを使用して、パッチジョブに含めるインスタンスを指定できます。パッチジョブでは次のフィルタがサポートされています。

  • 名前でフィルタ: 特定の名前のインスタンスにパッチジョブを制限します。インスタンス名は完全な 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
  • 名前の接頭辞でフィルタ: 名前に特定の接頭辞を持つインスタンスにパッチジョブを制限します。

  • ゾーンでフィルタ: 特定のゾーンにあるインスタンスにパッチジョブを制限します。

  • ラベルでフィルタ: 特定のラベルを持つインスタンスにパッチジョブを制限します。

instanceFilterall フィールドを true に設定して、プロジェクト内のすべてのインスタンスでパッチジョブを実行することもできます。詳細については、インスタンス フィルタの例をご覧ください。

インスタンス フィルタの例

事例 gcloud フィルタ API フィルタ
プロジェクト内のすべてのインスタンス

--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=devapp=web の組み合わせラベルを持つインスタンスと、env=devapp=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=devapp=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 に次のパッチ構成を指定できます。

  • Windows の場合、適用するパッチの分類(SecurityCritical)を指定するか、除外する特定の KB を対象とします。パッチ分類の詳細については、Microsoft のサポート ドキュメントをご覧ください。
  • RHEL と CentOS の場合、基盤となるシステムは yum です。これらの VM をターゲットとするパッチの場合は、security パッケージと minimal パッケージを指定できます。特定のパッケージを除外することもできます。詳細については、yum のマニュアル ページをご覧ください。
  • Debian と Ubuntu の場合、基盤となるシステムは apt です。これらの VM を対象とするパッチの場合は、dist-upgrade または標準アップグレードを指定できます。特定のパッケージを除外することもできます。詳細については、Debian のマニュアル ページまたは Ubuntu のマニュアル ページをご覧ください。
  • SuSE の場合、基盤となるシステムは zypper であり、特に zypper パッチを使用します。これらの VM をターゲットとするパッチの場合、次のようなオプションを指定できます。

    • with update: パッチの対象ではないすべてのパッケージを更新する
    • with optional: 必要に応じてオプションのパッチを処理する
    • 適用するパッチのカテゴリまたは重大度

    特定のパッチを除外することもできます。

必要に応じて、サポートされているすべてのオペレーティング システムでこれらの更新を指定することで、承認済みパッチのみがインストールされるように選択できます。これにより、承認済みのパッケージまたはパッチのリストを入力できるようになります。これらの承認済みパッチを選択すると、承認済みのパッケージまたはパッチのみがインストールされます。その他のパッチ構成パラメータはすべて、更新時にスキップされます。

Console

  1. パッチジョブまたはパッチデプロイを作成するには、コンソールのタブに記載されている手順に従います。
  2. [パッチ構成] セクションで、パッチジョブのパラメータを選択します。

    入力フィールドを示す OS パッチ構成。

  3. パッチジョブまたはデプロイに必要な追加の構成を行います。

  4. [デプロイ] をクリックします。

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

API

たとえば、異なるオペレーティング システムの特定のパッチ構成で 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 のドキュメントをご覧ください。

再起動オプション

パッチジョブを実行するときに、パッチの再起動オプションを指定できます。次のオプションが用意されています。

  • デフォルト: エージェントによって、各 OS の既知のシグナルがチェックされ、再起動が必要かどうかが判別されます。パッチの適用中に複数の再起動が行われる場合があり、パッチがインストールされる前に行われる可能性もあります。
  • 常に実行: 更新の完了後にマシンが再起動されます。
  • 実行しない: 更新の完了後にマシンは再起動されません。場合によっては、一部のパッチが完全には適用されない可能性があります。

パッチ適用前スクリプトとパッチ適用後スクリプト

パッチジョブを実行するときに、パッチ適用プロセスの一部として実行するスクリプトを指定できます。これらのスクリプトは、アプリケーションのシャットダウンやヘルスチェックの実行などのタスクを実行するのに役立ちます。

  • パッチ適用前スクリプトは、パッチ適用が開始される前に実行されます。パッチ適用を開始する前にシステムの再起動が必要な場合、再起動前にパッチ適用前スクリプトが実行されます。
  • パッチ適用後スクリプトは、パッチ適用が完了した後に実行されます。パッチ適用の一部としてシステムの再起動が必要な場合は、再起動後にパッチ適用後スクリプトが実行されます。

パッチジョブは、Linux 用の 1 つのパッチ適用前スクリプトと 1 つのパッチ適用後スクリプトを受け入れ、Windows 用の 1 つのパッチ適用前スクリプトと 1 つのパッチ適用後スクリプトを受け入れます。Linux スクリプトと Windows スクリプトは、別々に提供する必要があります。

これらのスクリプト ファイルは、VM またはバージョニングされた Cloud Storage バケットに保存できます。Cloud Storage オブジェクトが一般公開されていない場合は、プロジェクトのデフォルトの Compute Engine サービス アカウントに、Cloud Storage オブジェクトの読み取りに必要な IAM 権限があることを確認してください。適切な権限があることを確認するには、Cloud Storage オブジェクトの権限設定を確認します。

Cloud Storage バケットを使用してスクリプトを保存する場合は、Cloud Storage バケットを作成し、バケットにスクリプトをアップロードします。

Console

  1. パッチジョブまたはパッチデプロイを作成するには、コンソールのタブに記載されている手順に従います。
  2. [詳細オプション] セクションの [パッチ適用前] セクションと [パッチ適用後] セクションの両方で、[参照] をクリックします。Cloud Storage オブジェクトのページが表示されます。
  3. [Cloud Storage オブジェクト] ページで、スクリプトを含む Cloud Storage バケットを選択し、Cloud Storage オブジェクトまたはファイルを選択します。
  4. パッチジョブまたはデプロイに必要な追加の構成を行います。
  5. [デプロイ] をクリックします。

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

API

たとえば、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. 影響を受けるパッチジョブのインスタンスの詳細を確認します。これにより、失敗したインスタンスや、どのような状態でインスタンスが停止しているかを特定できます。インスタンスの詳細リストには、各インスタンスの簡単なエラー メッセージも含まれています。

    パッチが NO_AGENT_DETECTED のステータスで失敗した場合、通常、サービスはエージェントにパッチ適用を開始するリクエストを送信しましたが、エージェントからの応答がありません。次の考えられる原因と解決方法を確認してください。

    • インスタンスが実行されていません。これを修正するには、VM インスタンスを起動します。
    • OS Config サービスが有効になっていません。この問題を解決するには、VM の設定をご覧ください。
    • OS Config エージェントがインスタンスにインストールされていないか、実行されていません。この問題を解決するには、VM の設定をご覧ください。
    • インスタンスのネットワーク設定で、エージェントがサービスと通信できませんでした。ネットワーク設定を確認します。
  2. インスタンスの詳細で十分な情報が得られない場合は、Cloud Logging のログまたはシリアルポート コンソールを確認してください。OS Config エージェントはログエントリを両方の場所に書き込みます。Cloud Logging では、パッチジョブ ID を使用してフィルタリングし、そのパッチジョブに関連するすべてのログエントリを表示できます。

次のステップ