에이전트 정책을 사용하면 사용자가 지정한 기준과 일치하는 Compute Engine VM Fleet에서 운영 에이전트를 자동으로 설치하고 유지보수할 수 있습니다. 해당Google Cloud 프로젝트와 연결된 기존 VM 및 신규 VM을 제어하는Google Cloud 프로젝트에 대한 정책을 만들어 이러한 VM에서 운영 에이전트의 적절한 설치 및 제거를 보장할 수 있습니다.
운영 에이전트의 에이전트 정책
운영 에이전트의 에이전트 정책 지원은 정식 버전 및 베타의 두 가지 출시 수준에서 사용할 수 있습니다. 두 가지 정책 유형은 VM Manager에서 제공하는 OS 구성 기능을 사용하지만 구현은 다릅니다. 가능하면 정식 버전 정책을 사용하는 것이 좋습니다. 대부분의 경우 베타 정책을 정식 버전 정책으로 변환할 수 있습니다.
이 섹션에서는 베타 및 정식 버전 에이전트 정책의 차이점에 대해 설명합니다. 에이전트 정책을 만들고 관리하는 방법은 다음을 참조하세요.
베타 및 정식 버전 에이전트 정책의 차이점
베타 및 정식 버전 에이전트 정책은 다음과 같은 차이점이 있습니다.
- 생성 메커니즘 - 베타 에이전트 정책은 다음을 통해 생성됩니다.
- 정식 버전 에이전트 정책은 다음을 통해 생성됩니다.
 
- 기존 Monitoring 에이전트 및 Logging 에이전트 지원 - 베타 에이전트 정책은 기존 Monitoring 에이전트 및 Logging 에이전트는 물론 운영 에이전트도 관리할 수 있습니다.
- 정식 버전 에이전트 정책은 운영 에이전트만 관리합니다.
 
- 에이전트 버전 자동 업그레이드 - 베타 에이전트 정책은 에이전트를 업그레이드하여 에이전트를 최신 버전으로 유지할 수 있습니다.
- 정식 버전 에이전트 정책은 자동 업그레이드 작업을 지원하지 않습니다. 대체 접근 방식은 베타 에이전트 업그레이드 정책 바꾸기를 참고하세요.
 
- 이름이 지정된 Compute Engine 인스턴스에 정책 적용 - 베타 에이전트 정책은 명명된 인스턴스 목록에 적용할 수 있습니다.
- 정식 버전 에이전트 정책은 이름이 지정된 인스턴스를 지원하지 않습니다. 정식 버전 정책에서 동일한 동작을 가져오는 방법에 대한 자세한 내용은 이름이 지정된 인스턴스 베타 정책을 정식 버전 정책으로 변환을 참조하세요.
 
- Google Cloud 프로젝트 내 에이전트 정책의 전역 또는 영역별 적용 - 베타 에이전트 정책은 Google Cloud 프로젝트 내에서 정책 기준에 따라 선택된 모든 인스턴스에 전역적으로 적용됩니다.
- 정식 버전 에이전트 정책은 정책이 지정한 영역 내에서 정책 기준에 따라 선택된 모든 인스턴스에 적용됩니다. 예를 들어 us-central1-a영역에서 생성된 정책은 다른 영역의 VM에 영향을 미치지 않습니다.
 
