O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Visão geral das políticas do agente de operações

As políticas de agente possibilitam a instalação e manutenção automatizadas do agente de operações em uma frota de VMs do Compute Engine que correspondem a critérios especificados pelo usuário. É possível criar uma política para um Google Cloud projeto que administre VMs novas e atuais associadas a esse Google Cloud projeto, garantindo a instalação e desinstalação adequadas do agente de operações nessas VMs.

Políticas de agente para o agente de operações

O suporte a políticas de agente para o agente de operações está disponível em dois níveis de lançamento: GA e Beta. Os dois tipos de políticas dependem dos recursos de configuração do SO fornecidos pelo VM Manager, mas as implementações são diferentes. Recomendamos usar as políticas de disponibilidade geral sempre que possível. Na maioria dos casos, é possível converter políticas Beta em políticas de disponibilidade geral.

Esta seção descreve as diferenças entre as políticas de agente Beta e de disponibilidade geral. Para informações sobre como criar e gerenciar políticas de agente, consulte o seguinte:

Diferenças entre as políticas de agente Beta e de disponibilidade geral

As políticas de agente Beta e de disponibilidade geral diferem das seguintes maneiras:

Mecanismos de criação
- As políticas de agente Beta são criadas usando o seguinte:
  - O grupo de comandos gcloud beta compute instances ops-agents policies no SDK Google Cloud.
  - O agent-policy módulo do Terraform
- As políticas de agente de disponibilidade geral são criadas usando o seguinte:
  - O grupo de comandos gcloud compute instances ops-agents policies no SDK Google Cloud.
  - O módulo do Terraform ops-agent-policy
Suporte ao agente de monitoramento e ao agente do Logging legados
- As políticas de agente Beta podem gerenciar o agente de monitoramento e o agente do Logging legados, bem como o Agente de operações.
- As políticas de agente de disponibilidade geral gerenciam apenas o agente de operações.
Upgrade automático da versão do agente
- As políticas de agente Beta podem manter o agente na versão mais recente fazendo upgrade dele.
- As políticas de agente de disponibilidade geral não oferecem suporte a uma operação de upgrade automático. Para abordagens alternativas, consulte Substituir políticas de upgrade de agente Beta.
Aplicação da política a instâncias nomeadas do Compute Engine
- As políticas de agente Beta podem ser aplicadas a uma lista de instâncias nomeadas.
- As políticas de agente de disponibilidade geral não oferecem suporte a instâncias nomeadas. Para informações sobre como conseguir o mesmo comportamento com políticas de disponibilidade geral, consulte Converter uma política de instância nomeada Beta em uma política de disponibilidade geral.
Aplicação global ou zonal de políticas de agentes em um Google Cloud projeto
- As políticas de agente Beta são aplicadas globalmente a todas as instâncias selecionadas pelos critérios de política no seu Google Cloud projeto.
- As políticas de agente de disponibilidade geral são aplicadas a todas as instâncias selecionadas pelos critérios de política na zona especificada pela política. Por exemplo, uma política criada na zona us-central1-a não tem efeito nas VMs em outras zonas.

As políticas Beta e de disponibilidade geral também são estruturalmente diferentes:

As políticas criadas usando gcloud beta compute instances ops-agents policies descrevem as políticas de agente transmitindo opções individuais aos comandos, por exemplo:

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_ID

O módulo do Terraform agent-policy oferece os mesmos recursos.

As políticas criadas usando gcloud compute instances ops-agents policies descrevem a política de agente usando um arquivo de configuração YAML e uma zona, por exemplo:
```
gcloud compute instances ops-agents policies create test-policy \
  --zone us-central1-a \
  --file test-policy.yaml \
  --project PROJECT_ID
```
O módulo do Terraform ops-agent-policy oferece os mesmos recursos.

Uso de políticas Beta e de disponibilidade geral

É possível usar políticas de agente Beta e de disponibilidade geral com o agente de operações, desde que você considere as diferenças entre os tipos de política.

A maior diferença de comportamento entre as políticas de agente Beta e de disponibilidade geral é que as políticas de disponibilidade geral são zonais e as políticas de agente Beta são globais em um projeto. Ou seja, as políticas de agente de disponibilidade geral selecionam apenas VMs na zona em que a política é criada, mas as políticas Beta podem selecionar qualquer VM no seu Google Cloud projeto.

Se as políticas Beta selecionarem um conjunto de VMs e as políticas de disponibilidade geral selecionarem um conjunto diferente de VMs, as políticas não poderão entrar em conflito.

É possível ter políticas de agente Beta e de disponibilidade geral que se aplicam à mesma VM, mas é necessário garantir que as políticas não tenham propósitos conflitantes, por exemplo, uma política Beta que instala o agente de operações e uma política de disponibilidade geral que desinstala o agente de operações.

Converter políticas Beta em políticas de disponibilidade geral

