패치 작업 만들기

패치를 사용하여 가상 머신(VM) 인스턴스 그룹에 운영체제 패치를 적용할 수 있습니다.

VM에 패치를 적용하려면 다음 단계를 완료합니다.

VM을 설정합니다.
패치 작업을 실행합니다.

시작하기 전에

OS 구성 할당량을 검토합니다.
아직 인증을 설정하지 않았다면 설정합니다. 인증은 Google Cloud 서비스 및 API에 액세스하기 위해 ID를 확인하는 프로세스입니다. 로컬 개발 환경에서 코드 또는 샘플을 실행하려면 다음과 같이 Compute Engine에 인증하면 됩니다.

이 페이지의 샘플 사용 방법에 대한 탭을 선택하세요.
콘솔

Google Cloud 콘솔을 사용하여 Google Cloud 서비스 및 API에 액세스할 때는 인증을 설정할 필요가 없습니다.
gcloud
1. Google Cloud CLI를 설치한 후 다음 명령어를 실행하여 초기화합니다.
```
gcloud init
```
  참고: gcloud CLI를 이전에 설치했으면 gcloud components update를 실행하여 최신 버전을 사용할 수 있는지 확인합니다.
2. 기본 리전 및 영역을 설정합니다.
REST

로컬 개발 환경에서 이 페이지의 REST API 샘플을 사용하려면 gcloud CLI에 제공한 사용자 인증 정보를 사용합니다.

제한사항

단일 Google Cloud 프로젝트의 VM에만 패치 작업을 배포하고 실행할 수 있습니다. VM이 공유 VPC에 있더라도 Google Cloud 프로젝트에서 패치 작업을 실행할 수 없습니다. 하지만 프로젝트 전반의 패치 규정 준수 데이터를 확인할 수 있습니다.
관리형 인스턴스 그룹(MIG)에 속하는 VM을 패치할 때 다음 제한사항이 적용됩니다.
- MIG는 VM을 복구할 때 인스턴스 템플릿을 기반으로 VM을 다시 만듭니다. 이렇게 하면 VM을 패치되지 않은 상태로 되돌릴 수 있습니다.
- VM에 패치를 적용하면 자동 확장이 사용 설정된 MIG에서 예기치 않은 결과가 발생할 수 있습니다. 자동 확장 처리는 부하가 감소하면 패치가 적용된 VM을 삭제하고 부하가 증가하면 MIG의 인스턴스 템플릿을 사용하여 패치 없이 새 VM을 만듭니다. 예를 들어 평균 CPU 사용률이 자동 확장에 지정한 목표 사용률보다 낮은 경우 MIG는 수평 축소하는 동안 패치가 적용된 일부 VM을 삭제할 수 있습니다.

지원되는 운영체제

패치를 지원하는 운영체제와 버전의 전체 목록은 운영체제 세부정보를 참조하세요.

VM 설정

패치 기능을 사용하려면 다음 단계를 완료하세요.

모든 VM에 VM Manager를 설정합니다.
Windows VM의 경우 VM에서 자동 업데이트를 중지하는 것이 좋습니다. 이렇게 하면 Windows 자동 업데이트와 패치 서비스 간의 충돌이 줄어듭니다.

권한

Google Cloud 프로젝트의 소유자는 패치 작업을 실행하고 관리할 수 있는 전체 액세스 권한을 갖습니다. 다른 모든 사용자에게는 권한 부여가 필요합니다. 다음 세분화된 역할 중 하나를 부여할 수 있습니다.

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: 사용자의 Google Workspace 사용자 이름

패치 작업 실행

Google Cloud 콘솔, Google Cloud CLI 또는 REST를 사용하여 패치 작업을 실행할 수 있습니다.

패치 작업을 실행하면 인스턴스 필터로 지정된 모든 인스턴스에서 VM 패치 적용이 동시에 시작됩니다.

패치 작업을 시작한 후에는 패치 대시보드를 사용하여 패치를 모니터링할 수 있습니다. 패치 작업 시작 후 대시보드에 데이터가 채워지는 데 약 30분 정도 걸립니다.

콘솔

Google Cloud 콘솔에서 Compute Engine > VM Manager > 패치 페이지로 이동합니다.
패치 페이지로 이동
새 패치 배포를 클릭합니다.
대상 VM 섹션에서 패치할 VM이 포함된 영역을 선택합니다. 모든 영역을 선택할 수도 있습니다.

영역을 선택한 후 해당 영역 내의 VM을 추가로 필터링할 수 있습니다.

참고: Google Cloud Console에서는 이름 프리픽스 또는 라벨로만 필터링할 수 있습니다. 다른 유형의 인스턴스 필터를 적용해야 하는 경우 Google Cloud CLI 또는 REST를 사용하세요.