베타 정책과 정식 버전 정책은 구조에도 차이가 있습니다.
- gcloud beta compute instances ops-agents policies를 사용하여 생성된 정책은 명령에 개별 옵션을 전달하여 에이전트 정책을 설명합니다. 예를 들면 다음과 같습니다.- gcloud beta compute instances ops-agents policiescreate ops-agents-test-policy \ --agent-rules="type=logging,enable-autoupgrade=false;type=metrics,enable-autoupgrade=false" \ --description="A test policy." \ --os-types=short-name=centos,version=7 \ --instances=zones/us-central1-a/instances/test-instance \ --project PROJECT_ID- agent-policy Terraform 모듈도 동일한 기능을 제공합니다. 
- gcloud compute instances ops-agents policies를 사용하여 생성된 정책은 YAML 구성 파일과 영역을 사용하여 에이전트 정책을 설명합니다. 예를 들면 다음과 같습니다.- gcloud compute instances ops-agents policiescreate test-policy \ --zone us-central1-a \ --file test-policy.yaml \ --project PROJECT_ID- ops-agent-policy Terraform 모듈도 동일한 기능을 제공합니다. 
베타 및 정식 버전 정책 모두 사용
정책 유형 간의 차이점을 고려하는 한 운영 에이전트와 함께 베타 및 정식 버전 에이전트 정책을 모두 사용할 수 있습니다.
베타 및 정식 버전 에이전트 정책의 가장 큰 동작 차이점은 정식 버전 정책은 영역별이고 베타 에이전트 정책은 프로젝트 내에서 전역적이라는 것입니다. 즉, 정식 버전 에이전트 정책은 정책이 생성되는 영역의 VM만 선택하지만 베타 정책은Google Cloud 프로젝트의 모든 VM을 선택할 수 있습니다.
베타 정책이 VM 집합 하나를 선택하고 정식 버전 정책이 다른 VM 집합을 선택하는 경우 정책이 충돌할 수 없습니다.
동일한 VM에 적용되는 베타 및 정식 버전 에이전트 정책이 있을 수 있지만 운영 에이전트를 설치하는 베타 정책과 운영 에이전트를 제거하는 정식 버전 정책과 같이 두 정책의 용도가 충돌하지 않는지 확인해야 합니다.
베타 정책을 정식 버전 정책으로 변환
해결할 수 없는 정책 유형 간 차이가 없으면 운영 에이전트 베타 에이전트 정책을 정식 버전 에이전트 정책으로 변환할 수 있습니다. 기존 Monitoring 에이전트 또는 Logging 에이전트의 베타 에이전트 정책을 정식 버전 에이전트 정책으로 변환할 수는 없습니다.
Google Cloud SDK를 사용하여 베타 에이전트 정책을 정식 버전 정책으로 변환하려면 다음을 수행합니다.
- 다음 명령어를 실행하여 프로젝트의 모든 베타 에이전트 정책 목록을 생성합니다. - gcloud beta compute instances ops-agents policieslist --project PROJECT_ID
- 정식 버전 정책으로 변환할 베타 에이전트 정책을 식별합니다. 
- 변환하기 위해 식별한 각 베타 정책에 다음을 수행합니다. - 베타 및 정식 버전 정책의 차이점을 고려하여 최대한 베타 정책에 가까운 YAML 구성 파일을 만듭니다. YAML 구성 형식에 대한 자세한 내용은 에이전트 정책 설명을 참고하세요. 
- 정책이 필요한 각 영역에 정식 버전 에이전트 정책을 만듭니다. 정식 버전 에이전트 정책 만들기에 대한 자세한 내용은 에이전트 정책 만들기를 참조하세요. 
- 다음 명령어를 실행하여 베타 에이전트 정책을 삭제합니다. - gcloud beta compute instances ops-agents policiesdelete POLICY_ID --project PROJECT_ID
 
