Configurations prises en charge
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.
| Type | Valeur kind YAML | Description |
|---|---|---|
| Règles de filtrage du trafic, y compris WAF | CDN | Déclarer les règles pour bloquer le trafic malveillant |
| Transformations de requête | CDN | Déclaration des règles pour transformer la forme de la demande de trafic |
| Transformations de réponse | CDN | Déclaration de règles pour transformer la forme de la réponse pour une requête donnée |
| Redirections côté client | CDN | Déclarez les redirections côté client de style 301/302 |
| Sélecteurs d’origine | CDN | Déclarez des règles pour acheminer le trafic vers différents serveurs principaux, y compris les applications non Adobes |
| Pages d’erreur du réseau CDN | CDN | Remplacer la page d’erreur par défaut si l’origine AEM ne peut pas être atteinte, en référençant l’emplacement du contenu statique auto-hébergé dans le fichier de configuration |
| Purge CDN | CDN | Déclarez les clés API de purge utilisées pour purger le réseau CDN. |
| Jeton HTTP CDN géré par le client | CDN | Déclarez la valeur de X-AEM-Edge-Key nécessaire pour appeler le réseau CDN Adobe à partir d’un réseau CDN client |
| Authentification de base | CDN | Déclarez les noms d’utilisateur et mots de passe d’une boîte de dialogue d’authentification de base protégeant certaines URL. |
| Tâche de maintenance de purge de version | MaintenanceTasks | Optimisez le référentiel AEM en déclarant les règles déterminant quand les versions de contenu doivent être purgées. |
| Tâche de maintenance de purge du journal d’audit | MaintenanceTasks | Optimisez le journal d’audit AEM pour améliorer les performances en déclarant des règles concernant le moment où les journaux doivent être purgés. |
| Transfert de journal | LogForwarding | Configurez les points d’entrée et les informations d’identification pour le transfert des journaux vers diverses destinations, y compris Azure Blob Storage, Datadog, HTTPS, Elasticsearch, Splunk) |
Création et gestion des pipelines de configuration
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
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"]
| Propriété | Description | Valeur par défaut |
|---|---|---|
kind | Chaîne qui détermine le type de configuration, tel que le transfert de journal, les règles de filtrage du trafic ou les transformations de requête | Obligatoire, pas de valeur par défaut |
version | Chaîne représentant la version du schéma | Obligatoire, pas de valeur par défaut |
envTypes | Ce tableau de chaînes est une propriété enfant du nœud metadata. Les valeurs possibles sont dev, stage, prod ou toute combinaison de ces éléments. Elle détermine pour quels types d’environnement la configuration sera traitée. Par exemple, si le tableau contient uniquement des dev, la configuration n’est pas chargée dans les environnements d’évaluation ou de production, même si elle y est déployée. | Tous les types d’environnements (développement, évaluation, production) |
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
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
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"