Déploiement sur AEM as a Cloud Service deploying-to-aem-as-a-cloud-service

Présentation introduction

Les principes fondamentaux du développement de code sont similaires dans AEM as a Cloud Service par rapport aux solutions AEM On Premise et Managed Services. Les développeurs et développeuses écrivent du code et le testent localement. Il est ensuite envoyé vers les environnements distants AEM as a Cloud Service. Cloud Manager, qui était un outil de diffusion de contenu facultatif pour Managed Services, est requis. Cet outil de diffusion est désormais l’unique mécanisme permettant de déployer du code vers les environnements de production, d’évaluation et de développement d’AEM as a Cloud Service. Pour une validation rapide des fonctionnalités et un débogage avant de déployer ces environnements, le code peut être synchronisé d’un environnement local vers un Environnement de développement rapide.

La mise à jour de la version d’AEM est toujours un événement de déploiement distinct de la publication de code personnalisé. Sinon, les versions de code personnalisé doivent être testées par rapport à la version d’AEM en cours de production, car c’est sur cette version qu’elles sont déployées. Les mises à jour de version d’AEM qui se produisent par la suite (qui sont fréquentes et appliquées automatiquement) sont censées être rétrocompatibles avec le code client déjà déployé.

Le reste de ce document décrit comment les développeurs adaptent leurs pratiques pour fonctionner avec les mises à jour de la version d’AEM as a Cloud Service et les mises à jour client.

Versions client customer-releases

Codage par rapport à la version appropriée d’AEM coding-against-the-right-aem-version

Pour les solutions AEM précédentes, la version d’AEM était rarement modifiée et les clients mettaient à jour les instances de production vers le quickstart le plus récent, en référençant le fichier Jar de l’API. Toutefois, les applications sur AEM as a Cloud Service sont automatiquement mises à jour vers la dernière version d’AEM à une fréquence plus élevée, de sorte que le code personnalisé pour les versions internes doit être créé par rapport à la dernière version d’AEM.

Comme pour les versions d’AEM non cloud existantes, le développement hors ligne local basé sur un démarrage rapide spécifique est pris en charge. Il s’agit généralement de l’outil principal de débogage.

Pour développer du code personnalisé pour une version interne, vous devez télécharger et installer la version appropriée du SDK AEM as a Cloud Service. Pour plus d’informations sur l’utilisation des outils AEM as a Cloud Service Dispatcher, voir Dispatcher en mode cloud.

La vidéo suivante présente une vue d’ensemble générale du déploiement du code vers AEM as a Cloud Service :

Déploiement de packages de contenu via Cloud Manager et le gestionnaire de packages deploying-content-packages-via-cloud-manager-and-package-manager

Déploiements via Cloud Manager deployments-via-cloud-manager

Les clients et clientes déploient le code personnalisé dans les environnements cloud via Cloud Manager. Cloud Manager transforme des packages de contenu assemblés localement en artefact conforme au modèle de fonctionnalité Sling. Ce modèle décrit une application sur AEM as a Cloud Service lors de l’exécution dans un environnement cloud. Par conséquent, lorsque vous examinez les packages dans le Gestionnaire de modules sur les environnements cloud, le nom comprend « cp2fm » et toutes les métadonnées des packages transformés sont supprimées. Il est impossible d’interagir avec eux, ce qui signifie qu’ils ne peuvent pas être téléchargés, répliqués ni ouverts. Pour obtenir une documentation détaillée à propos du convertisseur, voir sling-org-apache-sling-feature-cpconverter sur GitHub.

Les packages de contenu pour AEM as a Cloud Service doivent séparer le contenu modifiable du contenu non modifiable. Cloud Manager installe uniquement le contenu modifiable et génère un message du type suivant :

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

Le reste de cette section décrit la composition et les implications des packages immuables et mutables.

Packages de contenu non modifiables immutabe-content-packages

L’ensemble du contenu et du code conservés dans le référentiel non modifiable doit être archivé dans git et déployé via Cloud Manager. En d’autres termes, contrairement aux solutions AEM actuelles, le code n’est jamais déployé directement sur une instance AEM en cours d’exécution. Ce processus garantit que le code en cours d’exécution est identique pour une version donnée dans n’importe quel environnement cloud, ce qui élimine le risque de variation non intentionnelle du code en production. Par exemple, la configuration OSGI doit être validée dans le contrôle de code source plutôt que d’être gérée au moment de l’exécution par le biais du gestionnaire de configuration de la console web AEM.