예를 들어 선택한 영역의 특정 VM을 패치하려면 다음과 유사한 이름 필터와 라벨 필터를 입력합니다.
- 이름 프리픽스: test-
- 라벨: env=dev 및 app=web
패치 구성 섹션에서 패치를 구성합니다.
1. 패치 이름을 지정합니다.
2. 운영체제에 필요한 업데이트를 선택합니다. 자세한 내용은 패치 구성을 참조하세요.
예약 섹션에서 다음을 완료합니다.
- 일정을 선택합니다. 패치 작업을 즉시 실행하려면 지금 시작을 선택합니다.
- 선택사항: 기간 또는 유지보수 기간을 설정합니다.
출시 옵션 섹션에서 패치 출시 옵션을 구성합니다.
- 한 번에 하나의 영역에 패치를 적용할지 아니면 여러 영역에 패치를 동시에 적용할지 선택합니다.
- 중단 예산을 설정합니다. 중단 예산은 패치 프로세스를 통해 한 번에 중단하려는 영역의 VM 수 또는 백분율입니다.
선택사항: 고급 옵션 섹션에서는 다음 작업을 완료할 수 있습니다.
- 재부팅 옵션을 선택합니다.
- 사전 패치 및 사후 패치 스크립트를 업로드합니다. 사전 패치 및 사후 패치 스크립트에 대한 자세한 내용은 사전 패치 및 사후 패치 스크립트 지정을 참조하세요.
배포를 클릭합니다.

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=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
}

다음을 바꿉니다.

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에서는 시간을 초 단위로 표시해야 하므로 5,400초로 설정합니다.
머신은 업데이트를 설치한 후 시스템 설정에 따라 재부팅되어야 합니다.
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":"4339284"
   }
 }
}

인스턴스 필터

필터를 사용하여 패치 작업에 포함할 인스턴스를 지정할 수 있습니다. 패치 작업에는 다음과 같은 필터가 지원됩니다.

