Esta página foi traduzida pela API Cloud Translation.

Vista geral das políticas do agente para o agente de operações

As políticas de agente permitem a instalação e a manutenção automáticas do agente de operações numa frota de VMs do Compute Engine que correspondem aos critérios especificados pelo utilizador. Pode criar uma política para um Google Cloud projeto que rege as VMs existentes e novas associadas a esse Google Cloud projeto, garantindo a instalação e a desinstalação adequadas do agente de operações nessas VMs.

Políticas do agente para o Ops Agent

O suporte para políticas de agentes para o agente de operações está disponível em dois níveis de lançamento: disponibilidade geral e beta. Ambos os tipos de políticas baseiam-se nas funcionalidades da configuração do SO fornecidas pelo VM Manager, mas as implementações são diferentes. Recomendamos que use as políticas do GA sempre que possível. Na maioria dos casos, pode converter políticas beta em políticas de disponibilidade geral (GA).

Esta secção descreve as diferenças entre as políticas de agentes beta e GA. Para obter informações sobre a criação e a gestão de políticas de agentes, consulte o seguinte:

Diferenças entre as políticas de agentes beta e GA

As políticas de agentes beta e GA diferem nos seguintes aspetos:

Mecanismos de criação
- As políticas de agentes beta são criadas através do seguinte:
  - O gcloud beta compute instances ops-agents policies grupo de comandos no SDK Cloud da Google.
  - O agent-policy módulo do Terraform
- As políticas de agentes do GA são criadas através do seguinte:
  - O gcloud compute instances ops-agents policies grupo de comandos no SDK Cloud da Google.
  - O ops-agent-policy módulo do Terraform
Suporte para o agente de monitorização e o agente de registo antigos
- As políticas de agentes beta podem gerir o agente de monitorização e o agente de registos antigos, bem como o agente de operações.
- As políticas do agente do GA gerem apenas o agente de operações.
Atualização automática da versão do agente
- As políticas de agentes beta podem manter o agente na versão mais recente através da atualização do agente.
- As políticas de agentes do GA não suportam uma operação de atualização automática. Para abordagens alternativas, consulte o artigo Substitua as políticas de atualização de agentes beta.
Aplicação da política a instâncias do Compute Engine com nome
- As políticas de agentes beta podem ser aplicadas a uma lista de instâncias denominadas.
- As políticas de agentes do GA não oferecem apoio técnico para instâncias com nome. Para informações sobre como obter o mesmo comportamento com as políticas do GA, consulte o artigo Converta uma política de instância com nome beta numa política do GA.
Aplicação global ou zonal de políticas de agentes num Google Cloud projeto
- As políticas de agentes beta são aplicadas globalmente a todas as instâncias selecionadas pelos critérios da política no seu Google Cloud projeto.
- As políticas de agentes da GA são aplicadas a todas as instâncias selecionadas pelos critérios da 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 noutras zonas.

As políticas beta e de GA também são estruturalmente diferentes:

As políticas criadas através de gcloud beta compute instances ops-agents policies descrevem as políticas do 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 Terraform agent-policy oferece as mesmas capacidades.

As políticas criadas através do comando gcloud compute instances ops-agents policies descrevem a política do agente através de um ficheiro 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 Terraform ops-agent-policy oferece as mesmas capacidades.

Utilização de políticas beta e GA

Pode usar políticas de agentes beta e de GA com o agente de operações, desde que considere as diferenças entre os tipos de políticas.

A maior diferença comportamental entre as políticas de agentes beta e GA é que as políticas de GA são zonais e as políticas de agentes beta são globais num projeto. Ou seja, as políticas de agente do GA selecionam apenas VMs na zona em que a política é criada, mas as políticas beta podem selecionar qualquer VM no seu projetoGoogle Cloud .

Se as políticas beta selecionarem um conjunto de VMs e as políticas de GA selecionarem um conjunto diferente de VMs, as políticas não podem entrar em conflito.

Pode ter políticas de agente beta e de disponibilidade geral que se aplicam à mesma VM, mas tem de garantir que as políticas não têm finalidades em conflito, 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.

Converta políticas beta em políticas de disponibilidade geral