É possível converter as políticas de agente Beta do agente de operações em políticas de agente de disponibilidade geral, desde que não haja diferenças entre os tipos de política que você não possa contornar. Não é possível converter políticas de agente Beta para o agente de monitoramento ou o agente do Logging legados em políticas de agente de disponibilidade geral.

Para converter políticas de agente Beta em políticas de disponibilidade geral usando o SDK Google Cloud, faça o seguinte:

Gere uma lista de todas as políticas de agente Beta no seu projeto executando o seguinte comando:
```
gcloud beta compute instances ops-agents policies list --project PROJECT_ID
```
Identifique as políticas de agente Beta que você quer converter em políticas de disponibilidade geral.
Para cada política Beta identificada para conversão, faça o seguinte:
1. Crie um arquivo de configuração YAML que seja o mais próximo possível da política Beta considerando as diferenças entre as políticas Beta e de disponibilidade geral. Para informações sobre o formato de configuração YAML, consulte Descrever políticas de agente.
2. Crie uma política de agente de disponibilidade geral em cada zona em que você precisa da política. Para informações sobre como criar políticas de agente de disponibilidade geral, consulte Criar uma política de agente.
3. Exclua a política de agente Beta executando o seguinte comando:
```
gcloud beta compute instances ops-agents policies delete POLICY_ID --project PROJECT_ID
```

Talvez não seja possível gravar uma política de agente de disponibilidade geral para o agente de operações que seja exatamente igual a uma política de agente Beta atual. No entanto, com exceção da opção de upgrade automático da política de agente Beta, é possível ter um comportamento equivalente.

As seções a seguir descrevem como lidar com os seguintes casos:

Políticas de agente Beta que selecionam instâncias nomeadas
Políticas de upgrade de agente Beta

Converter uma política de instância nomeada Beta em uma política de disponibilidade geral

Para converter uma política de agente Beta que é aplicada a um conjunto nomeado de instâncias de VM, faça o seguinte:

Aplique um rótulo às instâncias no conjunto de VMs que você quer selecionar. Para aplicar um rótulo a uma VM atual, use o gcloud compute instances add-labels comando, conforme mostrado no comando a seguir:
```
gcloud compute instances add-labels INSTANCE_NAME --labels=KEY=VALUE
```
Descreva uma política de agente de disponibilidade geral que selecione VMs com o novo rótulo usando a instanceFilter estrutura na configuração. O exemplo a seguir cria um arquivo chamado config.yaml que contém uma política que corresponde ao rótulo aplicado na etapa anterior:
```
cat > config.yaml << EOF
agentsRule:
  packageState: installed
  version: 2.47.0
instanceFilter:
  inclusionLabels:
  - labels:
    KEY: VALUE
EOF
```
Para mais informações sobre como descrever políticas de agente de disponibilidade geral, consulte Arquivos de configuração para políticas de agente.
Crie uma política de agente de disponibilidade geral em cada zona que tenha VMs com o novo rótulo:
```
gcloud compute instances ops-agents policies create POLICY_ID \
  --zone ZONE \
  --file config.yaml
  --project PROJECT_ID
```
Para informações sobre como criar políticas de agente de disponibilidade geral, consulte Criar uma política de agente.

Substituir políticas de upgrade de agente Beta

Para substituir políticas de agente Beta que fazem upgrade do agente, você tem as seguintes opções:

Para garantir que o agente de operações esteja sempre atualizado, use o patch do SO para criar e executar um job de patch do SO que mantenha o agente na versão mais recente.
Para realizar um upgrade único, faça o seguinte:
1. Determine a versão mais recente do agente de operações consultando as notas de lançamento do agente de operações no GitHub.
2. Crie ou modifique uma política de agente que instale a versão mais recente do agente. Por exemplo, se a versão mais recente for 2.70.0, você poderá usar um YAML de política de agente semelhante ao seguinte:
```
agentsRule:
  packageState: installed
  version: 2.70.0
instanceFilter:
[...]
```
3. Aplique a política às VMs em cada zona.

Sistemas operacionais compatíveis

É possível aplicar uma política de agente a instâncias de VM do Compute Engine que executam os sistemas operacionais mostrados na tabela a seguir:

Sistema operacional	Agente de operações (políticas de disponibilidade geral e Beta^†)	Agente de geração de registros (somente políticas Beta^†)	Agente do Monitoring (somente políticas Beta^†)
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)
Deep Learning VM Images baseadas no Debian 11 (Bullseye)
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

^† Nas políticas de agente Beta, as colunas de agente são associadas a um tipo de agente especificado para a invocação gcloud beta compute instances ops-agents policies create:

Agente de operações é associado ao tipo de agente ops-agent.
O agente do Logging é associado ao tipo de agente logging.
O agente do Monitoring é associado ao tipo de agente metrics.

^‡ O agente do Monitoring não é compatível com rhel-7-9-sap-ha, rhel-8-2-sap-ha, ou rhel-8-4-sap-ha.

A seguir

Para informações sobre como usar políticas de agente para gerenciar o agente de operações, consulte o seguinte:

Visão geral das políticas do agente de operações Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.