이름으로 필터링: 패치 작업을 특정 이름을 사용하는 인스턴스로 제한합니다. 전체 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
```
이름 프리픽스로 필터링: 패치 작업을 이름에 특정 프리픽스가 있는 인스턴스로 제한합니다.
영역으로 필터링: 패치 작업을 특정 영역의 인스턴스로 제한합니다.
라벨로 필터링: 패치 작업을 특정 라벨이 있는 인스턴스로 제한합니다.

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에 구성된 패키지 저장소(Linux) 또는 Windows 업데이트 서버(Windows)에서 제공됩니다.

VM에 다음 패치 구성을 지정할 수 있습니다.

Windows의 경우 적용할 패치 분류(예: Security 및 Critical)를 지정하거나 제외할 특정 KB를 타겟팅합니다. 패치 분류에 대한 자세한 내용은 Microsoft 지원 문서를 참조하세요.
RHEL, Rocky Linux, CentOS의 경우 기본 시스템은 yum입니다.
- RHEL 및 Rocky Linux VM을 대상으로 하는 패치의 경우 security 및 minimal 패키지를 지정할 수 있습니다.
- CentOS VM의 경우 CentOS yum 저장소에 security 메타데이터가 없습니다. 따라서 보안 패키지를 업데이트할 때 security 옵션을 지정하지 않아도 됩니다. 패키지를 지정하지 않으면 패치 작업은 보안 업데이트가 있는 패키지를 포함하여 모든 패키지를 업데이트합니다.
- 또한 특정 패키지를 제외할 수 있습니다. 자세한 내용은 yum 설명 페이지를 참조하세요.
Debian 및 Ubuntu의 경우 기본 시스템은 apt입니다. 이러한 VM을 타겟팅하는 패치의 경우 dist-upgrade 또는 표준 업그레이드를 지정할 수 있습니다. 또한 특정 패키지를 제외할 수 있습니다. 자세한 내용은 Debian 설명 페이지나 Ubuntu 설명 페이지를 참조하세요.
SuSE의 경우 기본 시스템은 zypper이고 구체적으로 zypper 패치를 사용합니다. 이러한 VM을 타겟팅하는 패치의 경우 다음과 같은 옵션을 지정할 수 있습니다.
- with update: 패치가 적용되지 않는 모든 패키지 업데이트
- with optional: 필요에 따라 선택적 패치 처리
- 적용할 패치의 카테고리 또는 심각도
또한 특정 패치를 제외할 수 있습니다.

원하는 경우 지원되는 모든 운영체제에 이러한 업데이트를 지정하여 승인된 패치만 설치할 수 있습니다. 이렇게 하면 승인된 패키지 또는 패치의 목록을 입력할 수 있습니다. 이러한 승인된 패치를 선택하면 승인된 패키지나 패치만 설치됩니다. 다른 모든 패치 구성 매개변수는 업데이트 중에 건너뜁니다.

예시

콘솔

Console 탭에 설명된 단계를 수행하여 패치 작업이나 패치 배포를 만듭니다.
패치 구성 섹션에서 패치 작업의 매개변수를 선택합니다.
패치 작업이나 배포에 필요한 추가 구성을 수행합니다.
배포를 클릭합니다.

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분 후에 새로운 패치 작업이 시작되지 않습니다. 파일 다운로드 또는 재부팅과 같은 일부 프로세스는 이 유지보수 기간이 지난 후에도 발생할 수 있지만 새로운 패치 작업은 시작되지 않습니다.

재부팅 옵션

패치 작업을 실행할 때 패치의 재부팅 옵션을 지정할 수 있습니다. 사용할 수 있는 옵션은 다음과 같습니다.

기본값: 에이전트가 각 OS에서 잘 알려진 신호를 확인하여 재부팅이 필요한지 여부를 결정합니다. 패치하는 동안과 패치가 설치되기 전에 여러 번 재부팅될 수 있습니다.
항상: 업데이트가 완료되면 머신이 재부팅됩니다.
재부팅 안 함: 업데이트가 완료된 후 머신이 재부팅되지 않습니다. 경우에 따라 일부 패치가 완전히 적용되지 않을 수도 있습니다.

사전 패치 및 사후 패치 스크립트

패치 작업을 실행할 때 패치 프로세스의 일부로 실행할 스크립트를 지정할 수 있습니다. 이러한 스크립트는 애플리케이션 종료 및 상태 확인과 같은 태스크를 수행할 때 유용합니다.

사전 패치 스크립트는 패치가 시작되기 전에 실행됩니다. 패치를 시작하기 전에 시스템을 재부팅해야 하는 경우에는 재부팅 전에 사전 패치 스크립트가 실행됩니다.
사후 패치 스크립트는 패치가 완료된 후 실행됩니다. 패치 과정에서 시스템을 재부팅해야 하는 경우에는 재부팅 후에 사후 패치 스크립트가 실행됩니다.

Linux에서는 패치 작업에 사전 패치 및 사후 패치 스크립트가 각각 한 개씩 허용되고 Windows에서는 사전 패치 및 사후 패치 스크립트가 각각 한 개씩 허용됩니다. 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 버킷을 생성하고 버킷에 스크립트를 업로드합니다.

예시

콘솔

Console 탭에 설명된 단계를 수행하여 패치 작업이나 패치 배포를 만듭니다.
사전 패치 및 사후 패치 섹션의 고급 옵션 섹션에서 찾아보기를 클릭합니다. Cloud Storage 객체 페이지가 표시됩니다.
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

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 섹션을 참조하세요.

패치 출시 옵션

VM을 한 번에 하나의 영역에 패치를 적용할지(영역별) 모든 영역에 한 번에 패치를 적용할지(동시 영역) 선택할 수 있습니다.

영역 출시를 선택할 때 VM에 대한 영역 중단 예산을 함께 지정할 수도 있습니다.

영역 중단 예산

중단 예산은 특정 시점에 중단되는 영역당 최대 VM 수(또는 백분율)입니다.

중단된 VM은 어떤 것인가요?

VM은 패치가 진행되는 동안 OS 구성 에이전트에 패치 시작 알림이 전송된 시점부터 패치가 완료되는 시점까지 중단된 것으로 간주됩니다. 이 중단 시간에는 재부팅 및 모든 패치 후 단계를 완료하는 시간이 포함됩니다.

또한 VM은 다음 조건 중 하나를 충족하는 경우 중단 예산의 일부로 계산됩니다.

패치 적용 시 패치 작업이 실패하는 경우
패치 전 또는 패치 후 단계를 실행할 때 패치 작업이 실패하는 경우
시간 제한 전에 패치 작업이 성공 알림으로 응답하지 않는 경우

중단 예산 작동 방식

영역별 출시의 경우 영역의 중단 예산이 초과되면 패치 작업이 중지됩니다. 이는 다음 영역으로 계속 진행하려면 이전 영역의 패치 프로세스를 완료해야 하기 때문에 발생합니다.

예를 들어 중단 예산의 값이 10이고 현재 영역에서 8개의 VM을 패치하는 데 실패하는 경우 패치 작업은 영역이 완료될 때까지 한 번에 2개의 VM을 계속 패치합니다. 해당 영역이 성공적으로 완료되면 다음 영역에서는 한 번에 10개의 VM을 패치하기 시작합니다. 다음 영역에서 10개의 VM을 패치하는 데 실패하면 패치 작업이 중지됩니다.

예시

콘솔

Console 탭에 설명된 단계를 수행하여 패치 작업이나 패치 배포를 만듭니다.
출시 옵션 섹션에서 출시 옵션을 구성합니다.
- 한 번에 하나의 영역에 패치를 적용할지 아니면 모든 영역에 패치를 동시에 적용할지 선택합니다.
- 중단 예산을 설정합니다. 중단 예산은 패치 프로세스를 통해 한 번에 중단하려는 영역의 VM 수 또는 백분율입니다.
패치 작업이나 배포에 필요한 추가 구성을 수행합니다.
배포를 클릭합니다.

gcloud

예시 1

이 예시에서는 다음 사양을 통해 패치 작업을 실행하기 위한 os-config patch-jobs execute 명령어를 보여줍니다.

프로젝트의 모든 VM 패치
영역별 VM 패치
지정된 시간에 동일한 영역에서 10개 이하의 VM이 중단되도록 함

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 명령어를 보여줍니다.

프로젝트의 모든 VM 패치
모든 영역 동시에 패치
지정된 시간에 동일한 영역에서 50% 이하의 VM이 중단되도록 함

gcloud compute os-config patch-jobs execute \
   --instance-filter-all \
   --rollout-mode=concurrent-zones \
   --rollout-disruption-budget-percent=50

REST

이 예시에서는 다음 사양을 통해 패치 작업을 실행하기 위한 patchJobs.execute 메서드를 보여줍니다.

us-central1-a, us-central1-c, us-central1-f 영역의 모든 VM 패치
모든 영역 동시에 패치
지정된 시간에 동일한 영역에서 25% 이하의 인스턴스가 중단되도록 함

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에서 패치 작업을 실행할 때는 기본적으로 패치가 Windows 운영체제에 대한 패치만 적용합니다.

패치 작업을 실행할 때 Windows VM에서 실행되는 Microsoft SQL Server, SharePoint Server, .NET Framework와 같은 Microsoft 소프트웨어에 대해 업데이트를 적용할 수 있습니다. 기본적으로 이러한 애플리케이션 패치 적용은 서비스 중단을 방지하고 이러한 소프트웨어에 대해 계획된 업데이트를 분리하기 위해 사용 중지되어 있습니다. Microsoft 소프트웨어 패치 적용을 자동으로 사용 설정하려면 Windows UI 또는 PowerShell을 사용할 수 있습니다.

Windows UI

Windows Start 메뉴에서 설정 > 업데이트 및 보안 > Windows Update를 선택합니다.
고급 옵션 섹션에서 Windows를 업데이트할 때 다른 Microsoft 제품 업데이트 받기를 켭니다.

PowerShell

 $service_manager = New-Object -ComObject 'Microsoft.Update.ServiceManager'
 $service_manager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"")

패치 작업 디버깅

패치가 실패하면 다음 단계를 수행하여 문제를 찾고 해결할 수 있습니다.

인스턴스 세부정보에서 문제가 발생한 패치 작업을 검토합니다. 이렇게 하면 실패한 인스턴스와 이 인스턴스가 멈춰 있는 상태를 식별할 수 있습니다. 인스턴스 세부정보 목록에는 각 인스턴스의 간략한 오류 메시지도 포함됩니다.

패치가 NO_AGENT_DETECTED 또는 TIMED_OUT 상태로 실패한 경우 이는 일반적으로 서비스에서 패치가 시작되도록 에이전트에 요청을 보냈지만 에이전트에서 응답을 받지 못했음을 의미합니다. 가능한 원인과 해결 방법을 검토하세요.
- 인스턴스가 실행되고 있지 않습니다. 이 문제를 해결하려면 VM 인스턴스를 시작하세요.
- 확인 체크리스트를 사용하여 설정을 확인합니다.
- VPC 네트워크 또는 인스턴스의 네트워크 설정에서 OS 구성 에이전트가 OS Config API와 통신하도록 허용하지 않았습니다. 이 문제를 해결하려면 네트워크 설정을 확인합니다.
인스턴스 세부정보에 포함된 정보가 충분하지 않으면 Cloud Logging 로그 또는 직렬 포트 콘솔을 검토하세요. OS 구성 에이전트는 두 위치 모두에 로그 항목을 작성합니다. Cloud Logging에서 패치 작업 ID를 사용하여 필터링하면 패치 작업과 관련된 모든 로그 항목을 확인할 수 있습니다. VM 또는 Google Cloud 프로젝트 수준에서 osconfig-log-level=debug 메타데이터 값을 설정하여 디버그 로깅을 사용 설정할 수도 있습니다.