에이전트 정책을 사용하면 사용자가 지정한 기준과 일치하는 Compute Engine VM Fleet에서 운영 에이전트를 자동으로 설치하고 유지보수할 수 있습니다. 하나의 명령어로 해당 Google Cloud 프로젝트와 연결된 기존 VM과 신규 VM을 제어하는 Google Cloud 프로젝트에 대한 정책을 만들어 운영 에이전트의 적절한 설치 및 제거를 보장할 수 있습니다.
운영 에이전트의 에이전트 정책
운영 에이전트의 에이전트 정책 지원은 정식 버전 및 베타 버전의 두 가지 출시 수준으로 Google Cloud SDK에서 제공됩니다. 두 정책 유형 모두 VM Manager에서 제공하는 OS 구성 기능에 의존하지만 구현은 다릅니다. 가능하면 정식 버전 정책을 사용하는 것이 좋습니다. 대부분의 경우 베타 정책을 정식 버전 정책으로 변환할 수 있습니다.
이 섹션에서는 베타 및 정식 버전 에이전트 정책의 차이점에 대해 설명합니다. 에이전트 정책을 만들고 관리하는 방법은 다음을 참조하세요.
베타 및 정식 버전 에이전트 정책의 차이점
베타 및 정식 버전 compute instances ops-agents policies
명령어 그룹에서 만든 에이전트 정책은 다음과 같은 점에서 차이가 있습니다.
기존 Monitoring 에이전트 및 Logging 에이전트 지원
- 베타 에이전트 정책은 기존 Monitoring 에이전트 및 Logging 에이전트는 물론 운영 에이전트도 관리할 수 있습니다.
- 정식 버전 에이전트 정책은 운영 에이전트만 관리합니다.
에이전트 버전 자동 업그레이드
- 베타 에이전트 정책은 에이전트를 업그레이드하여 에이전트를 최신 버전으로 유지할 수 있습니다.
- 정식 버전 에이전트 정책은 자동 업그레이드 작업을 지원하지 않습니다. 다른 접근 방식은 베타 에이전트 업그레이드 정책 대체를 참조하세요.
명명된 Compute Engine 인스턴스에 정책 적용
- 베타 에이전트 정책은 이름이 지정된 인스턴스 목록에 적용할 수 있습니다.
- 정식 버전 에이전트 정책은 이름이 지정된 인스턴스를 지원하지 않습니다. 정식 버전 정책에서 동일한 동작을 가져오는 방법에 대한 자세한 내용은 이름이 지정된 인스턴스 베타 정책을 정식 버전 정책으로 변환을 참조하세요.
Google Cloud 프로젝트 내 에이전트 정책의 전역 또는 영역별 적용
- 베타 에이전트 정책은 Google Cloud 프로젝트 내에서 정책 기준에 따라 선택된 모든 인스턴스에 전역적으로 적용됩니다.
- 정식 버전 에이전트 정책은 정책이 지정한 영역 내에서 정책 기준에 따라 선택된 모든 인스턴스에 적용됩니다. 예를 들어
us-central1-a
영역에서 생성된 정책은 다른 영역의 VM에 영향을 미치지 않습니다.
베타 및 정식 버전 compute instances ops-agents policies
명령어 그룹도 구조적으로 다릅니다.
gcloud beta compute instances ops-agents policies
명령어는 개별 옵션을 명령어에 전달하여 에이전트 정책을 설명합니다. 예를 들면 다음과 같습니다.gcloud beta compute instances ops-agents policies
create 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_IDgcloud compute instances ops-agents policies
명령어는 YAML 구성 파일과 영역을 사용하여 에이전트 정책을 설명합니다. 예를 들면 다음과 같습니다.gcloud compute instances ops-agents policies
create test-policy \ --zone us-central1-a \ --file test-policy.yaml \ --project PROJECT_ID
베타 및 정식 버전 정책 모두 사용
정책 유형 간의 차이점을 고려하는 한 운영 에이전트와 함께 베타 및 정식 버전 에이전트 정책을 모두 사용할 수 있습니다.
베타 및 정식 버전 에이전트 정책의 가장 큰 동작 차이점은 정식 버전 정책은 영역별이고 베타 에이전트 정책은 프로젝트 내에서 전역적이라는 것입니다. 즉, 정식 버전 에이전트 정책은 정책이 생성되는 영역의 VM만 선택하지만 베타 정책은 Google Cloud 프로젝트의 모든 VM을 선택할 수 있습니다.
베타 정책이 VM 집합 하나를 선택하고 정식 버전 정책이 다른 VM 집합을 선택하는 경우 정책이 충돌할 수 없습니다.
동일한 VM에 적용되는 베타 및 정식 버전 에이전트 정책이 있을 수 있지만 운영 에이전트를 설치하는 베타 정책과 운영 에이전트를 제거하는 정식 버전 정책과 같이 두 정책의 용도가 충돌하지 않는지 확인해야 합니다.
베타 정책을 정식 버전 정책으로 변환
해결할 수 없는 정책 유형 간 차이가 없으면 운영 에이전트 베타 에이전트 정책을 정식 버전 에이전트 정책으로 변환할 수 있습니다. 기존 Monitoring 에이전트 또는 Logging 에이전트의 베타 에이전트 정책을 정식 버전 에이전트 정책으로 변환할 수는 없습니다.
베타 에이전트 정책을 정식 버전 정책으로 변환하려면 다음을 수행합니다.
다음 명령어를 실행하여 프로젝트의 모든 베타 에이전트 정책 목록을 생성합니다.
gcloud beta compute instances ops-agents policies
list --project PROJECT_ID정식 버전 정책으로 변환할 베타 에이전트 정책을 식별합니다.
전환하기 위해 식별한 각 베타 정책에 다음을 수행합니다.
베타 및 정식 버전 정책의 차이점을 고려하여 최대한 베타 정책에 가까운 YAML 구성 파일을 만듭니다. YAML 구성 형식에 대한 자세한 내용은 에이전트 정책 설명을 참조하세요.
정책이 필요한 각 영역에 정식 버전 에이전트 정책을 만듭니다. 정식 버전 에이전트 정책 만들기에 대한 자세한 내용은 에이전트 정책 만들기를 참조하세요.
다음 명령어를 실행하여 베타 에이전트 정책을 삭제합니다.
gcloud beta compute instances ops-agents policies
delete 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 policies
create POLICY_ID \ --zone ZONE \ --file config.yaml --project PROJECT_ID정식 버전 에이전트 정책 만들기에 대한 자세한 내용은 에이전트 정책 만들기를 참조하세요.
베타 에이전트 업그레이드 정책 교체
에이전트를 업그레이드하는 베타 에이전트 정책을 교체하려는 경우 다음 옵션이 있습니다.
- 운영 에이전트를 항상 최신 상태로 유지하려면 OS 패치를 사용하여 에이전트를 최신 상태로 유지하는 OS 패치 작업을 만들고 실행합니다.
일회성 업그레이드를 수행하려면 다음과 같이 하세요.
- GitHub의 운영 에이전트 출시 노트를 참조하여 운영 에이전트의 최신 버전을 확인합니다.
최신 에이전트 버전을 설치하는 에이전트 정책을 만들거나 수정합니다. 예를 들어 최신 버전이 2.46.0인 경우 다음과 유사한 에이전트 정책 YAML을 사용할 수 있습니다.
agentsRule: packageState: installed version: 2.46.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
에서 지원되지 않습니다.
다음 단계
에이전트 정책을 사용하여 운영 에이전트를 관리하는 방법은 다음을 참조하세요.