Panoramica dei criteri degli agenti per Ops Agent

I criteri degli agenti consentono l'installazione e la manutenzione automatiche di Ops Agent su un parco risorse di VM di Compute Engine che soddisfano i criteri specificati dall'utente. Con un solo comando puoi creare un criterio per un progetto Google Cloud che regola le VM esistenti e nuove associate al progetto Google Cloud, assicurando la corretta installazione e disinstallazione di Ops Agent su queste VM.

Criteri degli agenti per Ops Agent

Il supporto per i criteri degli agenti per Ops Agent è disponibile in Google Cloud SDK in due livelli di release: GA e beta. Entrambi i tipi di criteri si basano sulle funzionalità di OS Config fornite da VM Manager, ma le implementazioni sono diverse. Ti consigliamo di utilizzare i criteri GA, se possibile. Nella maggior parte dei casi, puoi convertire i criteri beta in norme GA.

Questa sezione descrive le differenze tra i criteri degli agenti beta e GA Per informazioni sulla creazione e sulla gestione dei criteri degli agenti, consulta quanto segue:

Differenze tra i criteri degli agenti beta e GA

I criteri dell'agente creati dai gruppi di comandi beta e GA compute instances ops-agents policies differiscono per i seguenti aspetti:

  • Supporto per l'agente Monitoring legacy e l'agente Logging

    • I criteri degli agenti beta possono gestire l'agente Monitoring e l'agente Logging legacy, nonché Ops Agent.
    • I criteri dell'agente GA gestiscono solo l'Ops Agent.
  • Upgrade automatico della versione dell'agente

    • I criteri dell'agente beta possono mantenere l'agente all'ultima versione eseguendo l'upgrade dell'agente.
    • Le norme dell'agente GA non supportano un'operazione di upgrade automatico. Per gli approcci alternativi, consulta Sostituire i criteri di upgrade degli agenti beta.
  • Applicazione del criterio alle istanze di Compute Engine denominate

  • Applicazione globale o a livello di zona dei criteri degli agenti all'interno di un progetto Google Cloud

    • I criteri degli agenti beta vengono applicati a livello globale a tutte le istanze selezionate in base ai criteri dei criteri all'interno del tuo progetto Google Cloud.
    • I criteri dell'agente GA vengono applicati a tutte le istanze selezionate in base ai criteri del criterio all'interno della zona specificata dal criterio. Ad esempio, un criterio creato nella zona us-central1-a non ha alcun effetto sulle VM in altre zone.

Anche i gruppi di comandi compute instances ops-agents policies (beta e GA) sono strutturalmente diversi:

  • I comandi gcloud beta compute instances ops-agents policies descrivono i criteri degli agenti passando singole opzioni ai comandi, ad esempio:

    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
    
  • I comandi gcloud compute instances ops-agents policies descrivono il criterio dell'agente utilizzando un file di configurazione YAML e una zona, ad esempio:

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

Utilizzo delle norme di GA e beta

Puoi utilizzare i criteri degli agenti sia beta che GA con Ops Agent, a condizione che tu consideri le differenze tra i tipi di criteri.

La principale differenza comportamentale tra i criteri degli agenti beta e quelli GA è che i criteri degli agenti GA sono a livello di zona e quelli degli agenti beta sono globali all'interno di un progetto. In altre parole, i criteri dell'agente GA selezionano solo le VM nella zona in cui viene creato il criterio, mentre i criteri beta possono selezionare qualsiasi VM nel tuo progetto Google Cloud.

Se i criteri beta selezionano un insieme di VM e i criteri GA selezionano un insieme diverso di VM, i criteri non possono entrare in conflitto.

Puoi avere criteri degli agenti beta e GA che si applicano alla stessa VM, ma devi assicurarti che non abbiano scopi in conflitto, ad esempio un criterio beta che installa Ops Agent e un criterio GA che disinstalla Ops Agent.

Convertire i criteri beta in norme GA

Puoi convertire i criteri degli agenti Ops Agent in criteri degli agenti GA, purché non ci siano differenze tra i tipi di criteri su cui non puoi aggirare. Non puoi convertire i criteri dell'agente beta per l'agente Monitoring legacy o l'agente Logging in criteri dell'agente GA.

