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-sandlådeprogram). RDE:er stöds inte.
I följande avsnitt i det här dokumentet finns en översikt över viktig information om hur du kan använda Config-pipelines 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 - En lista över konfigurationer som kan distribueras med konfigurationspipelines
- Skapar och hanterar konfigurationsförgreningar - Så här skapar du en konfigurationsförlopp.
- Vanlig syntax - Syntax delad mellan konfigurationer
- Mappstruktur - Beskriver de strukturkonfigurationströrningar som förväntas för konfigurationerna
- Hemliga miljövariabler - Exempel på hur du använder miljövariabler för att inte avslöja hemligheter i dina konfigurationer
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.
kind-värdeCDNCDNCDNCDNCDNMaintenanceTasksMaintenanceTasksLogForwardingSkapa 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.
Vanlig syntax common-syntax
Varje konfigurationsfil börjar med egenskaper som liknar följande exempelkodfragment:
kind: "LogForwarding"
version: "1"
metadata:
envTypes: ["dev"]
kindversionenvTypesmetadata. Möjliga värden är dev, stage, prod eller valfri kombination och avgör för vilka miljötyper konfigurationen ska bearbetas. Om matrisen till exempel bara innehåller dev läses konfigurationen inte in i scen- eller produktmiljöer, även om konfigurationen distribueras där.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 tillräcklig 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 exempelcdn-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.