Använda config pipelines config-pipelines

Lär dig hur du kan använda konfigurationspipelines för att distribuera olika konfigurationer i AEM as a Cloud Service, till exempel inställningar för vidarebefordran av loggfiler, 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.

För Publicera leveransprojekt -projekt kan konfigurationspipelines distribueras via Cloud Manager till olika typer av dev-, stage- och produktionsmiljöer. Konfigurationsfilerna kan distribueras till Rapid Development Environment (RDE) med kommandoradsverktyg.

Konfigurationspipelines kan också distribueras via Cloud Manager för Edge Delivery -projekt.

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 konfigureringspipelines creating-and-managing

Mer information om hur du skapar och konfigurerar konfigurationspipelines för publiceringsleverans finns i 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.

Mer information om hur du skapar och konfigurerar Edge Delivery-konfigurationspipelines finns i artikeln Lägg till en Edge Delivery-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 liknar följande:

/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"]

Med hjälp av miljövariabler av hemlig typ (eller pipeline-variabler) kan hemliga egenskaper variera per miljö, vilket visas i följande ${{SPLUNK_TOKEN}}-referens.

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 liknar följande:

/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 liknar följande:

/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ö.

Edge Delivery Services yamls-for-eds

Edge Delivery config-pipelines har inte separata miljöer för utveckling, staging och produktion. I Publicera leverans-miljöer ändrar du förloppet genom nivåerna dev, stage och prod. En Edge Delivery-konfigurationspipeline tillämpar däremot konfigurationen direkt på alla domänmappningar som är registrerade i Cloud Manager för en Edge Delivery-plats.

Distribuera en enkel filstruktur som:

/config
  cdn.yaml
  logForwarding.yaml

Om en regel måste skilja sig åt mellan olika Edge Delivery-webbplatser kan du använda syntaxen when för att skilja reglerna från varandra. Observera till exempel att domänen matchar dev.example.com i kodutdraget nedan, som kan särskiljas från domänen www.example.com.

kind: "CDN"
version: "1"
data:
  trafficFilters:
    rules:
    # Block simple path
    - name: block-path
      when:
        allOf:
          - reqProperty: domain
            equals: "dev.example.com"
          - reqProperty: path
            equals: '/block/me'
      action: block

Om du inkluderar metadatafältet envTypes bör bara värdet prod användas (det går också bra att utelämna metadatafältet envTypes). Endast värdet publish ska användas för tier reqProperty.

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.

Observera att hemliga miljövariabler används för publiceringsleveransprojekt. Se avsnittet Hemliga rörvariabler för Edge Delivery Services-projekt.

Följande kodutdrag ä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 Cloud Manager miljövariabler.

Hemliga pipeline-variabler secret-pipeline-vars

Använd Cloud Manager pipeline-variabler av typen secrets för Edge Delivery Services Projects så att känslig information inte behöver lagras i källkontrollen. Använd-valrutan bör använda alternativet distribuera.

Syntaxen är identisk med fragmentet som visades i föregående avsnitt.

Mer information om hur du använder pipeline-variabler finns i Förloppsvariabler i Cloud Manager.