Utilizzo delle pipeline di configurazione config-pipelines

Scopri come utilizzare le pipeline di configurazione per distribuire diverse configurazioni di AEM as a Cloud Service, ad esempio le impostazioni di inoltro del registro, le attività di manutenzione relative all’eliminazione e varie configurazioni CDN.

Panoramica overview

Una pipeline di configurazione di Cloud Manager distribuisce i file di configurazione (creati in formato YAML) in un ambiente di destinazione. È possibile configurare in questo modo diverse funzioni in AEM as a Cloud Service, tra cui l’inoltro del registro, le attività di manutenzione relative all’eliminazione e diverse funzioni CDN.

Le pipeline di configurazione possono essere distribuite tramite Cloud Manager ai tipi di ambiente di sviluppo, stage e produzione nei programmi di produzione (non sandbox). RDE non supportati.

Le sezioni seguenti di questo documento forniscono una panoramica di informazioni importanti su come è possibile utilizzare le pipeline di configurazione e su come devono essere strutturate le relative configurazioni. Descrive i concetti generali condivisi tra tutte le funzionalità o un sottoinsieme di quelle supportate dalle pipeline di configurazione.

Configurazioni supportate configurations

La tabella seguente offre un elenco completo di tali configurazioni, con collegamenti alla documentazione dedicata che descrive la sintassi di configurazione specifica e altre informazioni.

Creazione e gestione delle pipeline di configurazione creating-and-managing

Per informazioni su come creare e configurare le pipeline, consulta il documento Pipeline CI/CD.

Durante la creazione di una pipeline di configurazione in Cloud Manager, assicurati di selezionare una distribuzione mirata anziché codice full stack durante la configurazione della pipeline.

Sintassi comune common-syntax

Ogni file di configurazione inizia con proprietà simili al seguente snippet di esempio:

  kind: "LogForwarding"
  version: "1"
  metadata:
    envTypes: ["dev"]

È possibile utilizzare l'utilità yq per convalidare localmente la formattazione YAML del file di configurazione (ad esempio, yq cdn.yaml).

Struttura delle cartelle folder-structure

Una cartella denominata /config o simile deve trovarsi nella parte superiore della struttura, con uno o più file YAML in una struttura al di sotto di essa.

Ad esempio:

/config
  cdn.yaml

oppure

/config
  /dev
    cdn.yaml

I nomi delle cartelle e dei file sotto /config sono arbitrari. Il file YAML, tuttavia, deve includere un valore di proprietà kind valido.

In genere, le configurazioni vengono distribuite in tutti gli ambienti. Se tutti i valori delle proprietà sono identici per ogni ambiente, è sufficiente un singolo file YAML. Tuttavia, è comune che i valori delle proprietà differiscano tra gli ambienti, ad esempio durante il test di un ambiente inferiore.

Le sezioni seguenti illustrano alcune strategie per strutturare i file.

Un singolo file di configurazione per tutti gli ambienti single-file

La struttura del file sarà simile alla seguente:

/config
  cdn.yaml
  logForwarding.yaml

Utilizza questa struttura quando la stessa configurazione è sufficiente per tutti gli ambienti e per tutti i tipi di configurazione (CDN, inoltro registro, ecc.). In questo scenario, la proprietà dell'array envTypes includerebbe tutti i tipi di ambiente.

   kind: "cdn"
   version: "1"
   metadata:
     envTypes: ["dev", "stage", "prod"]

Utilizzando variabili di ambiente di tipo segreto, è possibile che proprietà segrete varino in base all'ambiente, come illustrato dal riferimento a ${{SPLUNK_TOKEN}}

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "AEMaaCS"

Un File Separato Per Tipo Di Ambiente file-per-env

La struttura del file sarà simile alla seguente:

/config
  cdn-dev.yaml
  cdn-stage.yaml
  cdn-prod.yaml
  logForwarding-dev.yaml
  logForwarding-stage.yaml
  logForwarding-prod.yaml

Utilizza questa struttura quando possono esserci differenze nei valori delle proprietà. Nei file, ci si aspetta che il valore dell'array envTypes corrisponda al suffisso, ad esempio
cdn-dev.yaml e logForwarding-dev.yaml con valore di ["dev"], cdn-stage.yaml e logForwarding-stage.yaml con valore di ["stage"] e così via.

Una cartella per ambiente folder-per-env

In questa strategia, esiste una cartella config separata per ogni ambiente, con una pipeline separata dichiarata in Cloud Manager per ogni ambiente.

Questo approccio è particolarmente utile se disponi di più ambienti di sviluppo, ciascuno dei quali ha valori di proprietà univoci.

La struttura del file sarà simile alla seguente:

/config/dev1
  cdn.yaml
  logForwarding.yaml
/config/dev2
  cdn.yaml
  logForwarding.yaml
/config/prod
  cdn.yaml
  logForwarding.yaml

Una variazione di questo approccio consiste nel mantenere un ramo separato per ogni ambiente.

Variabili di ambiente segrete secret-env-vars

Per evitare che le informazioni riservate vengano archiviate nel controllo del codice sorgente, i file di configurazione supportano variabili di ambiente Cloud Manager di tipo secret. Per alcune configurazioni, incluso l’inoltro del registro, le variabili di ambiente segrete sono obbligatorie per alcune proprietà.

Lo snippet seguente è un esempio di come la variabile di ambiente segreta ${{SPLUNK_TOKEN}} viene utilizzata nella configurazione.

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "AEMaaCS"

Per informazioni dettagliate sull'utilizzo delle variabili di ambiente, vedere il documento Variabili di ambiente Cloud Manager.