Explication des fichiers de configuration | AEM

Explorez une ventilation détaillée des fichiers de configuration dans le serveur Dispatcher d’Adobe Managed Services. Découvrez leur signification, leurs conventions de dénomination et leurs applications pratiques.

Description description

Environnement

Experience Manager

Problème/Symptômes

Ce document présente la ventilation et l’explication de chacun des fichiers de configuration déployés dans un serveur Dispatcher standard intégré configuré dans Adobe Managed Services. Leur utilisation, convention de dénomination, etc.

Convention d’affectation de noms

Le serveur web Apache ne se soucie pas réellement de l’extension de fichier d’un fichier lorsqu’il est ciblé avec une instruction facultative include (Inclusion) ou include (Inclusion). Nommer correctement les noms avec des noms qui éliminent les conflits et la confusion aide une tonne. Les noms utilisés décrivent la portée de l’application du fichier, ce qui facilite la vie. Si tout s’appelle .conf, cela devient vraiment déroutant. Évitez les fichiers et les extensions mal nommés.

Vous trouverez ci-dessous une liste des différentes extensions de fichier personnalisées et des conventions d’affectation de nom utilisées dans un Dispatcher standard configuré par AMS.

Fichiers contenus dans conf.d/

Fichiers contenus dans conf.modules.d/

Problèmes évités

Lorsque vous respectez la convention de dénomination, évitez les erreurs assez faciles à commettre qui peuvent avoir des résultats catastrophiques. Couvrons quelques exemples.

Exemple de problème

Comme exemple de site pour ExempleCo, deux fichiers de configuration sont créés par les développeurs des configurations Dispatcher.

/etc/httpd/conf.d/exampleco.conf

<VirtualHost *:80>

    ServerName  "exampleco"

    ServerAlias "www.exampleco.com"

    .......... SNIP ...............

    <IfModule mod_rewrite.c>

        ReWriteEngine   on

        LogLevel warn rewrite:trace1

        Include /etc/httpd/conf.d/rewrites/exampleco.conf

    </IfModule>

</VirtualHost>

/etc/httpd/conf.d/rewrites/exampleco.conf

RewriteRule /$ /content/exampleco/en.html [ PT,L]

RewriteRule /robots.txt$ /content/dam/exampleco/robots.txt [ PT,L]

DANGER POTENTIEL

A. Les noms de fichier sont identiques.

Si le fichier vhost est accidentellement placé dans le dossier rewrites et que le fichier rewrites est placé dans le dossier vhosts. Il semble qu’il soit correctement déployé par nom de fichier, mais Apache renvoie une erreur et le problème n’est pas immédiatement visible.

Comment cela devient-il généralement un problème ?

Si les deux fichiers sont téléchargés au même emplacement, ils peuvent soit se remplacer, soit les rendre impossibles à distinguer, ce qui fait du processus de déploiement un cauchemar.

B. Les extensions de fichier sont identiques et incluent automatiquement

Les extensions de fichier sont les mêmes et utilisent l’extension auto-incluse qu’Apache inclut automatiquement tous les fichiers .conf dans la plupart de ses dossiers par défaut.

Comment cela devient-il généralement un problème ?

Si le fichier vhost avec l’extension .conf est placé dans le dossier /etc/httpd/conf.d/ , il tente de le charger en mémoire sur Apache, ce qui est généralement correct, mais si le fichier de règles de réécriture avec l’extension .conf est placé dans le dossier /etc/httpd/conf.d/, il sera automatiquement inclus et s’applique globalement, ce qui provoquera des résultats confus et indésirables.

Résolution resolution

Nommez les fichiers en fonction de ce qu’ils font et en toute sécurité en dehors de l’espace de noms des règles d’inclusion automatique.

L’utilisation de ces conventions d’affectation de noms permet d’éviter des problèmes si un fichier est déplacé dans un répertoire d’inclusion automatique auquel il n’appartient pas.

Par exemple, placer un fichier nommé avec .rules, .any ou .vhost dans le dossier d’auto-inclusion de /etc/httpd/conf.d/ n’aurait aucun effet.

Si une requête de modification de déploiement indique please deploy exampleco_rewrite.rules to production dispatchers, la personne qui déploie les modifications peut déjà savoir qu’elle n’ajoute pas de nouveau site ; elle met simplement à jour les règles de réécriture comme indiqué par le nom du fichier.

Inclure la commande

Lors de l’extension des fonctionnalités et des configurations dans le serveur web Apache installé sur Enterprise Linux, vous disposez d’un ajout de commandes important que vous souhaitez comprendre.

A. Inclusion de la ligne de base Apache

