Esta página se ha traducido con Cloud Translation API.

Información general sobre las políticas de agente del agente de operaciones

Las políticas de agente permiten instalar y mantener automáticamente el agente de operaciones en un conjunto de VMs de Compute Engine que cumplan los criterios especificados por el usuario. Puedes crear una política para unGoogle Cloud proyecto que rija las VMs asociadas a eseGoogle Cloud proyecto, tanto las que ya tengas como las nuevas, para asegurarte de que el agente de Ops se instale y desinstale correctamente en esas VMs.

Políticas de agente del agente de operaciones

La compatibilidad con las políticas de agente del agente de operaciones está disponible en dos niveles de lanzamiento: disponibilidad general y beta. Ambos tipos de políticas se basan en las funciones de Configuración del SO que ofrece VM Manager, pero las implementaciones son diferentes. Le recomendamos que utilice las políticas de GA siempre que sea posible. En la mayoría de los casos, puede convertir políticas beta en políticas de disponibilidad general.

En esta sección se describen las diferencias entre las políticas de agente beta y las de GA. Para obtener información sobre cómo crear y gestionar políticas de agente, consulta los siguientes artículos:

Diferencias entre las políticas de agentes beta y GA

Las políticas de los agentes beta y de los agentes de disponibilidad general se diferencian en lo siguiente:

Mecanismos de creación
- Las políticas de agentes beta se crean con lo siguiente:
  - El gcloud beta compute instances ops-agents policies grupo de comandos del SDK de Google Cloud.
  - El agent-policy módulo de Terraform
- Las políticas de agente de GA se crean con lo siguiente:
  - El gcloud compute instances ops-agents policies grupo de comandos del SDK de Google Cloud.
  - El ops-agent-policy módulo de Terraform
Compatibilidad con los agentes de Monitoring y Logging antiguos
- Las políticas de agentes beta pueden gestionar los agentes de Monitoring y Logging antiguos, así como el agente de operaciones.
- Las políticas de agente de disponibilidad general solo gestionan el agente de operaciones.
Actualización automática de la versión del agente
- Las políticas de agentes beta pueden mantener el agente en la versión más reciente actualizándolo.
- Las políticas de agentes de GA no admiten la operación de actualización automática. Para ver otras opciones, consulta Reemplazar políticas de actualización de agentes beta.
Aplicación de políticas a instancias de Compute Engine con nombre
- Las políticas de agentes beta se pueden aplicar a una lista de instancias con nombre.
- Las políticas de agentes de GA no admiten instancias con nombre. Para obtener información sobre cómo conseguir el mismo comportamiento con las políticas de GA, consulte Convertir una política de instancia con nombre beta en una política de GA.
Aplicación global o por zonas de las políticas de agentes en un Google Cloud proyecto
- Las políticas de agente beta se aplican de forma global a todas las instancias seleccionadas por los criterios de la política de tu proyecto Google Cloud .
- Las políticas de agente de GA se aplican a todas las instancias seleccionadas por los criterios de la política en la zona que especifica la política. Por ejemplo, una política creada en la zona us-central1-a no tiene ningún efecto en las máquinas virtuales de otras zonas.

Las políticas de la versión beta y de la versión GA también son estructuralmente diferentes:

Las políticas creadas con gcloud beta compute instances ops-agents policies describen las políticas de agentes pasando opciones individuales a los comandos, por ejemplo:

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

El módulo de Terraform agent-policy ofrece las mismas funciones.

Las políticas creadas con gcloud compute instances ops-agents policies describen la política del agente mediante un archivo de configuración YAML y una zona. Por ejemplo:
```
gcloud compute instances ops-agents policies create test-policy \
  --zone us-central1-a \
  --file test-policy.yaml \
  --project PROJECT_ID
```
El módulo de Terraform ops-agent-policy ofrece las mismas funciones.

Uso de políticas beta y GA

Puedes usar políticas de agente beta y GA con el agente de operaciones, siempre que tengas en cuenta las diferencias entre los tipos de políticas.

La mayor diferencia de comportamiento entre las políticas de agente beta y las de GA es que las políticas de GA son zonales, mientras que las políticas de agente beta son globales en un proyecto. Es decir, las políticas de agente de GA solo seleccionan las VMs de la zona en la que se crea la política, pero las políticas beta pueden seleccionar cualquier VM de tu proyecto.Google Cloud

Si las políticas beta seleccionan un conjunto de máquinas virtuales y las políticas GA seleccionan otro conjunto de máquinas virtuales, las políticas no pueden entrar en conflicto.

Puedes tener políticas de agente beta y GA que se apliquen a la misma VM, pero debes asegurarte de que las políticas no tengan finalidades contradictorias. Por ejemplo, una política beta que instale el agente de operaciones y una política GA que lo desinstale.

Convertir políticas beta en políticas de disponibilidad general

Puedes convertir tus políticas de agente beta de Ops Agent en políticas de agente de GA, siempre que no haya diferencias entre los tipos de políticas que no puedas solucionar. No puedes convertir las políticas de agentes beta del agente de monitorización o del agente de registro antiguos en políticas de agentes de disponibilidad general.