Un commutateur active les modifications de l’application en raison du modèle de déploiement. Il ne peut donc pas dépendre des modifications du référentiel modifiable, à l’exception des utilisateurs du service, de leurs listes de contrôle d’accès, de leurs types de nœuds et des modifications de définition d’index.

Pour les clients et clientes qui disposent de bases de code, il est essentiel de passer par l’exercice de restructuration du référentiel décrit dans la documentation d’AEM en vue de s’assurer que le contenu qui se trouvait auparavant sous /etc est déplacé vers le bon emplacement.

Certaines restrictions supplémentaires s’appliquent à ces packages de code, par exemple, les ​ hooks d’installation ​ ne sont pas pris en charge.

Configuration OSGI osgi-configuration

Comme mentionné ci-dessus, la configuration OSGI doit être validée dans le contrôle de code source plutôt que par le biais de la console web. Pour ce faire, les techniques suivantes sont disponibles :

Pour plus d’informations sur la configuration d’OSGI, voir la section Configuration d’OSGi pour AEM as a Cloud Service.

Contenu mutable mutable-content

Parfois, il est utile de préparer les modifications de contenu dans le contrôle de code source afin que Cloud Manager les déploie chaque fois qu’un environnement est mis à jour. Par exemple, il est judicieux d’amorcer certaines structures de dossiers racine. Pour activer les composants de politiques que le déploiement d’application met à jour, alignez les modifications dans les modèles modifiables.

Cloud Manager déploie le contenu dans le référentiel modifiable en utilisant deux stratégies : des packages de contenu modifiables et des instructions repoinit.

Packages de contenu modifiables mutable-content-packages

Les contenus tels que les hiérarchies de chemins de dossier, les utilisateurs du service et les contrôles d’accès (ACL) sont généralement validés dans un projet AEM Maven basé sur l’archétype. Les techniques incluent l’exportation depuis AEM ou l’écriture directe au format XML. Au cours du processus de création et de déploiement, Cloud Manager crée le package de contenu modifiable résultant. Le contenu modifiable est installé à trois reprises lors de la phase de déploiement du pipeline :

Avant le démarrage de la nouvelle version de l’application :

Au démarrage d’une nouvelle version de l’application, mais avant le basculement :

Après le basculement vers la nouvelle version de l’application :

Il est possible de limiter l’installation de contenu modifiable à la création ou à la publication en incorporant des packages dans un dossier install.author ou install.publish sous /apps. Une restructuration pour refléter cette séparation a été effectuée dans AEM 6.5 et les détails relatifs à la restructuration de projet recommandée sont disponibles dans la documentation d’AEM 6.5 ​.

En outre, il n’existe aucun mécanisme pour annuler les modifications de package de contenu modifiable après les avoir appliquées. Si les clients et clientes détectent un problème, ils peuvent choisir de le résoudre dans la prochaine version de leur code ou, en dernier recours, restaurer l’ensemble du système à un moment donné avant le déploiement.

Tous les packages tiers inclus doivent être validés comme étant compatibles avec AEM as a Cloud Service. Dans le cas contraire, leur inclusion entraîne un échec du déploiement.

Comme mentionné ci-dessus, les clients disposant de bases de code se conforment à l’exercice de restructuration du référentiel nécessaire aux modifications du référentiel dans la version 6.5, comme décrit dans la documentation d’AEM 6.5.

Repoinit repoinit

Pour les cas suivants, il est préférable d’adopter l’approche du codage manuel pour la création de contenu explicite repoinit les instructions dans les configurations d’usine OSGI :

Il est préférable d’opter pour repoinit pour ces scénarios de modification de contenu pris en charge en raison des avantages suivants :

Lorsque Cloud Manager déploie l’application, il exécute ces instructions, indépendamment de l’installation des modules de contenu.

Pour créer des instructions repoinit, procédez comme suit

Pour plus d’informations sur repoinit, voir la documentation Sling

Utilisations ponctuelles du gestionnaire de modules pour les modules de contenu modifiables package-manager-oneoffs-for-mutable-content-packages

