Migration de la configuration Dispatcher d’AMS vers AEM as a Cloud Service Dispatcher-in-the-cloud
Principales différences entre AMS Dispatcher et AEM as a Cloud Service main-differences-between-ams-dispatcher-configuration-and-aem-as-a-cloud-service
La configuration Apache et Dispatcher dans AEM as a Cloud Service est assez similaire à la configuration AMS. Les principales différences sont :
- Dans AEM as a Cloud Service, certaines directives Apache peuvent ne pas être utilisées (par exemple,
ListenouLogLevel) - Dans AEM as a Cloud Service, seules certaines parties de la configuration Dispatcher peuvent être placées dans les fichiers d’inclusion et les noms qui leur sont donnés sont importants. Par exemple, les règles de filtrage que vous souhaitez réutiliser sur différents hôtes doivent être placées dans un fichier nommé
filters/filters.any. Consultez la page de référence pour plus d’informations. - Dans AEM as a Cloud Service, il existe une validation supplémentaire pour interdire les règles de filtrage écrites avec
/globde façon à éviter les problèmes de sécurité. Puisquedeny *est utilisé plutôt queallow *(qui ne peut pas être utilisé), les clients et les clientes auront avantage à exécuter le Dispatcher localement et à procéder par tâtonnements, en examinant les journaux pour savoir exactement quels chemins sont bloqués par les filtres Dispatcher afin de pouvoir les ajouter. - Dans AEM as a Cloud Service, il est actuellement vivement recommandé de choisir d’utiliser le mode source flexible de la configuration du Dispatcher par exemple d’utiliser des pipelines de configuration de niveau web ou d’avoir une meilleure flexibilité sur le nombre et la structure des fichiers de configuration.
Instructions relatives à la migration de la configuration Dispatcher d’AMS vers AEM as a Cloud Service
La structure de configuration Dispatcher présente des différences entre Managed Services et AEM as a Cloud Service. Vous trouverez ci-dessous un guide détaillé sur la migration de la configuration Dispatcher d’AMS version 2 vers AEM as Cloud Service.
Comment convertir une configuration Dispatcher AMS en configuration AEM as a Cloud Service
La section suivante fournit des instructions étape par étape pour convertir une configuration AMS. Il suppose que :
vous disposez d’une archive avec une structure similaire à celle décrite dans la configuration de Cloud Manager Dispatcher 🔗
Extraire l’archive et supprimer tout préfixe
Extrayez l’archive dans un dossier et assurez-vous que les sous-dossiers immédiats commencent par conf, conf.d,conf.dispatcher.d et conf.modules.d. Si tel n’est pas le cas, déplacez-les dans la hiérarchie.
Supprimer les sous-dossiers et fichiers non utilisés
Supprimez les sous-dossiers conf et conf.modules.d, ainsi que les fichiers correspondants conf.d/*.conf.
Supprimer tous les hôtes virtuels non publiés
Supprimez tout fichier hôte virtuel dans conf.d/enabled_vhosts qui a author, unhealthy, health,lc ou flush dans son nom. Tous les fichiers hôtes virtuels dans conf.d/available_vhosts qui ne le sont pas
lié à peut également être supprimé.
Supprimer ou mettre en commentaires les sections d’hôte virtuel qui ne font pas référence au port 80
Si des sections de vos fichiers d’hôtes virtuels font encore référence exclusivement à d’autres ports que le port 80, par exemple :
<VirtualHost *:443>
...
</VirtualHost>
supprimez-les ou commentez-les. Les instructions de ces sections ne seront pas traitées, mais si vous
si vous les conservez, vous risquez de les modifier sans effet, ce qui est déroutant.
Vérifier les réécritures
Entrez dans le répertoire conf.d/rewrites.
Supprimez tout fichier nommé base_rewrite.rules et xforwarded_forcessl_rewrite.rules et pensez à
supprimez les instructions Include dans les fichiers hôtes virtuels qui y font référence.
Si conf.d/rewrites contient désormais un seul fichier , il doit être renommé rewrite.rules et non .
oubliez d’adapter également les instructions Include faisant référence à ce fichier dans les fichiers d’hôtes virtuels.
Si le dossier contient toutefois plusieurs fichiers spécifiques à l’hôte virtuel, leur contenu doit être .
copié dans l’instruction Include qui y fait référence dans les fichiers d’hôtes virtuels.
Vérifier les variables
Entrez dans le répertoire conf.d/variables.
Supprimez tout fichier nommé ams_default.vars et pensez à supprimer les instructions Include dans le virtuel
les fichiers hôtes qui y font référence.
Si conf.d/variables contient désormais un seul fichier , il doit être renommé custom.vars et non .
oubliez d’adapter également les instructions Include faisant référence à ce fichier dans les fichiers d’hôtes virtuels.
Si le dossier contient toutefois plusieurs fichiers spécifiques à l’hôte virtuel, leur contenu doit être .
copié dans l’instruction Include qui y fait référence dans les fichiers d’hôtes virtuels.
Supprimer des listes autorisées
Supprimez le conf.d/whitelists de dossiers et supprimez les instructions de Include dans les fichiers hôtes virtuels faisant référence à
un fichier dans ce sous-dossier.
Remplacer toute variable qui n’est plus disponible
Dans tous les fichiers d’hôtes virtuels :
Renommez PUBLISH_DOCROOT en . DOCROOT
Supprimez les sections faisant référence à des variables nommées DISP_ID, PUBLISH_FORCE_SSL ou PUBLISH_WHITELIST_ENABLED
Vérifier votre état en exécutant le programme de validation
Exécutez le programme de validation du Dispatcher dans votre répertoire, avec la sous-commande httpd :
$ validator httpd .
Si des erreurs s’affichent au sujet des fichiers d’inclusion manquants, vérifiez si vous les avez correctement renommés
fichiers.
Si vous voyez des directives Apache qui ne sont pas placées sur la liste autorisée, supprimez-les.
Supprimer toutes les fermes non publiées
Supprimez tout fichier de ferme dans conf.dispatcher.d/enabled_farms qui a author, unhealthy, health,lc ou flush dans son nom. Tous les fichiers de ferme dans conf.dispatcher.d/available_farms qui ne le sont pas
lié à peut également être supprimé.
Renommer les fichiers de fermes
Toutes les fermes dans conf.dispatcher.d/enabled_farms doivent être renommées afin de correspondre au modèle *.farm, par exemple, .
le fichier de ferme appelé customerX_farm.any doit être renommé customerX.farm.
Vérifier le cache
Entrez dans le répertoire conf.dispatcher.d/cache.
Supprimez tout fichier portant le préfixe ams_.
Si conf.dispatcher.d/cache est maintenant vide, copiez le fichier conf.dispatcher.d/cache/rules.any
de la configuration Dispatcher standard à ce dossier. Le Dispatcher standard
La configuration se trouve dans la src de dossiers de ce SDK. N’oubliez pas d’adapter le$include des instructions faisant référence aux fichiers de règles ams_*_cache.any dans les fichiers de la batterie
et aussi.
Si au lieu de cela conf.dispatcher.d/cache contient désormais un seul fichier avec le suffixe _cache.any,
il doit être renommé rules.any et ne pas oublier d’adapter les instructions $include
en faisant également référence à ce fichier dans les fichiers de la ferme.
Si le dossier contient toutefois plusieurs fichiers spécifiques à la ferme avec ce motif, leur contenu
doit être copié dans l’instruction $include qui y fait référence dans les fichiers de la batterie de serveurs.
Supprimez tout fichier portant le suffixe _invalidate_allowed.any.
Copiez le fichier conf.dispatcher.d/cache/default_invalidate_any depuis la valeur par défaut
la configuration d’AEM dans le Dispatcher cloud à cet emplacement.
Dans chaque fichier de ferme, supprimez tout contenu de la section cache/allowedClients et remplacez-le
Par :
$include "../cache/default_invalidate.any"
Vérifier les en-têtes de client
Entrez dans le répertoire conf.dispatcher.d/clientheaders.
Supprimez tout fichier portant le préfixe ams_.
Si conf.dispatcher.d/clientheaders contient désormais un seul fichier avec le suffixe _clientheaders.any,
il doit être renommé clientheaders.any et ne pas oublier d’adapter les instructions $include
en faisant également référence à ce fichier dans les fichiers de la ferme.
Si le dossier contient toutefois plusieurs fichiers spécifiques à la ferme avec ce motif, leur contenu
doit être copié dans l’instruction $include qui y fait référence dans les fichiers de la batterie de serveurs.
Copiez le fichier conf.dispatcher/clientheaders/default_clientheaders.any depuis la valeur par défaut
Configuration d’AEM as a Cloud Service Dispatcher à cet emplacement.
Dans chaque fichier de ferme, remplacez les instructions d’inclusion clientheader qui se présentent comme suit :
$include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_publish_clientheaders.any"
$include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_common_clientheaders.any"
par l’instruction suivante :
$include "../clientheaders/default_clientheaders.any"
Vérifier le filtre
Entrez dans le répertoire conf.dispatcher.d/filters.
Supprimez tout fichier portant le préfixe ams_.
Si conf.dispatcher.d/filters contient désormais un seul fichier , il doit être renommé .filters.any et n’oubliez pas d’adapter les énoncés $include qui y font référence
dans les fichiers de la ferme également.
Si le dossier contient toutefois plusieurs fichiers spécifiques à la ferme avec ce motif, leur contenu
doit être copié dans l’instruction $include qui y fait référence dans les fichiers de la batterie de serveurs.
Copiez le fichier conf.dispatcher/filters/default_filters.any depuis la valeur par défaut
Configuration d’AEM as a Cloud Service Dispatcher à cet emplacement.
Dans chaque fichier de ferme, remplacez les instructions d’inclusion de filtre qui se présentent comme suit :
$include "/etc/httpd/conf.dispatcher.d/filters/ams_publish_filters.any"
par l’instruction suivante :
$include "../filters/default_filters.any"
Vérifier les rendus
Entrez dans le répertoire conf.dispatcher.d/renders.
Supprimez tous les fichiers de ce dossier.
Copiez le fichier conf.dispatcher.d/renders/default_renders.any depuis la valeur par défaut
Configuration d’AEM as a Cloud Service Dispatcher à cet emplacement.
Dans chaque fichier de ferme, supprimez tout contenu de la section renders et remplacez-le
Par :
$include "../renders/default_renders.any"
Vérifier les hôtes virtuels
Renommez le répertoire conf.dispatcher.d/vhosts en conf.dispatcher.d/virtualhosts puis entrez dedans.
Supprimez tout fichier portant le préfixe ams_.
Si conf.dispatcher.d/virtualhosts contient désormais un seul fichier , il doit être renommé .virtualhosts.any et n’oubliez pas d’adapter les énoncés $include qui y font référence
dans les fichiers de la ferme également.
Si le dossier contient toutefois plusieurs fichiers spécifiques à la ferme avec ce motif, leur contenu
doit être copié dans l’instruction $include qui y fait référence dans les fichiers de la batterie de serveurs.
Copiez le fichier conf.dispatcher/virtualhosts/default_virtualhosts.any depuis la valeur par défaut
Configuration d’AEM as a Cloud Service Dispatcher à cet emplacement.
Dans chaque fichier de ferme, remplacez les instructions d’inclusion de filtre qui se présentent comme suit :
$include "/etc/httpd/conf.dispatcher.d/vhosts/ams_publish_vhosts.any"
par l’instruction suivante :
$include "../virtualhosts/default_virtualhosts.any"
Vérifier votre état en exécutant le programme de validation
Exécutez le programme de validation du Dispatcher AEM as a Cloud Service dans votre répertoire, avec la sous-commande dispatcher :
$ validator dispatcher .
Si des erreurs s’affichent au sujet des fichiers d’inclusion manquants, vérifiez si vous les avez correctement renommés
fichiers.
Si des erreurs s’affichent concernant une variable PUBLISH_DOCROOT non définie, renommez-la DOCROOT.
Pour toute autre erreur, reportez-vous à la section Dépannage de la
documentation de l’outil de validation.
Tester votre configuration avec un déploiement local (installation de Docker requise)
À l’aide du docker_run.sh de script dans les outils AEM as a Cloud Service Dispatcher, vous pouvez tester cela
votre configuration ne contient aucune autre erreur qui n’apparaîtrait que dans .
déploiement :
Étape 1 : générer des informations de déploiement avec le programme de validation
validator full -d out .
Cela valide la configuration complète et génère des informations de déploiement dans out
Étape 2 : démarrer le Dispatcher dans une image Docker avec ces informations de déploiement
Avec votre serveur de publication AEM en cours d’exécution sur votre ordinateur macOS, à l’écoute sur le port 4503,
vous pouvez exécuter le démarrage du Dispatcher devant ce serveur comme suit :
$ docker_run.sh out docker.for.mac.localhost:4503 8080
Cela démarrera le conteneur et exposera Apache sur le port local 8080.
Utiliser votre nouvelle configuration Dispatcher
Félicitations. Si le programme de validation ne signale plus aucun problème, alors le
le conteneur docker démarre sans erreur ni avertissement, vous êtes
prêt à déplacer votre configuration vers un sous-répertoire dispatcher/src
de votre référentiel git.
Les clientes et les clients qui utilisent la version 1 de la configuration AMS Dispatcher doivent contacter le service clientèle pour les aider à migrer à la version 2 afin de pouvoir suivre les instructions ci-dessus.