Présentation des règles d'agent pour l'agent Ops

Les règles d'agent permettent d'automatiser l'installation et la maintenance Agent Ops sur un parc de VM Compute Engine correspondant en fonction de critères définis par l'utilisateur. Vous pouvez créer une règle pour un projet Google Cloud qui régit les VM nouvelles et existantes associées à ce projet Google Cloud, afin d'assurer l'installation et la désinstallation appropriées de l'agent Ops sur ces VM.

Stratégies d'agent pour l'agent Ops

La prise en charge des règles d'agent pour l'agent Ops est disponible à deux niveaux de version : GA et bêta. Les deux types de stratégies reposent sur les fonctionnalités OS Config fournies par VM Manager, mais les implémentations sont différentes. Nous vous recommandons d'utiliser les règles GA dans la mesure du possible. Dans la plupart des cas, vous pouvez convertir les règles bêta en règles GA.

Cette section décrit les différences entre les règles d'agent bêta et DG. Pour en savoir plus sur la création et la gestion des règles d'agent, consultez les pages suivantes:

Différences entre les règles de l'agent bêta et de l'agent DG

Voici les différences qui existent entre les règles de la version bêta et celles de l'agent GA:

  • Mécanismes de création

  • Compatibilité avec l'ancien agent Monitoring et l'ancien agent Logging

    • Les règles d'agent bêta peuvent gérer l'ancien agent Monitoring et l'ancien agent Logging, ainsi que l'agent Ops.
    • Les règles d'agent DG ne gèrent que l'agent Ops.

  • Mise à niveau automatique de la version de l'agent

    • Les stratégies d'agent bêta permettent de maintenir l'agent à la dernière version mettre à niveau l'agent.
    • Les règles d'agent GA ne sont pas compatibles avec les opérations de mise à niveau automatique. Pour découvrir d'autres approches, consultez la section Remplacer les règles de mise à niveau de l'agent bêta.

  • Application de la stratégie aux instances Compute Engine nommées

    • Les règles de l'agent bêta peuvent être appliquées à une liste d'instances nommées.
    • Les règles de l'agent DG ne sont pas compatibles avec les instances nommées. Pour obtenir le même comportement avec les règles DG, consultez la section Convertir une règle d'instance nommée bêta en règle DG.

  • Application globale ou zonale des règles de l'agent dans un projet Google Cloud

    • Les règles de l'agent bêta sont appliquées globalement à toutes les instances sélectionnées par les critères de stratégie dans votre projet Google Cloud.
    • Les règles de l'agent DG sont appliquées à toutes les instances sélectionnées par les critères de stratégie dans la zone spécifiée par la règle. Par exemple, une règle créée dans la zone us-central1-a n'a aucun effet sur les VM d'autres zones.

Les règles bêta et celles de GA sont également structurellement différentes:

  • Règles créées à l'aide de gcloud beta compute instances ops-agents policies décrire les stratégies d'agent en transmettant des options individuelles aux commandes, Exemple:

    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

    Le module Terraform agent-policy offre les mêmes fonctionnalités.

  • Les règles créées à l'aide de gcloud compute instances ops-agents policies décrire la stratégie d'agent à l'aide d'une configuration YAML et une zone, par exemple:

    gcloud compute instances ops-agents policies create test-policy \
  --zone us-central1-a \
  --file test-policy.yaml \
  --project PROJECT_ID

    Le module Terraform ops-agent-policy offre les mêmes fonctionnalités.

Utilisation des règles bêta et DG

Vous pouvez utiliser des règles d'agent bêta et d'agent DG avec l'agent Ops, à condition de prendre en compte les différences entre les types de règles.

La principale différence comportementale entre les règles d'agent bêta et d'agent DG est que les règles d'agent DG sont zonales, tandis que règles d'agent bêta sont globales au sein d'un projet. Autrement dit, les règles d'agent DG ne sélectionnent que les VM de la zone dans laquelle la règle est créée, tandis que les règles bêta peuvent sélectionner n'importe quelle VM de votre projet Google Cloud.

Si les règles bêta sélectionnent un ensemble de VM et que les règles DG sélectionnent un autre ensemble de VM, les règles ne peuvent pas entrer en conflit.

