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 projeto do Google Cloud que administre VMs novas e existentes associadas a esse projeto do Google Cloud, garantindo a instalação e desinstalação adequada do agente de operações nessas VMs.
Políticas de agentes 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. Ambos os tipos de políticas dependem de recursos da Configuração do SO fornecidos pelo VM Manager, mas as implementações são diferentes. Recomendamos usar as políticas do GA sempre que possível. Na maioria dos casos, é possível converter políticas Beta em políticas GA.
Esta seção descreve as diferenças entre as políticas de agente Beta e GA. Para saber como criar e gerenciar políticas de agente, consulte:
Diferenças entre as políticas de agente Beta e GA
As políticas de agente Beta e GA 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 módulo
agent-policy
do Terraform
- O grupo de comandos
- As políticas de agente do GA são criadas usando o seguinte:
- O grupo de comandos
gcloud compute instances ops-agents policies
no SDK Google Cloud. - O módulo
ops-agent-policy
do Terraform
- O grupo de comandos
- As políticas de agente Beta são criadas usando o seguinte:
Suporte para o agente legado do Monitoring e do Logging
- As políticas de agente Beta podem gerenciar o agente legado do Monitoring e do Logging, bem como o agente de operações.
- As políticas de agentes do GA gerenciam apenas o agente de operações.
Upgrade automático da versão do agente
- As políticas de agentes Beta podem manter o agente na versão mais recente fazendo upgrade dele.
- As políticas de agente do GA não são compatíveis com uma operação de upgrade automático. Para abordagens alternativas, consulte Substituir políticas de upgrade do agente Beta.
Aplicação de políticas 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 agentes do GA não oferecem suporte a instâncias nomeadas. Para saber como ter o mesmo comportamento com as 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 regional de políticas de agentes em um projeto do Google Cloud
- As políticas do agente Beta são aplicadas globalmente a todas as instâncias selecionadas pelos critérios de política no seu projeto do Google Cloud.
- As políticas do agente do GA são aplicadas a todas as instâncias selecionadas pelos critérios da política na zona especificada. Por exemplo,
uma política criada na zona
us-central1-a
não afeta as VMs em outras zonas.
As políticas Beta e GA também são estruturalmente diferentes:
As políticas criadas usando
gcloud beta compute instances ops-agents policies
descrevem as políticas de agentes 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_IDO módulo do Terraform de política do agente oferece os mesmos recursos.
As políticas de pesquisa criadas usando o
gcloud compute instances ops-agents policies
descrevem a política do 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_IDO módulo Terraform ops-agent-policy oferece os mesmos recursos.
Uso das políticas Beta e GA
É possível usar políticas de agente Beta e GA com o Agente de operações, desde que você considere as diferenças entre os tipos de política.
A maior diferença comportamental entre as políticas de agente Beta e GA é que as políticas do GA são zonais, e as políticas de agente Beta são globais em um 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 projeto do Google Cloud.
Se as políticas Beta selecionarem um conjunto de VMs e as políticas de GA selecionarem um conjunto diferente de VMs, elas não poderão entrar em conflito.
É possível ter políticas de agente Beta e GA que se aplicam à mesma VM, mas é necessário garantir que elas não tenham finalidades conflitantes. Por exemplo, uma política Beta que instala o agente de operações e uma política GA que desinstala o agente de operações.
Converter políticas Beta em políticas GA
É possível converter as políticas de agente Beta do Agente de operações em políticas de agente GA, desde que não haja diferenças entre os tipos de política que não possam ser contornadas. Não é possível converter políticas de agente Beta para o agente de monitoramento ou de registro legado em políticas de agente GA.
Para converter políticas de agente Beta em políticas de GA 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_IDIdentifique as políticas de agente Beta que você quer converter em políticas do GA.
Para cada política Beta que você identificar para conversão, faça o seguinte:
Crie um arquivo de configuração YAML o mais próximo possível da política Beta, considerando as diferenças entre as políticas Beta e GA. Para informações sobre o formato de configuração YAML, consulte Descrever políticas do agente.
Crie uma política de agente do GA em cada zona em que você precisa dela. Para informações sobre como criar políticas de agente do GA, consulte Criar uma política de agente.
Exclua a política do 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 escrever uma política de agente GA para o Agente de operações que seja exatamente igual a uma política de agente Beta. 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:
Converter uma política de instância nomeada Beta em uma política de lançamento oficial
Para converter uma política de agente Beta 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, use o comando
gcloud compute instances add-labels
, como mostrado no comando a seguir:gcloud compute instances add-labels INSTANCE_NAME --labels=KEY=VALUE
Descreva uma política do agente do GA que seleciona VMs com o novo rótulo usando a estrutura
instanceFilter
na configuração. O exemplo a seguir cria um arquivo chamadoconfig.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 agentes do GA, consulte Arquivos de configuração para políticas de agentes.
Crie uma política do agente do GA 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_IDPara mais informações sobre como criar políticas de agentes do GA, consulte Criar uma política de agente.
Substituir políticas de upgrade de agente Beta
Para substituir as 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 Correção do SO para criar e executar um job de correção do SO que mantenha o agente na versão mais recente.
Para fazer um upgrade único, siga estas etapas:
- Determine a versão mais recente do agente de operações consultando as notas da versão do agente de operações no GitHub.
Crie ou modifique uma política de agente que instale a versão mais recente. Por exemplo, se a versão mais recente for 2.51.0, use um YAML de política do agente semelhante a este:
agentsRule: packageState: installed version: 2.51.0 instanceFilter: [...]
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 |
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
.
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: