Använda konfigurationsförlopp config-pipelines

Lär dig hur du kan använda konfigurationspipelines för att distribuera olika konfigurationer av AEM as a Cloud Service, t.ex. inställningar för vidarebefordran av loggar, rensningsrelaterade underhållsåtgärder och olika CDN-konfigurationer.

Ökning overview

En Cloud Manager-konfigurationspipeline distribuerar konfigurationsfiler (skapade i YAML-format) till en målmiljö. Ett antal funktioner i AEM as a Cloud Service kan konfigureras på det här sättet, inklusive loggvidarebefordran, rensningsrelaterade underhållsåtgärder och flera CDN-funktioner.

Konfigurationspipelines kan distribueras via Cloud Manager till olika typer av dev-, stage- och produktionsmiljöer i produktionsprogram (icke-sandbox). Konfigurationsfilerna kan distribueras till Rapid Development Environment (RDE) med kommandoradsverktyg.

I följande avsnitt i det här dokumentet ges en översikt över viktig information om hur du kan använda konfigureringspipelines och hur konfigurationer för dem ska struktureras. Här beskrivs allmänna koncept som delas av alla eller en delmängd av de funktioner som stöds av konfigurationspipelines.

Konfigurationer som stöds configurations

I följande tabell finns en omfattande lista över sådana konfigurationer med länkar till dedikerad dokumentation som beskriver dess distinkta konfigurationssyntax och annan information.

Skapa och hantera konfigurationsförlopp creating-and-managing

Mer information om hur du skapar och konfigurerar rörledningar finns i dokumentet CI/CD Pipelines.

När du skapar en konfigurationspipeline i Cloud Manager måste du välja en riktad distribution i stället för fullständig stackkod när du konfigurerar pipeline.

Som tidigare nämnts distribueras konfigurationen för RDE med kommandoradsverktyg i stället för en pipeline.

Vanlig syntax common-syntax

Varje konfigurationsfil börjar med egenskaper som liknar följande exempelkodfragment:

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

Du kan använda verktyget yq för att lokalt validera YAML-formateringen av konfigurationsfilen (till exempel yq cdn.yaml).

Mappstruktur folder-structure

En mapp med namnet /config eller liknande bör finnas högst upp i trädet, med en eller flera YAML-filer någonstans i ett träd nedanför.

Till exempel:

/config
  cdn.yaml

eller

/config
  /dev
    cdn.yaml

Mappnamnen och filnamnen under /config är godtyckliga. YAML-filen måste dock innehålla ett giltigt kind-egenskapsvärde.

Konfigurationer distribueras vanligtvis till alla miljöer. Om alla egenskapsvärden är identiska för varje miljö räcker det med en YAML-fil. Det är dock vanligt att egenskapsvärden skiljer sig åt mellan olika miljöer, till exempel när en lägre miljö testas.

I följande avsnitt visas några strategier för hur du strukturerar filer.

En enda konfigurationsfil för alla miljöer single-file

Filstrukturen ser ut ungefär så här:

/config
  cdn.yaml
  logForwarding.yaml

Använd den här strukturen när samma konfiguration räcker för alla miljöer och för alla typer av konfigurationer (CDN, loggvidarebefordran osv.). I det här scenariot skulle matrisegenskapen envTypes innehålla alla miljötyper.

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

Om du använder miljövariabler av hemlig typ kan hemliga egenskaper variera per miljö, vilket visas i referensen ${{SPLUNK_TOKEN}}

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

En separat fil per miljötyp file-per-env

Filstrukturen ser ut ungefär så här:

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

Använd den här strukturen när det kan finnas skillnader i egenskapsvärden. I filerna förväntar man sig att arrayvärdet envTypes motsvarar suffixet, till exempel
cdn-dev.yaml och logForwarding-dev.yaml med värdet ["dev"], cdn-stage.yaml och logForwarding-stage.yaml med värdet ["stage"] och så vidare.

En mapp per miljö folder-per-env

I den här strategin finns det en separat config-mapp per miljö med en separat pipeline deklarerad i Cloud Manager för varje.

Detta är särskilt användbart om du har flera utvecklingsmiljöer där varje miljö har unika egenskapsvärden.

Filstrukturen ser ut ungefär så här:

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

En variant av detta tillvägagångssätt är att ha en separat gren per miljö.

Hemliga miljövariabler secret-env-vars

Så att känslig information inte behöver lagras i källkontrollen stöder konfigurationsfiler Cloud Manager-miljövariabler av typen secrets. För vissa konfigurationer, inklusive vidarebefordran av loggar, är hemliga miljövariabler obligatoriska för vissa egenskaper.

Utdraget nedan är ett exempel på hur den hemliga miljövariabeln ${{SPLUNK_TOKEN}} används i konfigurationen.

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

Mer information om hur du använder miljövariabler finns i dokumentet Cloud Manager-miljövariabler.