Utilisation des pipelines de configuration config-pipelines

Découvrez comment utiliser les pipelines de configuration pour déployer différentes configurations dans AEM as a Cloud Service, telles que les paramètres de transfert de journal, les tâches de maintenance liées à la purge et diverses configurations de réseau CDN.

Vue d’ensemble overview

Un pipeline de configuration Cloud Manager déploie des fichiers de configuration (créés au format YAML) dans un environnement cible. Plusieurs fonctionnalités d’AEM as a Cloud Service peuvent être configurées de cette manière, notamment le transfert de journal, les tâches de maintenance liées à la purge et plusieurs fonctionnalités de réseau CDN.

Les pipelines de configuration peuvent être déployés via Cloud Manager vers les types d’environnements de développement, d’évaluation et de production. Les fichiers de configuration peuvent être déployés dans des environnements de développement rapide (RDE) à l’aide de outil de ligne de commande.

Les sections suivantes de ce document donnent un aperçu des informations importantes concernant la manière dont les pipelines de configuration peuvent être utilisés et la manière dont les configurations pour ces pipelines doivent être structurées. Il décrit les concepts généraux partagés entre toutes les fonctionnalités ou un sous-ensemble des fonctionnalités prises en charge par les pipelines de configuration.

Configurations prises en charge configurations

Le tableau suivant propose une liste complète de ces configurations avec des liens vers la documentation dédiée décrivant sa syntaxe de configuration distincte et d’autres informations.

Création et gestion des pipelines de configuration creating-and-managing

Pour plus d’informations sur la création et la configuration des pipelines, voir Pipelines CI/CD.

Lors de la création d’un pipeline de configuration dans Cloud Manager, veillez à sélectionner un Déploiement ciblé plutôt qu’un Code de pile complète lors de la configuration du pipeline.

Comme indiqué précédemment, la configuration des RDE est déployée à l’aide de outils de ligne de commande plutôt que d’un pipeline.

Syntaxe courante common-syntax

Chaque fichier de configuration commence par des propriétés ressemblant à l’exemple de fragment de code suivant :

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

Vous pouvez utiliser l’utilitaire yq pour valider localement la mise en forme YAML de votre fichier de configuration (par exemple, yq cdn.yaml).

Structure de dossiers folder-structure

Un dossier nommé /config ou similaire doit se trouver en haut de l’arborescence, avec un ou plusieurs fichiers YAML quelque part dans une arborescence sous celui-ci.

Par exemple :

/config
  cdn.yaml

ou

/config
  /dev
    cdn.yaml

Les noms de dossier et de fichier sous /config sont arbitraires. Le fichier YAML doit toutefois inclure une valeur de propriété kind valide.

En règle générale, les configurations sont déployées dans tous les environnements. Si toutes les valeurs de propriété sont identiques pour chaque environnement, un seul fichier YAML suffira. Cependant, il est courant que les valeurs de propriété diffèrent d’un environnement à l’autre, par exemple lors du test d’un environnement inférieur.

Les sections suivantes illustrent quelques stratégies pour structurer vos fichiers.

Un seul fichier de configuration pour tous les environnements single-file

La structure du fichier ressemblera à ce qui suit :

/config
  cdn.yaml
  logForwarding.yaml

Utilisez cette structure lorsque la même configuration est suffisante pour tous les environnements et pour tous les types de configuration (réseau CDN, transfert de journal, etc.). Dans ce scénario, la propriété de tableau envTypes inclut tous les types d’environnement.

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

En utilisant des variables d’environnement de type secret, il est possible que les propriétés secrètes varient selon l’environnement, comme illustré par la référence ${{SPLUNK_TOKEN}}

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

Un Fichier Distinct Par Type D’Environnement file-per-env

La structure du fichier ressemblera à ce qui suit :

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

Utilisez cette structure en cas de différences dans les valeurs de propriété. Dans les fichiers , on s’attend à ce que la valeur du tableau envTypes corresponde au suffixe , par exemple
cdn-dev.yaml et logForwarding-dev.yaml avec une valeur de ["dev"], cdn-stage.yaml et logForwarding-stage.yaml avec une valeur de ["stage"], etc.

Un Dossier Par Environnement folder-per-env

Dans cette stratégie, il existe un dossier config distinct par environnement, avec un pipeline distinct déclaré dans Cloud Manager pour chacun.

Cette approche est particulièrement utile si vous disposez de plusieurs environnements de développement, où chacun possède des valeurs de propriété uniques.

La structure du fichier ressemblera à ce qui suit :

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

Une variante de cette approche consiste à conserver une branche distincte par environnement.

Variables d’environnement secrètes secret-env-vars

Pour que le stockage des informations sensibles dans le contrôle de code source ne soit pas nécessaire, les fichiers de configuration prennent en charge les variables d’environnement Cloud Manager de type secret. Pour certaines configurations, y compris le transfert de journal, les variables d’environnement secrètes sont obligatoires pour certaines propriétés.

Le fragment de code ci-dessous est un exemple de la manière dont la variable d’environnement secrète ${{SPLUNK_TOKEN}} est utilisée dans la configuration.

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

Consultez le document Variables d’environnement Cloud Manager pour plus d’informations sur l’utilisation des variables d’environnement.