Config Pipelines gebruiken config-pipelines

Leer hoe u config pijpleidingen kunt gebruiken om verschillende configuraties AEM as a Cloud Service zoals logboek op te stellen door:sturen montages, zuivert-verwante onderhoudstaken, en diverse configuraties CDN.

Overzicht overview

Een Cloud Manager config pijpleiding stelt configuratiedossiers (die in formaat YAML worden gecreeerd) aan een doelmilieu op. Een aantal eigenschappen in AEM as a Cloud Service kan op deze manier worden gevormd, met inbegrip van logboek het door:sturen, zuivert-verwante onderhoudstaken, en verscheidene eigenschappen CDN.

Config-pijplijnen kunnen via Cloud Manager worden geïmplementeerd voor het ontwikkelen, uitvoeren en produceren van omgevingstypen in productieprogramma's (niet-sandbox). De configuratiedossiers kunnen aan Snelle Milieu's van de Ontwikkeling (RDEs) worden opgesteld gebruikend het hulpmiddel van de bevellijn van de bevellijn.

Deze volgende secties van dit document geven een overzicht van belangrijke informatie betreffende hoe config de pijpleidingen kunnen worden gebruikt en hoe de configuraties voor hen zouden moeten worden gestructureerd. Het beschrijft algemene concepten die over of allen of een ondergroep van de eigenschappen worden gedeeld die door config pijpleidingen worden gesteund.

Ondersteunde configuraties configurations

De volgende lijst biedt een uitvoerige lijst van dergelijke configuraties met verbindingen aan specifieke documentatie die zijn verschillende configuratiesyntaxis en andere informatie beschrijft.

Config-pijplijnen maken en beheren creating-and-managing

Voor informatie over om pijpleidingen tot stand te brengen en te vormen, te zien gelieve het document CI/CD Pijpleidingen.

Wanneer het creëren van een config pijpleiding in Cloud Manager, ben zeker om a gerichte Plaatsing eerder dan Volledige Code van de Stapel te selecteren wanneer het vormen van de pijpleiding.

Zoals vroeger genoteerd, wordt de configuratie voor RDEs opgesteld gebruikend het hulpmiddel van de bevellijneerder dan een pijpleiding.

Algemene syntaxis common-syntax

Elk configuratiebestand begint met eigenschappen die op het volgende voorbeeldfragment lijken:

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

U kunt het hulpprogramma yq gebruiken om de YAML-opmaak van uw configuratiebestand lokaal te valideren (bijvoorbeeld yq cdn.yaml ).

Mapstructuur folder-structure

Een map met de naam /config of een vergelijkbare map moet zich boven aan de structuur bevinden, met nog een YAML-bestand ergens in een boomstructuur eronder.

Bijvoorbeeld:

/config
  cdn.yaml

of

/config
  /dev
    cdn.yaml

De mapnamen en bestandsnamen onder /config zijn willekeurig. Het YAML-bestand moet echter een geldige waarde voor de eigenschap kind bevatten.

Configuraties worden doorgaans in alle omgevingen geïmplementeerd. Als alle bezitswaarden voor elk milieu identiek zijn, zal één enkel dossier YAML voldoende zijn. Het is echter gebruikelijk dat eigenschapswaarden verschillen tussen omgevingen, bijvoorbeeld tijdens het testen van een lagere omgeving.

In de volgende secties ziet u enkele strategieën voor het structureren van uw bestanden.

Eén configuratiebestand voor alle omgevingen single-file

De bestandsstructuur lijkt op het volgende:

/config
  cdn.yaml
  logForwarding.yaml

Gebruik deze structuur wanneer de zelfde configuratie voor alle milieu's en voor alle types van configuratie (CDN, logboek het door:sturen, etc.) voldoende is. In dit scenario zou de array-eigenschap envTypes alle omgevingstypen bevatten.

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

Gebruikend geheim-type milieuvariabelen, is het mogelijk voor geheime eigenschappenper milieu te variëren, zoals die door de ${{SPLUNK_TOKEN}} verwijzing wordt geïllustreerd

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

Een afzonderlijk bestand per omgevingstype file-per-env

De bestandsstructuur lijkt op het volgende:

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

Gebruik deze structuur wanneer er verschillen in eigenschapswaarden kunnen zijn. In de bestanden wordt verwacht dat de arraywaarde envTypes overeenkomt met het achtervoegsel, bijvoorbeeld
cdn-dev.yaml en logForwarding-dev.yaml met de waarde ["dev"] , cdn-stage.yaml en logForwarding-stage.yaml met de waarde ["stage"] , enzovoort.

Een map per omgeving folder-per-env

In deze strategie, is er een afzonderlijke config omslag per milieu, met een afzonderlijke pijpleiding die in Cloud Manager voor elk wordt verklaard.

Deze benadering is vooral nuttig als u veelvoudige ontwikkelomgevingen hebt, waar elk unieke bezitswaarden heeft.

De bestandsstructuur lijkt op het volgende:

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

Een variatie van deze benadering is het handhaven van een afzonderlijke tak per milieu.

Geheime omgevingsvariabelen secret-env-vars

Zo dat de gevoelige informatie niet in broncontrole moet worden opgeslagen, steunen de configuratiedossiers de milieu variabelen van Cloud Manager van type geheim. Voor sommige configuraties, met inbegrip van logdoor:sturen, zijn de geheime omgevingsvariabelen verplicht voor bepaalde eigenschappen.

Het onderstaande fragment is een voorbeeld van hoe de geheime omgevingsvariabele ${{SPLUNK_TOKEN}} in de configuratie wordt gebruikt.

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

Gelieve te zien het document de Variabelen van het Milieu van Cloud Managervoor details op hoe te om omgevingsvariabelen te gebruiken.