Il existe des cas d’utilisation où un package de contenu doit être installé en une seule fois. Par exemple, pour déboguer un problème de production, vous devez importer du contenu spécifique de la production vers l’évaluation. Pour ces scénarios, le gestionnaire de modules peut être utilisé dans les environnements sur AEM as a Cloud Service.

Le gestionnaire de packages est un concept d’exécution ; il n’est pas possible d’installer du contenu ou du code dans le référentiel non modifiable, et ces packages de contenu consistent en du contenu modifiable (principalement /content ou /conf). Si le module de contenu comprend du contenu mixte (modifiable et non modifiable), seul le contenu modifiable est installé.

Toutes les installations de packages de contenu Cloud Manager (modifiables et non modifiables) apparaissent figées dans l’interface utilisateur du gestionnaire de packages d’AEM. Ces packages ne peuvent pas être réinstallés, reconstruits ou même téléchargés. Ils sont répertoriés avec un suffixe « cp2fm », indiquant que Cloud Manager a effectué leur installation.

Inclusion de packages tiers including-third-party

Il est courant pour les clientes et les clients d’inclure des packages préconfigurés provenant de sources tierces, telles que des fournisseurs de logiciels comme les partenaires de traduction d’Adobe. Il est recommandé d’héberger ces packages au sein d’un référentiel distant et de les référencer dans le pom.xml. Cette méthode est possible pour les référentiels publics et pour les référentiels privés avec protection par mot de passe, comme décrit dans Référentiels Maven protégés par mot de passe.

S’il n’est pas possible de stocker le package dans un référentiel distant, les clientes et clients peuvent le placer dans un référentiel Maven local basé sur un système de fichiers, qui est validé dans SCM dans le cadre du projet. Tout ce qui en dépend y fait référence. Ce référentiel est déclaré dans les fichiers POM du projet, comme illustré ci-dessous :

<repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>

Les packages tiers inclus doivent respecter les directives de codage et de création de package d’AEM as a Cloud Service décrites dans cet article. Sinon, leur inclusion entraîne un échec du déploiement.

L’extrait de code POM.xml Maven suivant montre comment les packages tiers peuvent être intégrés dans le package « Conteneur » du projet, généralement appelé « all », au moyen de la configuration du plug-in Maven filevault-package-maven-plugin.

...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <embeddeds>

          ...

          <!-- Include any other extra packages  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Fonctionnement des déploiements en continu how-rolling-deployments-work

Comme les mises à jour d’AEM, les versions client sont déployées à l’aide d’une stratégie de déploiement en continu, afin d’éliminer les temps d’arrêt du cluster de création dans des conditions appropriées. La séquence générale des événements est décrite ci-dessous, où les nœuds comportant à la fois l’ancienne version et la nouvelle version du code client exécutent la même version du code AEM.

Index indexes

Les nouveaux index ou les index modifiés entraînent une étape supplémentaire d’indexation ou de réindexation avant que la nouvelle version puisse prendre en charge le trafic. Vous trouverez des informations détaillées sur la gestion des index dans AEM as a Cloud Service sous Recherche et indexation de contenu. Vous pouvez vérifier le statut d’indexation des pages de build sur Cloud Manager et recevoir une notification lorsque la nouvelle version est prête à recevoir le trafic.

Actuellement, AEM as a Cloud Service ne fonctionne pas avec des outils de gestion d’index tels que l’outil ACS Commons Ensure Oak Index.

Réplication replication

Le mécanisme de publication est rétrocompatible avec les API Java™ de réplication AEM.

Pour développer et tester la réplication à l’aide du démarrage rapide d’AEM prêt pour le cloud, utilisez les fonctionnalités de réplication classiques avec une configuration Auteur/Publication. Si le point d’entrée de l’interface utilisateur sur l’instance de création AEM est supprimé pour le cloud, les personnes utilisatrices accèdent à http://localhost:4502/etc/replication pour la configuration.

Code rétrocompatible pour les déploiements en continu backwards-compatible-code-for-rolling-deployments

Comme décrit ci-dessus, la stratégie de déploiement en continu d’AEM as a Cloud Service implique que l’ancienne et la nouvelle version fonctionnent toutes deux en même temps. Par conséquent, faites attention aux modifications de code qui ne sont pas rétrocompatibles avec l’ancienne version d’AEM toujours opérationnelle.

