Configuratiepijpleidingen gebruiken config-pipelines

Leer hoe u config pijpleidingen kunt gebruiken om verschillende configuraties in 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.

Voor publiceer de Projecten van de Levering, config de pijpleidingen kunnen via Cloud Manager worden opgesteld om, stadium, en de types van productiemilieu te ontwikkelen. De configuratiedossiers kunnen aan Snelle Milieu's van de Ontwikkeling (RDEs) worden opgesteld gebruikend ​ het hulpmiddel van de bevellijn van de bevellijn ​.

De pijpleidingen van config kunnen ook door Cloud Manager voor Edge Delivery Projecten worden opgesteld.

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.

Configuratieleidingen maken en beheren creating-and-managing

Voor informatie over om te creëren en te vormen publiceer levering config pijpleidingen, zie ​ 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 bevellijn ​ eerder dan een pijpleiding.

Voor informatie over om Edge Delivery config pijpleidingen tot stand te brengen en te vormen, zie ​ een artikel van de Pijpleiding van Edge Delivery ​ toevoegen.

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 kind eigenschapswaarde ​ bevatten.

Configuraties worden doorgaans in alle omgevingen geïmplementeerd. Als alle bezitswaarden voor elk milieu identiek zijn, volstaat één enkel dossier YAML. 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 ziet er als volgt uit:

/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 milieu (of pijpleiding) variabelen, is het mogelijk voor ​ geheime eigenschappen ​ om per milieu te variëren, zoals geïllustreerd door de volgende ${{SPLUNK_TOKEN}} verwijzing.

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 ziet er als volgt uit:

/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. cdn-dev.yaml en logForwarding-dev.yaml bijvoorbeeld 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 ziet er als volgt uit:

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

Edge Delivery Services yamls-for-eds

Edge Delivery config-pijpleidingen hebben geen afzonderlijke ontwikkelings-, staging- en productieomgevingen. In de omgeving van Publiceren van de Levering, verandert vooruitgang door dev, stadium, en prod rijen. Een Edge Delivery config-pijplijn past daarentegen de configuratie rechtstreeks toe op alle domeintoewijzingen die in Cloud Manager voor een Edge Delivery-site zijn geregistreerd.

Implementeer dus een eenvoudige bestandsstructuur, zoals:

/config
  cdn.yaml
  logForwarding.yaml

Als een regel per plaats van Edge Delivery moet verschillen, gebruik de syntaxis wanneer om de regels van elkaar te onderscheiden. U ziet bijvoorbeeld dat het domein overeenkomt met dev.example.com in het onderstaande fragment, dat kan worden onderscheiden van het domein 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

Als het omvatten van het envTypes meta-gegevensgebied, slechts zou de waarde prod moeten worden gebruikt (het weglaten van het envTypes meta-gegevensgebied is ook fijn). Voor de rij reqProperty, slechts publiceert de waarde ​ ​zou moeten worden gebruikt.

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.

Merk op dat de geheime omgevingsvariabelen voor de Publish Projecten van de Levering worden gebruikt; zie de Geheime sectie van de Variabelen van de Pijpleiding voor de projecten van Edge Delivery Services.

Het volgende 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"

Voor details op hoe te om milieuvariabelen te gebruiken, zie ​ de Variabelen van het Milieu van Cloud Manager ​.

Geheime pijpleidingsvariabelen secret-pipeline-vars

Voor de Projecten van Edge Delivery Services, de pijpleidingsvariabelen van gebruiksCloud Manager van type geheim zodat moet de gevoelige informatie niet in broncontrole worden opgeslagen. De Toegepaste Stap uitgezochte doos zou gebruiken stelt optie op.

De syntaxis is identiek aan het fragment dat in de vorige sectie wordt weergegeven.

Voor details op hoe te om pijpleidingsvariabelen te gebruiken, zie ​ Variabelen van de Pijpleiding in Cloud Manager ​.