Per convertire i criteri degli agenti beta in criteri GA:

  1. Genera un elenco di tutti i criteri degli agenti beta nel tuo progetto eseguendo questo comando:

    gcloud beta compute instances ops-agents policies list --project PROJECT_ID
    
  2. Identifica i criteri dell'agente beta da convertire in criteri GA.

  3. Per ogni norma beta identificata per la conversione:

    1. Crea un file di configurazione YAML il più vicino possibile al criterio beta, date le differenze tra i criteri beta e quelli di GA. Per informazioni sul formato di configurazione YAML, consulta Descrivere i criteri dell'agente.

    2. Crea un criterio dell'agente GA in ogni zona in cui hai bisogno del criterio. Per informazioni sulla creazione dei criteri dell'agente GA, consulta Creare un criterio dell'agente.

    3. Elimina il criterio dell'agente beta eseguendo questo comando:

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

Potresti non essere in grado di scrivere un criterio dell'agente GA per Ops Agent che corrisponde esattamente a un criterio dell'agente beta esistente. Tuttavia, ad eccezione dell'opzione di upgrade automatico del criterio dell'agente beta, puoi ottenere un comportamento equivalente.

Le seguenti sezioni descrivono come gestire i seguenti casi:

Convertire un criterio per un'istanza denominata beta in un criterio GA

Per convertire un criterio dell'agente beta applicato a un insieme denominato di istanze VM, puoi:

  1. Applica un'etichetta alle istanze nel set di VM che vuoi selezionare. Per applicare un'etichetta a una VM esistente, utilizza il comando gcloud compute instances add-labels, come mostrato nel seguente comando:

    gcloud compute instances add-labels INSTANCE_NAME --labels=KEY=VALUE
    
  2. Descrivi un criterio dell'agente GA che seleziona le VM con la nuova etichetta utilizzando la struttura instanceFilter nella configurazione. Nell'esempio seguente viene creato un file denominato config.yaml contenente un criterio corrispondente all'etichetta applicata nel passaggio precedente:

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

    Per saperne di più sulla descrizione dei criteri degli agenti GA, consulta File di configurazione per i criteri degli agenti.

  3. Crea un criterio dell'agente GA in ogni zona che ha VM con la nuova etichetta:

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

    Per saperne di più sulla creazione dei criteri dell'agente GA, consulta Creare un criterio dell'agente.

Sostituisci i criteri di upgrade degli agenti beta

Per sostituire i criteri dell'agente beta che eseguono l'upgrade dell'agente, hai a disposizione le seguenti opzioni:

  • Per assicurarti che Ops Agent sia sempre aggiornato, utilizza OS Patch per creare ed eseguire un job di OS Patch che mantiene l'agente alla versione più recente.
  • Per eseguire un upgrade una tantum, segui questi passaggi:

    1. Per determinare l'ultima versione di Ops Agent consulta le note di rilascio su GitHub.
    2. Crea o modifica un criterio dell'agente che installa la versione più recente dell'agente. Ad esempio, se l'ultima versione è la 2.46.0, puoi utilizzare un YAML del criterio dell'agente simile al seguente:

      agentsRule:
        packageState: installed
        version: 2.46.0
      instanceFilter:
      [...]
      
    3. Applica il criterio alle VM in ciascuna zona.

Sistemi operativi supportati

Puoi applicare un criterio di agente alle istanze VM di Compute Engine che eseguono i sistemi operativi indicati nella tabella seguente:

Sistema operativo Ops Agent
(criteri GA e beta)
Agente Logging
(solo criteri beta)
Agente Monitoring
(solo criteri 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 Image basate su Debian 11 (Bullseye)
Ubuntu LTS 18.04 (Bionic Beaver):
ubuntu-1804-lts, ubuntu-minimal-1804-lts
Ubuntu LTS 20.04 (Fossa 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-*,
apreuse-leap-15-4-*)
Windows Server:
2016, 2019, 2022, Core 2016, Core 2019, Core 2022
  Nei criteri degli agenti beta, le colonne degli agenti vengono mappate a un tipo di agente specificato per la chiamata gcloud beta compute instances ops-agents policies create:
  • Ops Agent viene mappato al tipo di agente ops-agent.
  • L'agente Logging viene mappato al tipo di agente logging.
  • L'agente di monitoraggio viene mappato al tipo di agente metrics.
 L'agente Monitoring non è supportato su rhel-7-9-sap-ha, rhel-8-2-sap-ha o rhel-8-4-sap-ha.

Passaggi successivi

Per informazioni sull'utilizzo dei criteri degli agenti per gestire Ops Agent, consulta quanto segue: