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

Les règles d'agent permettent d'automatiser l'installation et la maintenance de l'agent Ops sur un parc de VM Compute Engine répondant aux critères spécifiés par l'utilisateur. À l'aide d'une seule commande, vous pouvez créer une stratégie 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.

Règles d'agent pour l'agent Ops

La compatibilité des règles d'agent pour l'agent Ops est disponible dans Google Cloud SDK à deux niveaux de version: en disponibilité générale et bêta. Les deux types de règles 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 lorsque cela est 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

Les règles d'agent créées par les groupes de commandes compute instances ops-agents policies en version bêta et en disponibilité générale présentent les différences suivantes:

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

    • Les règles d'agent bêta permettent de gérer l'ancien agent Monitoring et l'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

  • Application d'une stratégie aux instances Compute Engine nommées

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

    • Les règles d'agent bêta sont appliquées globalement à toutes les instances sélectionnées par les critères de règle 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 des autres zones.

Les groupes de commandes compute instances ops-agents policies bêta et en disponibilité générale sont également structurellement différents:

  • Les commandes gcloud beta compute instances ops-agents policies décrivent les stratégies d'agent en transmettant des options individuelles aux commandes, par 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

  • Les commandes gcloud compute instances ops-agents policies décrivent la règle d'agent à l'aide d'un fichier de configuration YAML et d'une zone, par exemple:

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

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 DG, procédez comme suit :

  1. Générez une liste de toutes les règles d'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 stratégies bêta et les stratégies GA. Pour en savoir plus sur le format de configuration YAML, consultez la page Décrire les stratégies 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 un comportement équivalent.

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

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

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 un libellé à 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 disposez des options suivantes:

  • Pour vous assurer que l'agent Ops est toujours à jour, utilisez OS Patch pour créer et exécuter une tâche OS Patch qui permet à l'agent de disposer de la dernière version.

  • Pour effectuer une mise à niveau unique, 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.46.0, vous pouvez utiliser un fichier YAML de règle d'agent qui se présente comme suit:

      agentsRule:
  packageState: installed
  version: 2.46.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 qui exécutent les systèmes d'exploitation présentés dans le tableau suivant:

Système d'exploitation Agent Ops
(règles DG et bêta†) 		Agent Logging
(règles en version 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.

Étapes suivantes

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