En outre, l’ancienne version doit être testée pour vérifier sa compatibilité avec toute nouvelle structure de contenu modifiable appliquée par la nouvelle version en cas de restauration, puisque le contenu modifiable n’est pas supprimé.

Utilisateurs du service et modifications des listes de contrôle d’accès service-users-and-acl-changes

Le changement des utilisateurs et utilisatrices du service, ou listes de contrôle d’accès qui accèdent au contenu ou au code, entraîne des erreurs dans les anciennes versions d’AEM, ce qui entraîne l’accès à ce contenu ou à ce code avec des utilisateurs et utilisatrices de services obsolètes. Pour remédier à ce problème, il est recommandé d’effectuer des modifications réparties sur au moins deux versions, la première version servant de transition avant de procéder au nettoyage dans la version suivante.

Modifications d’index index-changes

Si des modifications sont apportées aux index, il est important que l’ancienne version continue à utiliser ses index jusqu’à ce qu’elle soit terminée, tandis que la nouvelle version utilise son propre jeu d’index modifié. Le développeur suit les techniques de gestion des index décrites sous Recherche et indexation de contenu.

Codage conservateur pour les restaurations conservative-coding-for-rollbacks

Si un échec est signalé ou détecté après le déploiement, il est possible qu’une restauration de l’ancienne version soit nécessaire. Assurez-vous que le nouveau code est compatible avec toutes les nouvelles structures créées par cette nouvelle version. En effet, les nouvelles structures (tout contenu modifiable) ne sont pas restaurées. Si l’ancien code n’est pas compatible, des correctifs doivent être appliqués dans les versions du client ultérieures.

Environnements de développement rapide (RDE) rde

Les ​ Environnements de développement rapide ​ (ou RDE) permettent aux développeurs et aux développeuses de déployer et d’examiner rapidement les modifications. Cela réduit le temps nécessaire pour tester les fonctionnalités qui fonctionnent déjà dans un environnement de développement local.

Contrairement aux environnements de développement standard qui déploient le code via le pipeline de Cloud Manager, les développeurs et les développeuses utilisent des outils de ligne de commande pour synchroniser le code d’un environnement de développement local avec le RDE. Une fois les modifications testées avec succès dans un RDE, déployez-les dans un environnement de développement Cloud standard via le pipeline de Cloud Manager, qui place le code par le biais des points de contrôle qualité appropriés.

Modes d’exécution runmodes

Dans les solutions AEM existantes, les clients ont la possibilité d’exécuter des instances avec des modes d’exécution arbitraires et d’appliquer la configuration OSGI ou d’installer des lots OSGI sur ces instances spécifiques. Les modes d’exécution définis incluent généralement le service (création et publication) et l’environnement (RDE, développement, évaluation et production).

AEM as a Cloud Service, en revanche, est plus précis sur les modes d’exécution disponibles et sur la manière dont les bundles OSGI et la configuration OSGI peuvent être mappés sur ces modes :

AEM as a Cloud Service ne permet pas d’utiliser des modes d’exécution pour installer du contenu destiné à des environnements ou des services spécifiques. Si un environnement de développement doit être alimenté avec des données ou un HTML qui ne se trouvent pas dans les environnements d’évaluation ou de production, le gestionnaire de modules peut être utilisé.

Les configurations de mode d’exécution prises en charge sont les suivantes :

La configuration OSGI qui possède le plus grand nombre de modes d’exécution correspondants est utilisée.

Lors d’un développement local, un paramètre de démarrage en mode d’exécution, -r, est utilisé pour spécifier la configuration OSGI du mode d’exécution.

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

Configuration des tâches de maintenance dans le contrôle de code source maintenance-tasks-configuration-in-source-control

Les configurations de tâches de maintenance doivent être conservées dans le contrôle de la source, car l’écran Outils > Opérations n’est plus disponible dans les environnements cloud. Cet avantage permet de s’assurer que les modifications sont intentionnellement conservées, plutôt qu’appliquées de manière réactive et oubliées. Voir ​ Tâches de maintenance dans AEM as a Cloud Service pour plus d’informations.