운영 에이전트의 정식 버전 에이전트 정책을 기존 베타 에이전트 정책과 완전히 동일하게 작성하지 못할 수 있습니다. 그러나 베타 에이전트 정책의 자동 업그레이드 옵션을 제외하면 동일한 동작을 가져올 수 있습니다.
다음 섹션에서는 다음 사례를 처리하는 방법을 설명합니다.
이름이 지정된 인스턴스 베타 정책을 정식 버전 정책으로 변환
이름이 지정된 VM 인스턴스 집합에 적용된 베타 에이전트 정책을 변환하려면 다음을 수행하면 됩니다.
- 선택하려는 VM 집합의 인스턴스에 라벨을 적용합니다. 기존 VM에 라벨을 적용하려면 다음 명령어와 같이 - gcloud compute instances add-labels명령어를 사용합니다.- gcloud compute instances add-labels INSTANCE_NAME --labels=KEY=VALUE
- 구성에서 - instanceFilter구조를 사용하여 새 라벨이 있는 VM을 선택하는 정식 버전 에이전트 정책을 설명합니다. 다음 예시에서는 이전 단계에서 적용된 라벨과 일치하는 정책이 포함된- config.yaml이라는 파일을 만듭니다.- cat > config.yaml << EOF agentsRule: packageState: installed version: 2.47.0 instanceFilter: inclusionLabels: - labels: KEY: VALUE EOF- 정식 버전 에이전트 정책 설명에 대한 자세한 내용은 에이전트 정책 구성 파일을 참조하세요. 
- 새 라벨이 지정된 VM이 있는 각 영역에 정식 버전 에이전트 정책을 만듭니다. - gcloud compute instances ops-agents policiescreate POLICY_ID \ --zone ZONE \ --file config.yaml --project PROJECT_ID- 정식 버전 에이전트 정책 만들기에 대한 자세한 내용은 에이전트 정책 만들기를 참조하세요. 
베타 에이전트 업그레이드 정책 교체
에이전트를 업그레이드하는 베타 에이전트 정책을 교체하려는 경우 다음 옵션이 있습니다.
- 운영 에이전트를 항상 최신 상태로 유지하려면 OS 패치를 사용하여 에이전트를 최신 상태로 유지하는 OS 패치 작업을 만들고 실행합니다.
- 일회성 업그레이드를 수행하려면 다음과 같이 하세요. - 운영 에이전트 GitHub의 출시 노트를 참고하여 운영 에이전트의 최신 버전을 확인합니다.
- 최신 에이전트 버전을 설치하는 에이전트 정책을 만들거나 수정합니다. 예를 들어 최신 버전이 2.60.0인 경우 다음과 비슷한 에이전트 정책 YAML을 사용할 수 있습니다. - agentsRule: packageState: installed version: 2.60.0 instanceFilter: [...]
- 각 영역의 VM에 정책을 적용합니다. 
 
지원되는 운영체제
다음 표에 표시된 운영체제를 실행하는 Compute Engine VM 인스턴스에 에이전트 정책을 적용할 수 있습니다.
| 운영체제 | 운영 에이전트 (정식 버전 및 베타† 정책) | Logging 에이전트 (베타† 정책만 해당) | Monitoring 에이전트 (베타† 정책만 해당) | 
|---|---|---|---|
| CentOS 8 | |||
| Rocky Linux 8 | |||
| RHEL 6 | |||
| RHEL 7: rhel-7, rhel-7-6-sap-ha, rhel-7-7-sap-ha, rhel-7-9-sap-ha | ‡ | ||
| RHEL 8: rhel-8, rhel-8-4-sap-ha, rhel-8-6-sap-ha, rhel-8-8-sap-ha | ‡ | ||
| Debian 9(Stretch) | |||
| Debian 11(Bullseye) | |||
| Debian 11(Bullseye) 기반의 Deep Learning VM Image | |||
| Ubuntu LTS 18.04(Bionic Beaver): ubuntu-1804-lts, ubuntu-minimal-1804-lts | |||
| Ubuntu LTS 20.04(Focal Fossa): ubuntu-2004-lts, ubuntu-minimal-2004-lts | |||
| Ubuntu LTS 22.04(Jammy Jellyfish): buntu-2204-lts, ubuntu-minimal-2204-lts | |||
| SLES 12: sles-12, sles-12-sp5-sap | |||
| SLES 15: sles-15, sles-15-sp2-sap, sles-15-sp3-sap, sles-15-sp4-sap, sles-15-sp5-sap, sles-15-sp6-sap | |||
| OpenSUSE Leap 15: opensuse-leap(opensuse-leap-15-3-*, opensuse-leap-15-4-*) | |||
| Windows Server: 2016, 2019, 2022, Core 2016, Core 2019, Core 2022 | 
gcloud beta compute instances ops-agents policies create 호출에 지정된 에이전트 유형에 매핑됩니다.
  - 운영 에이전트는 에이전트 유형 ops-agent에 매핑됩니다.
- Logging 에이전트는 에이전트 유형 logging에 매핑됩니다.
- Monitoring 에이전트는 에이전트 유형 metrics에 매핑됩니다.
rhel-7-9-sap-ha, rhel-8-2-sap-ha, rhel-8-4-sap-ha에서 지원되지 않습니다.
다음 단계
에이전트 정책을 사용하여 운영 에이전트를 관리하는 방법에 대한 자세한 내용은 다음을 참고하세요.