Les règles d'agent permettent l'installation et la maintenance automatisées de l'Agent Ops sur un parc de VM Compute Engine correspondant 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.
Stratégies d'agent pour l'agent Ops
La prise en charge des règles d'agent pour l'agent Ops est disponible dans le SDK Google Cloud à deux niveaux de version : GA 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
bêta et GA diffèrent comme suit :
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'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'autres approches, consultez Remplacer les règles de mise à niveau des agents en version bêta
Application d'une 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.
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 de l'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_IDLes commandes
gcloud compute instances ops-agents policies
décrivent 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
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 :
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_IDIdentifiez les règles d'agent bêta que vous souhaitez convertir en règles DG.
Pour chaque règle bêta que vous souhaitez convertir, procédez comme suit:
Créer un fichier de configuration YAML aussi proche que possible de la stratégie bêta que possible, compte tenu les différences entre les règles de la version bêta et celles de GA. Pour en savoir plus sur le format de configuration YAML, consultez Décrivez les stratégies d'agent.
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.
Supprimez la règle de l'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 règle d'agent bêta, vous pouvez obtenir un comportement équivalent.
Les sections suivantes décrivent comment gérer les cas suivants:
- Règles de l'agent bêta qui sélectionnent des instances nommées
- Règles de mise à niveau de l'agent bêta
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:
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
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.
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_IDPour 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 de l'agent 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 OS Patch pour créer et exécuter une tâche de correctifs de l'OS qui maintient l'agent à la dernière version.
Pour effectuer une mise à niveau unique, procédez comme suit:
- Déterminez la dernière version de l'agent Ops en consultant les notes de version de l'agent Ops sur GitHub.
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: [...]
Appliquez la règle aux VM de chaque zone.
Systèmes d'exploitation compatibles
Vous pouvez appliquer une règle d'agent à Compute Engine Instances de VM exécutant 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 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 |
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
.
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 des règles d'agent pour gérer l'agent Ops, consultez les ressources suivantes :