Pode converter as suas políticas de agente beta do Ops Agent em políticas de agente de GA, desde que não existam diferenças entre os tipos de políticas que não consiga contornar. Não pode converter políticas de agentes beta para políticas de agentes de GA para o agente de monitorização ou o agente de registo antigos.

Para converter políticas de agente beta em políticas de GA através do SDK do Google Cloud, faça o seguinte:

Gere uma lista de todas as políticas de agentes beta no seu projeto executando o seguinte comando:
```
gcloud beta compute instances ops-agents policies list --project PROJECT_ID
```
Identifique as políticas de agentes beta que quer converter em políticas de disponibilidade geral.
Para cada política beta que identificar para conversão, faça o seguinte:
1. Crie um ficheiro de configuração YAML o mais próximo possível da política beta, tendo em conta as diferenças entre as políticas beta e GA. Para obter informações sobre o formato de configuração YAML, consulte o artigo Descreva as políticas do agente.
2. Crie uma política de agente do GA em cada zona onde precisa da política. Para obter informações sobre como criar políticas de agentes do GA, consulte o artigo Crie uma política de agente.
3. Elimine a política do agente beta executando o seguinte comando:
```
gcloud beta compute instances ops-agents policies delete POLICY_ID --project PROJECT_ID
```

Pode não conseguir escrever uma política do agente do GA para o agente de operações que seja exatamente igual a uma política do agente beta existente. No entanto, com exceção da opção de atualização automática da política do agente beta, pode obter um comportamento equivalente.

As secções seguintes descrevem como processar os seguintes casos:

Políticas de agentes beta que selecionam instâncias com nome
Políticas de atualização de agentes beta

Converta uma política de instância com nome beta numa política de GA

Para converter uma política de agente beta aplicada a um conjunto designado de instâncias de VM, pode fazer o seguinte:

Aplique uma etiqueta às instâncias no conjunto de VMs que quer selecionar. Para aplicar uma etiqueta a uma VM existente, use o comando gcloud compute instances add-labels, conforme mostrado no comando seguinte:
```
gcloud compute instances add-labels INSTANCE_NAME --labels=KEY=VALUE
```
Descreva uma política de agente do GA que selecione VMs com a nova etiqueta através da estrutura instanceFilter na configuração. O exemplo seguinte cria um ficheiro denominado config.yaml que contém uma política que corresponde à etiqueta aplicada no passo 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 agentes do GA, consulte o artigo Ficheiros de configuração para políticas de agentes.
Crie uma política de agente do GA em cada zona que tenha VMs com a nova etiqueta:
```
gcloud compute instances ops-agents policies create POLICY_ID \
  --zone ZONE \
  --file config.yaml
  --project PROJECT_ID
```
Para mais informações sobre a criação de políticas de agentes da GA, consulte o artigo Crie uma política de agente.

Substitua as políticas de atualização de agentes beta

Para substituir as políticas de agentes beta que atualizam o agente, tem as seguintes opções:

Para se certificar de que o agente de operações está sempre atualizado, use o patch do SO para criar e executar uma tarefa de patch do SO que mantém o agente na versão mais recente.
Para fazer uma atualização única, 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.57.0, pode usar um YAML de política do agente semelhante ao seguinte:
```
agentsRule:
  packageState: installed
  version: 2.57.0
instanceFilter:
[...]
```
3. Aplique a política às VMs em cada zona.

Sistemas operativos compatíveis

Pode aplicar uma política de agente a instâncias de VM do Compute Engine que executam os sistemas operativos apresentados na tabela seguinte:

Sistema operativo	Ops Agent (Políticas de GA e beta^†)	Agente de registos (apenas para políticas ^† beta)	Agente de monitorização (apenas 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)
Imagens de VMs de aprendizagem avançada 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 agentes beta, as colunas de agentes são mapeadas para um tipo de agente especificado para a gcloud beta compute instances ops-agents policies invocação create:

O Ops Agent é mapeado para o tipo de agente ops-agent.
O agente de registos é mapeado para o tipo de agente logging.
O agente de monitorização é mapeado para o tipo de agente metrics.

^‡ O agente de monitorização não é suportado no rhel-7-9-sap-ha, rhel-8-2-sap-ha nem no rhel-8-4-sap-ha.

O que se segue?

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

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