Le binaire Apache commence par httpd.conf qui effectue un includeoptional dans les répertoires conf.d/*.conf et conf.modules.d/*.conf.

Comme illustré dans le diagramme ci-dessus, le binaire httpd ne regarde que le fichier httpd.conf dans son fichier de configuration. Ce fichier contient les instructions suivantes :

Include conf.modules.d/*.conf
IncludeOptional conf.d/*.conf

B. Inclusions de niveau supérieur AMS

Lorsque nous avons appliqué notre norme, nous avons ajouté d’autres types de fichiers et inclus les nôtres.

Voici les répertoires de base AMS et les inclusions de niveau supérieur.

En partant de la ligne de base d’Apache, nous montrons comment AMS a créé des dossiers supplémentaires et des inclusions de niveau supérieur pour les dossiers conf.d ainsi que des répertoires spécifiques aux modules imbriqués sous /etc/httpd/conf.dispatcher.d/

Lorsque Apache charge, il extrait le fichier /etc/httpd/conf.modules.d/02-dispatcher.conf et ce fichier inclut le fichier binaire /etc/httpd/modules/mod_dispatcher.so dans son état d’exécution.

LoadModule dispatcher_module modules/mod_dispatcher.so

Pour utiliser le module dans notre </VirtualHost>, nous déposerons un fichier de configuration dans /etc/httpd/conf.d/ nommé dispatcher_vhost.conf. Dans ce fichier, vous verrez comment utiliser la configuration des paramètres de base nécessaires au fonctionnement du module :

<IfModule disp_apache2.c>
DispatcherConfig conf.dispatcher.d /dispatcher .any
...SNIP...
</IfModule>

Comme vous pouvez le voir ci-dessus, cela inclut le fichier dispatcher.any de niveau supérieur pour notre module Dispatcher afin de récupérer ses fichiers de configuration de /etc/httpd/conf.dispatcher.d/dispatcher.any.

Attention au contenu de ce fichier :

/farms {
 $include "enabled_farms/*_farm.any"
}

Le fichier dispatcher.any de niveau supérieur comprend tous les fichiers de fermes activés qui vivent dans /etc/httpd/conf.dispatcher.d/enabled_farms/ avec le nom de fichier <FILENAME>_farm.any qui respectent notre convention de dénomination standard.

Plus loin dans le fichier dispatcher_vhost.conf mentionné précédemment, nous faisons également une instruction d’inclusion pour activer chaque fichier d’hôte virtuel activé qui réside dans /etc/httpd/conf.d/enabled_vhosts/ avec le nom de fichier <FILENAME>.vhost qui suit notre convention d’affectation de nom standard.

IncludeOptional /etc/httpd/conf.d/enabled_vhosts/*.vhost

Dans chacun de nos fichiers .vhost, vous remarquerez que le module dispatcher est initialisé en tant que gestionnaire de fichiers par défaut pour un répertoire. Voici un exemple de fichier .vhost pour afficher la syntaxe :

<VirtualHost *:80>
 ServerName "weretail"
 ServerAlias www.weretail.com weretail.com
 <Directory />
 <IfModule disp_apache2.c>
 ....SNIP....
 SetHandler dispatcher-handler
 </IfModule>
 ....SNIP....
 </Directory>
 ....SNIP....
</VirtualHost>

Une fois que les inclusions de niveau supérieur sont résolues, elles comportent d’autres sous-inclusions qui méritent d’être mentionnées. Voici un diagramme de haut niveau sur la manière dont les fichiers de fermes de serveurs et vhosts incluent d’autres sous-éléments.

C. Inclusion de l’hôte virtuel AMS

Lorsque des fichiers .vhost du répertoire /etc/httpd/conf.d/availabled_vhosts/ sont liés de manière symbolique dans le répertoire /etc/httpd/conf.d/enabled_vhosts/, ils sont utilisés dans la configuration en cours d’exécution.

Les fichiers .vhost comportent des sous-inclusions basées sur les éléments communs que nous avons trouvés. Il s’agit de variables, de listes blanches et de règles de réécriture.

Le fichier .vhost comporte des instructions d’inclusion pour chaque fichier en fonction de l’endroit où il doit être inclus dans le fichier .vhost. Voici un exemple de syntaxe d’un fichier .vhost comme référence appropriée :

Include /etc/httpd/conf .d /variables/weretail .vars VirtualHost *:80
ServerName "${MAIN_DOMAIN}"
Directory / Include /etc/httpd/conf .d /whitelists/weretail *_whitelist.rules
IfModule disp_apache2.c
....SNIP....
SetHandler dispatcher-handler
/IfModule
....SNIP....
/Directory
....SNIP....
IfModule mod_rewrite.c
ReWriteEngine on
LogLevel warn rewrite:trace1
Include /etc/httpd/conf .d /rewrites/weretail_rewrite .rules
/IfModule /VirtualHost

Comme vous pouvez le voir dans l’exemple ci-dessus, il existe une inclusion pour les variables nécessaires dans ce fichier de configuration qui sont utilisées ultérieurement.

Dans le fichier /etc/httpd/conf.d/variables/weretail.vars, nous pouvons voir les variables qui sont définies :

Define MAIN_DOMAIN dev.weretail.com

Vous pouvez également voir une ligne qui contient une liste de fichiers whitelist.rules qui restreignent les utilisateurs autorisés à afficher ce contenu en fonction de différents critères de liste blanche. Examinons le contenu d’un des fichiers de liste blanche /etc/httpd/conf.d/whitelists/weretail_mainoffice_whitelist.rules :

<RequireAny>
 Require ip 192.150.16.0/23
</RequireAny>

Vous pouvez également voir une ligne qui comprend un ensemble de règles de réécriture. Examinons le contenu du fichier weretail_rewrite.rules :

RewriteRule /robots.txt$ /content/dam/weretail/robots.txt [ NC,PT]
RewriteCond %{SERVER_NAME} brand1.weretail.net [ NC]
RewriteRule /favicon.ico$ /content/dam/weretail/favicon.ico [ NC,PT]
RewriteCond %{SERVER_NAME} brand2.weretail.com [ NC]
RewriteRule /sitemap.xml$ /content/weretail/general/sitemap.xml [ NC,PT]
RewriteRule /logo.jpg$ /content/dam/weretail/general/logo.jpg [ NC,PT]

D. AMS Farm Includes

Lorsque des fichiers <FILENAME>_farm.any du répertoire /etc/httpd/conf.dispatcher.d/available_farms/ sont associés dans le répertoire /etc/httpd/conf.dispatcher.d/enabled_farms/, ils sont utilisés dans la configuration en cours d’exécution.

Les fichiers de fermes comportent des sous-inclusions basées sur les sections de niveau supérieur de la ferme comme le cache, les en-têtes clients, les filtres, les rendus et les hôtes virtuels.

Les fichiers <FILENAME>_farm.any contiendront des instructions pour chaque fichier en fonction de l’endroit où ils doivent être inclus dans le fichier de ferme. Voici un exemple de syntaxe d’un fichier <FILENAME>_farm.any comme référence appropriée :

/weretailfarm {
 /clientheaders {
 $include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_publish_clientheaders.any"
 $include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_common_clientheaders.any"
 }
 /virtualhosts {
 $include "/etc/httpd/conf.dispatcher.d/vhosts/weretail_vhosts.any"
 }
 /renders {
 $include "/etc/httpd/conf.dispatcher.d/renders/ams_publish_renders.any"
 }
 /filter {
 $include "/etc/httpd/conf.dispatcher.d/filters/ams_publish_filters.any"
 $include "/etc/httpd/conf.dispatcher.d/filters/weretail_search_filters.any"
 }
 ....SNIP....
 /cache {
 ....SNIP....
 /rules {
 $include "/etc/httpd/conf.dispatcher.d/cache/ams_publish_cache.any"
 }
 ....SNIP....
 /allowedClients {
 /0000 {
 /glob "*.*.*.*"
 /type "deny"
 }
 $include "/etc/httpd/conf.dispatcher.d/cache/ams_publish_invalidate_allowed.any"
 }
 ....SNIP....
 }
}

Comme vous pouvez voir chaque section pour la ferme de serveurs weretail au lieu de disposer de toutes les syntaxes nécessaires, elle utilise plutôt une instruction d’inclusion.

Examinons la syntaxe de quelques-unes de ces inclusions pour obtenir l’idée de ce à quoi ressemblerait chaque sous-inclusion /etc/httpd/conf.dispatcher.d/vhosts/weretail_publish_vhosts.any :

"brand1.weretail.com"
"brand2.weretail.com"
"www.weretail.comf"

Comme vous pouvez le constater, il s’agit d’une nouvelle liste de noms de domaine séparés par des lignes qui doivent être rendus à partir de cette ferme de serveurs par rapport aux autres.

Examinons ensuite le /etc/httpd/conf.dispatcher.d/filters/weretail_search_filters.any :

/400 { /type "allow" /method "GET" /path "/bin/weretail/lists/*" /extension "json" }
/401 { /type "allow" /method "POST" /path "/bin/weretail/search/" /extension "html" }