Mise en production go-live

Dans cette partie du parcours, vous apprenez à planifier et à effectuer la migration une fois que le code et le contenu sont prêts à être déplacés vers AEM as a Cloud Service. En outre, vous découvrez les bonnes pratiques et les limites connues lors de la migration.

Un peu d’histoire… story-so-far

Dans les phases précédentes du parcours :

  • Vous avez appris comment démarrer la migration vers AEM as a Cloud Service à la page Prise en main.
  • Vous avez déterminé si votre déploiement est prêt à être déplacé vers le cloud en consultant la Phase de préparation.
  • Vous vous êtes familiarisé avec les outils et le processus qui vous permettent de préparer votre code et votre contenu pour le cloud avec la phase d’implémentation.

Objectif objective

Ce document vous aidera à comprendre comment effectuer la migration vers AEM as a Cloud Service une fois que vous maîtriserez les étapes précédentes du parcours. Vous apprendrez comment effectuer la migration de production initiale, ainsi que les bonnes pratiques à suivre lors de la migration vers AEM as a Cloud Service.

Migration de production initiale initial-migration

Avant d’effectuer la migration de production, suivez les étapes d’adaptation et de preuve de migration décrites dans la section Stratégie et calendrier de la migration de contenu de la phase d’implémentation.

  • Lancez la migration de production en vous appuyant sur l’expérience acquise lors de la migration d’évaluation AEM as a Cloud Service effectuée sur des clones :

    • Création-Création
    • Publication-Publication
  • Validez le contenu ingéré dans les niveaux de création et de publication d’AEM as a Cloud Service.

  • Demandez à l’équipe de création de contenu d’éviter de déplacer le contenu à la fois sur la source et la destination jusqu’à ce que l’ingestion soit terminée.

  • Vous pouvez ajouter, modifier ou supprimer du nouveau contenu, mais évitez de le déplacer. Ceci s’applique à la fois à la source et à la destination.

  • Enregistrez le temps nécessaire à l’extraction et à l’ingestion complètes afin de disposer d’une estimation pour les futures délais de migration complémentaire.

  • Créez un planificateur de migration pour les créations et les publications.

Compléments incrémentiels top-up

Après la migration initiale depuis la production, vous devez effectuer des compléments incrémentiels pour vous assurer que votre contenu est à jour sur l’instance cloud. C’est pourquoi il est recommandé de suivre les bonnes pratiques suivantes :

  • Rassemblez les données sur la quantité de contenu. Par exemple : par semaine, par quinzaine ou par mois.
  • Veillez à planifier les compléments de manière à éviter l’extraction et l’ingestion de contenu pendant plus de 48 heures. Cette action vous est recommandée afin que les compléments de contenu puissent être effectués pendant le week-end.
  • Prévoyez le nombre de compléments nécessaires et utilisez ces estimations pour planifier la date de mise en production.

Déterminer les délais de gel du code et du contenu pour la migration code-content-freeze

Comme mentionné précédemment, vous devrez planifier une période de gel du code et du contenu. Répondez aux questions suivantes pour vous aider à planifier la période de gel :

  • Combien de temps dois-je geler les activités de création de contenu ?
  • Pendant combien de temps dois-je demander à mon équipe de diffusion de cesser d’ajouter de nouvelles fonctionnalités ?

Pour répondre à la première question, prenez en compte le temps nécessaire pour effectuer des essais dans des environnements de non-production. Pour répondre à la seconde question, il faut une collaboration étroite entre l’équipe qui ajoute de nouvelles fonctionnalités et l’équipe qui remanie le code. L’objectif est de s’assurer que tout le code qui est ajouté au déploiement existant est également ajouté, testé et déployé dans la branche des services cloud. En général, cela signifie que la quantité de code gelé est inférieure.

En outre, vous devez prévoir un gel du contenu lorsque le complément final de contenu est planifié.

Bonnes pratiques best-practices

Lors de la planification ou de l’exécution de la migration, tenez compte des recommandations suivantes :

  • Migrer de création à création et de publication à publication

  • Demandez un clone de production qui peut être utilisé pour :

    • Capturer les statistiques du référentiel
    • Prouver les activités de migration
    • Préparer le programme de migration
    • Identifier les besoins de gel du contenu
    • Identifier les besoins de mise à niveau de la production lors de la migration depuis la production

Bonnes pratiques de l’outil de transfert de contenu

Lors de la mise en production, assurez-vous d’exécuter la migration du contenu sur la production plutôt que sur un clone. Une bonne approche consiste à utiliser AZCopy pour la migration initiale, puis à exécuter fréquemment (voire quotidiennement) des extractions complémentaires afin d’extraire de plus petits blocs et d’éviter toute charge à long terme sur l’AEM source.

Lors de la migration de production, évitez d’exécuter l’outil de transfert de contenu à partir d’un clone, et ce, pour les raisons suivantes :

  • Si un client exige que les versions de contenu soient migrées pendant les migrations complémentaires, l’exécution de l’outil de transfert de contenu à partir d’un clone ne permet pas de migrer les versions. Même si le clone est fréquemment recréé à partir de l’instance de création en direct, chaque fois qu’un clone est créé, les points de contrôle qui sont utilisés par l’outil de transfert de contenu pour calculer les deltas sont réinitialisés.
  • Puisqu’un clone ne peut pas être actualisé dans son ensemble, le package de requêtes ACL doit être utilisé pour combiner et installer le contenu ajouté ou modifié de la production au clone. Le problème avec cette approche est que tout contenu supprimé sur l’instance source n’aura jamais accès au clone, sauf s’il est supprimé manuellement de la source et du clone. Il est donc possible que le contenu supprimé en production ne soit pas supprimé sur le clone et sur AEM as a Cloud Service.