Vous pouvez avoir des règles d'agent bêta et d'agent DG qui s'appliquent à la même VM, mais vous devez vous assurer qu'elles n'ont pas d'objectifs contradictoires (par exemple, une règle bêta qui installe l'agent Ops et une règle DG qui le désinstalle).

Convertir les règles bêta en règles DG

Vous pouvez convertir vos règles d'agent bêta en règles d'agent DG, à condition qu'il n'existe aucune différence entre les types de règles que vous ne pouvez pas contourner. Vous ne pouvez pas convertir les règles d'agent bêta de l'ancien agent Monitoring ou Logging en règles d'agent DG.

Pour convertir des règles d'agent bêta en règles GA à l'aide du SDK Google Cloud, procédez comme suit :

  1. Générez la liste de toutes les règles de l'agent bêta de votre projet en exécutant la commande suivante :

    gcloud beta compute instances ops-agents policies list --project PROJECT_ID

  2. Identifiez les règles d'agent bêta que vous souhaitez convertir en règles DG.

  3. Pour chaque règle bêta que vous souhaitez convertir, procédez comme suit:

    1. Créez un fichier de configuration YAML aussi proche que possible de la stratégie bêta, compte tenu des différences entre les règles bêta et GA. Pour en savoir plus sur le format de configuration YAML, consultez la section Décrire les règles d'agent.

    2. Créez une règle d'agent DG dans chaque zone où vous avez besoin de cette règle. Pour en savoir plus sur la création de règles d'agent DG, consultez la section Créer une règle d'agent.

    3. Supprimez la stratégie d'agent bêta en exécutant la commande suivante:

      gcloud beta compute instances ops-agents policies delete POLICY_ID --project PROJECT_ID

Il est possible que vous ne puissiez pas écrire une règle d'agent DG pour l'agent Ops qui soit exactement identique à une règle d'agent bêta existante. Toutefois, à l'exception de l'option de mise à niveau automatique de la stratégie d'agent bêta, vous pouvez obtenir comportemental.

Les sections suivantes décrivent comment gérer les cas suivants :

Convertir une règle d'instance nommée bêta en règle DG

Pour convertir une règle d'agent bêta appliquée à un ensemble nommé d'instances de VM, vous pouvez procéder comme suit:

  1. Appliquez une étiquette aux instances de l'ensemble de VM que vous souhaitez sélectionner. Pour appliquer une étiquette à une VM existante, utilisez la commande gcloud compute instances add-labels : comme indiqué dans la commande suivante:

    gcloud compute instances add-labels INSTANCE_NAME --labels=KEY=VALUE

  2. Décrivez une règle d'agent DG qui sélectionne les VM dotées du nouveau libellé à l'aide de la structure instanceFilter de la configuration. L'exemple suivant crée un fichier appelé config.yaml qui contient une règle correspondant au libellé appliqué à l'étape précédente :

    cat > config.yaml << EOF
agentsRule:
  packageState: installed
  version: 2.47.0
instanceFilter:
  inclusionLabels:
  - labels:
    KEY: VALUE
EOF

    Pour en savoir plus sur la description des règles d'agent DG, consultez la section Fichiers de configuration pour les règles d'agent.

  3. Créez une règle d'agent DG dans chaque zone comportant des VM avec le nouveau libellé :

    gcloud compute instances ops-agents policies create POLICY_ID \
  --zone ZONE \
  --file config.yaml
  --project PROJECT_ID

    Pour en savoir plus sur la création de règles d'agent DG, consultez la section Créer une règle d'agent.

Remplacer les règles de mise à niveau des agents en version bêta

Pour remplacer les règles d'agent bêta qui mettent à niveau l'agent, vous avez les options suivantes :

  • Pour vous assurer que l'agent Ops est toujours à jour, utilisez Correctif d'OS pour créer et exécuter Job de correctif de système d'exploitation qui maintient l'agent au dernier version.

  • Pour effectuer une mise à niveau ponctuelle, procédez comme suit :

    1. Déterminez la dernière version de l'agent Ops en consultant les notes de version de l'agent Ops sur GitHub.

    2. Créez ou modifiez une règle d'agent qui installe la dernière version de l'agent. Par exemple, si la dernière version est 2.51.0, vous pouvez alors utiliser un fichier YAML agent-policy qui se présente comme suit:

      agentsRule:
  packageState: installed
  version: 2.51.0
instanceFilter:
[...]

    3. Appliquez la règle aux VM de chaque zone.

Systèmes d'exploitation compatibles

Vous pouvez appliquer une règle d'agent aux instances de VM Compute Engine exécutant les systèmes d'exploitation indiqués dans le tableau suivant :

Système d'exploitation Agent Ops
(règles DG et bêta†) 		Agent Logging
(règles bêta† uniquement) 		Agent Monitoring
(règles en version bêta† uniquement)
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 basées sur 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
†  Dans les règles d'agent bêta, les colonnes de l'agent correspondent à un type d'agent spécifié dans l'appel gcloud beta compute instances ops-agents policies create :
  • L'Agent Ops correspond au type d'agent ops-agent.
  • L'agent Logging correspond au type d'agent logging.
  • L'agent Monitoring correspond au type d'agent metrics.
‡ L'agent Monitoring n'est pas compatible avec rhel-7-9-sap-ha, rhel-8-2-sap-ha ou rhel-8-4-sap-ha.

Étape suivante

Pour en savoir plus sur l'utilisation de règles d'agent pour gérer l'agent Ops, consultez les ressources suivantes :