Para convertir políticas de agente beta en políticas de disponibilidad general mediante el SDK de Google Cloud, haz lo siguiente:

Para generar una lista de todas las políticas de agente beta de tu proyecto, ejecuta el siguiente comando:
```
gcloud beta compute instances ops-agents policies list --project PROJECT_ID
```
Identifica las políticas de agente beta que quieras convertir en políticas de GA.
Por cada política beta que identifiques para la conversión, haz lo siguiente:
1. Crea un archivo de configuración YAML que se parezca lo máximo posible a la política beta, teniendo en cuenta las diferencias entre las políticas beta y GA. Para obtener información sobre el formato de configuración YAML, consulta Describe agent policies (Describe las políticas de agentes).
2. Crea una política de agente de GA en cada zona en la que necesites la política. Para obtener información sobre cómo crear políticas de agente de GA, consulta Crear una política de agente.
3. Elimina la política del agente beta ejecutando el siguiente comando:
```
gcloud beta compute instances ops-agents policies delete POLICY_ID --project PROJECT_ID
```

Es posible que no puedas escribir una política de agente de GA para el agente de operaciones que sea exactamente igual que una política de agente beta. Sin embargo, a excepción de la opción de actualización automática de la política del agente beta, puedes obtener un comportamiento equivalente.

En las siguientes secciones se describe cómo gestionar los siguientes casos:

Políticas de agente beta que seleccionan instancias con nombre
Políticas de actualización de agentes beta

Convertir una política de instancia con nombre beta en una política de disponibilidad general

Para convertir una política de agente beta que se aplica a un conjunto de instancias de VM con nombre, puedes hacer lo siguiente:

Aplica una etiqueta a las instancias del conjunto de VMs que quieras seleccionar. Para aplicar una etiqueta a una VM, usa el comando gcloud compute instances add-labels, como se muestra en el siguiente comando:
```
gcloud compute instances add-labels INSTANCE_NAME --labels=KEY=VALUE
```
Describe una política de agente de GA que seleccione las VMs con la nueva etiqueta mediante la estructura instanceFilter en la configuración. En el siguiente ejemplo, se crea un archivo llamado config.yaml que contiene una política que coincide con la etiqueta aplicada en el paso anterior:
```
cat > config.yaml << EOF
agentsRule:
  packageState: installed
  version: 2.47.0
instanceFilter:
  inclusionLabels:
  - labels:
    KEY: VALUE
EOF
```
Para obtener más información sobre cómo describir las políticas de agentes de GA, consulta Archivos de configuración de políticas de agentes.
Crea una política de agente de GA en cada zona que tenga VMs con la nueva etiqueta:
```
gcloud compute instances ops-agents policies create POLICY_ID \
  --zone ZONE \
  --file config.yaml
  --project PROJECT_ID
```
Para obtener más información sobre cómo crear políticas de agente de GA, consulta el artículo Crear una política de agente.

Sustituir las políticas de actualización de agentes beta

Para sustituir las políticas de agente beta que actualizan el agente, tienes las siguientes opciones:

Para asegurarte de que el agente de operaciones esté siempre actualizado, usa Gestión de parches de SO para crear y ejecutar un trabajo de gestión de parches de SO que mantenga el agente en la versión más reciente.
Para hacer una actualización única, sigue estos pasos:
1. Para determinar la versión más reciente del agente de operaciones, consulta las notas de la versión del agente de operaciones en GitHub.
2. Crea o modifica una política de agente que instale la versión más reciente del agente. Por ejemplo, si la versión más reciente es la 2.57.0, puedes usar un archivo YAML de política de agente similar al siguiente:
```
agentsRule:
  packageState: installed
  version: 2.57.0
instanceFilter:
[...]
```
3. Aplica la política a las VMs de cada zona.

Sistemas operativos compatibles

Puedes aplicar una política de agente a las instancias de máquina virtual de Compute Engine que ejecuten los sistemas operativos que se muestran en la siguiente tabla:

Sistema operativo	Agente de operaciones (políticas de disponibilidad general y beta^†)	Agente de Logging (solo políticas beta^†)	Agente de monitorización (solo 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)
Imágenes de máquinas virtuales de aprendizaje profundo basadas en 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): ubuntu-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 y Core 2022

^† En las políticas de agentes beta, las columnas de agentes se asignan a un tipo de agente especificado en la gcloud beta compute instances ops-agents policies create invocación:

Agente de operaciones se asigna al tipo de agente ops-agent.
El agente de Logging se asigna al tipo de agente logging.
Agente de monitorización se asigna al tipo de agente metrics.

^‡ El agente de monitorización no es compatible con rhel-7-9-sap-ha, rhel-8-2-sap-ha ni rhel-8-4-sap-ha.

Siguientes pasos

Para obtener información sobre cómo usar las políticas de agente para gestionar el agente de operaciones, consulta lo siguiente:

Información general sobre las políticas de agente del agente de operaciones Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.