Optimiser la charge de votre source AEM lors de la migration du contenu

Souvenez-vous que la charge sur la source AEM est plus importante pendant la phase d’extraction. Tenez compte des points suivants :

  • L’outil de transfert de contenu est un processus Java externe qui utilise un tas JVM de 4 Go.
  • La version non-AzCopy télécharge les fichiers binaires, les stocke dans un espace temporaire sur l’auteur de l’AEM source, consommant des E/S de disque, puis les charge dans le conteneur Azure, ce qui consomme de la bande passante réseau.
  • AzCopy transfère les blobs directement de la banque d’objets blob vers le conteneur Azure, ce qui permet d’économiser les E/S de disque et la bande passante du réseau. La version AzCopy utilise toujours la bande passante du disque et du réseau pour extraire et charger les données du magasin de segments dans le conteneur Azure.
  • Le processus de l’outil de transfert de contenu est moins gourmand en ressources système pendant la phase d’ingestion, car il ne diffuse que les journaux d’ingestion et qu’il n’y a pas beaucoup de charge sur l’instance source en ce qui concerne les E/S de disque ou la bande passante du réseau.

Limites connues known-limitations

Veuillez tenir compte du fait que l’ingestion entière échoue si l’une des limites suivantes fait partie du jeu de migration extrait :

  • Un nœud JCR dont le nom comporte plus de 150 caractères
  • Un nœud JCR dont la taille est supérieure à 16 Mo
  • Tout utilisateur/groupe avec rep:AuthorizableID ingéré et déjà présent sur AEM as a Cloud Service.
  • Si une ressource extraite et ingérée change de chemin d’accès à la source ou à la destination avant l’itération suivante de la migration.

Intégrité des ressources asset-health

Comparé à la section ci-dessus, l’ingestion n’échoue pas en raison des problèmes de ressources suivants. Toutefois, il est vivement recommandé de prendre les mesures appropriées dans ces scénarios :

  • Toute ressource dont le rendu original est manquant.
  • Tout dossier manquant jcr:content noeud .

Les deux éléments ci-dessus sont identifiés et signalés dans le rapport de Best Practice Analyzer.

Liste de contrôle de mise en production Go-Live-Checklist

Passez en revue cette liste d’activités pour vous assurer d’effectuer une migration en douceur et réussie.

  • Exécutez un pipeline de production de bout en bout avec des tests fonctionnels et d’interface utilisateur pour garantir une expérience du produit AEM toujours actuelle. Reportez-vous aux ressources suivantes.

  • Migrez le contenu en production et assurez-vous qu’un sous-ensemble approprié est disponible lors de l’évaluation pour les tests.

    • Les bonnes pratiques des DevOps pour AEM impliquent que le code passe du développement à l’environnement de production pendant que le contenu passe aux environnements de production.
  • Planifiez une période de gel du code et du contenu.

  • Effectuez la dernière mise à jour du contenu.

  • Validez les configurations du Dispatcher.

    • Utilisez un programme de validation de Dispatcher local qui facilite la configuration, la validation et la simulation locale du Dispatcher.

    • Examinez attentivement la configuration de l’hôte virtuel.

      • La solution la plus simple (et celle par défaut) est d’inclure ServerAlias * dans votre fichier d’hôte virtuel dans le /dispatcher/src/conf.d/available_vhostsfolder.

        • Ainsi, les alias d’hôte utilisés par les tests fonctionnels du produit, l’invalidation du cache du Dispatcher et les clones pourront tous fonctionner.
      • Cependant, si le ServerAlias * n’est pas acceptable, vous devez autoriser au minimum les entrées ServerAlias suivantes en plus de vos domaines personnalisés :

        • localhost
        • *.local
        • publish*.adobeaemcloud.net
        • publish*.adobeaemcloud.com
  • Configurez le CDN, le SSL et le DNS.

    • Si vous utilisez votre propre réseau de diffusion de contenu, saisissez un ticket d’assistance pour configurer le routage approprié.

    • Si vous n’utilisez pas de réseau de diffusion de contenu supplémentaire, configurez le SSL et le DNS conformément à la documentation suivante :

    • N’oubliez pas de valider le jeu TTL pour votre enregistrement DNS.

      • Le TTL est la durée pendant laquelle un enregistrement DNS reste dans un cache avant de demander une mise à jour au serveur.
      • Avec un TTL très élevé, les mises à jour de votre enregistrement DNS prendront plus de temps à se propager.
  • Exécutez des tests de performance et de sécurité qui répondent aux besoins et aux objectifs de votre entreprise.

    • Effectuez des tests dans un environnement intermédiaire. Celui-ci a la même taille que l’environnement de production.
    • Les environnements de développement n’ont pas la même taille que l’évaluation et la production.
  • Effectuez une coupure et assurez-vous que la mise en service réelle est effectuée sans aucun nouveau déploiement ni mise à jour du contenu.

  • Créez des profils de notification pour les utilisateurs et les utilisatrices de l’Admin Console. Consultez Profils de notification

  • Envisagez de configurer des règles de filtrage du trafic afin de contrôler le trafic qui ne doit pas être autorisé sur votre site web.

    • Les règles de filtrage du trafic de limite de taux peuvent être un outil efficace contre les attaques DDoS. Une catégorie spéciale de règles de filtrage du trafic, appelée règles WAF, nécessite une licence distincte.
    • Voir la documentation pour certains règles de démarrage suggérées.

Vous pouvez toujours vous référer à cette liste au cas où vous auriez besoin de recalibrer vos tâches lors de la migration.

Prochaines étapes what-is-next

Une fois que vous avez compris comment effectuer la migration vers AEM as a Cloud Service, vous pouvez consulter la page Post-mise en production pour assurer le bon fonctionnement de votre instance.

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab