Modèle multi-tenant de base pour AEM en tant que service cloud / Blogs / Perficient

Est-ce que vous ou votre client envisagez de passer à AEM en tant que service cloud (AEMaaCS) ? Les environnements entièrement gérés et automatisés proposés par AEMaaCS présentent de nombreux avantages. Mais l’une des choses à considérer est la nécessité d’un configuration multi-locataires. Si vous disposez actuellement d’une configuration multi-tenant, le passage à AEMaaCS nécessitera probablement quelques modifications.

Avec les installations AEM sur site, vous pouvez disposer d’un référentiel distinct pour chaque site Web de locataire, dans lequel vous installez simplement un package de code distinct pour chaque locataire (que ce soit manuellement dans le gestionnaire de packages ou via un pipeline CI/CD dans un outil de votre choix). Il s’agit d’une procédure standard qui fonctionne très bien. Malheureusement, ce modèle ne fonctionnera pas dans AEMaaCS.

Les pipelines de déploiement configurés dans Cloud Manager ne prennent en charge qu’un seul référentiel Git dans AEMaaCS. Et vous ne pouvez disposer que d’un seul pipeline de déploiement de code par environnement. Cela signifie que tout le code déployé dans un environnement donné doit provenir d’un seul référentiel Git.

Heureusement, il existe plusieurs façons de répondre à l’exigence de déploiement à partir d’un seul référentiel Git tout en conservant une configuration multi-tenant. Dans ce blog, nous aborderons le modèle multi-tenant de base pour AEMaaCS.

Modèle multi-tenant de base pour AEMaaCS utilisant des sous-modules Git

Considérez ce scénario :

• Deux sites Web différents doivent être déployés sur la même instance AEM.
• Chaque site Web a sa propre équipe de développement
• Il n’y a pas de chevauchement entre les sites Web
• Chaque équipe souhaite travailler dans son propre référentiel sans que l’autre équipe y ait accès

Configuration du référentiel

Le modèle le plus simple permettant une configuration multi-tenant dans AEMaaCS utilise Sous-modules Git. Dans ce modèle, chaque locataire dispose de son propre référentiel Git avec le projet multi-module Maven standard pour AEM (créé à partir de l’archétype Maven, disponible auprès d’Adobe).

Étant donné que plusieurs locataires déploient leur code sur la même instance AEM, nous avons également besoin d’un référentiel distinct (et du projet Maven) dédié au code commun, aux configurations OSGi et aux fichiers de configuration du répartiteur – tout ce qui est soit partagé entre tous les locataires, soit défini au niveau de l’instance. Ce référentiel (et ce projet) n’est pas strictement nécessaire mais c’est une bonne idée. Cela permet une meilleure séparation des préoccupations et une meilleure gouvernance au sein des équipes de locataires.

La dernière pièce du puzzle est le référentiel principal qui combine les autres référentiels (et les projets Maven) en un seul référentiel pouvant être utilisé pour les déploiements de code. Ce référentiel est le dépôt « shell » qui extrait les autres référentiels en tant que sous-modules Git. Il doit contenir le .gitmodules fichier qui définit les sous-modules Git et le pom.xml déposer. Ce référentiel principal peut également contenir d’autres fichiers, tels que des fichiers YAML définissant vos pipelines personnalisés ou des fichiers de configuration Cloud Manager contenus dans le .cloudmanager dossier.

Voici un schéma de ce à quoi ressemblent ces dépôts.

Vous souhaiterez probablement avoir tous ces référentiels dans votre propre Git et synchroniser uniquement le référentiel principal « shell » avec Adobe Git.

client-communs, site-client-aet site-client-b sont tous des référentiels indépendants et des projets Maven. Vous devriez pouvoir déployer chaque projet séparément (sur votre instance AEM locale, par exemple). Ce sont les référentiels où toutes les mises à jour doivent être effectuées.

client principal est le référentiel principal qui extrait les autres référentiels en tant que sous-modules Git. Même si vous pouvez voir les fichiers dans les sous-modules de ce référentiel principal, vous ne devez modifier aucun de ces fichiers.

Ajout de sous-modules Git au référentiel principal

Tout d’abord, vous devez désigner votre client-communs, site-client-a, et site-client-b référentiels indépendants en tant que sous-modules Git du client principal dépôt.

Il est facile d’ajouter un nouveau sous-module au projet/dépôt principal :

• Exécutez la commande suivante à partir du dossier de niveau supérieur dans le client principal projet:
  git submodule add <REPO_URL>
  où est l’URL du référentiel que vous souhaitez ajouter en tant que sous-module

Après avoir exécuté le ajout d’un sous-module git commande première fois, un nouveau .gitmodules le fichier est créé. Ouvrez le .gitmodules et remarquez qu’un nouveau sous-module a été ajouté. Exécutez le ajout d’un sous-module git commande pour chaque sous-module que vous souhaitez ajouter au référentiel principal. Dans notre cas, nous exécuterons le ajout d’un sous-module git commande trois fois : pour client-communs, site-client-a, et site-client-b référentiels.

• Vous pouvez modifier le .gitmodules et ajoutez/mettez à jour la branche pour chaque sous-module.
• Exécutez la commande sync pour synchroniser les fichiers des sous-modules dans le client principal dépôt
  git submodule update --recursive --init --remote
• commit et push vos mises à jour.

Voici ce que .gitmodules le fichier ressemble à (ici, venant de la branche ‘develop’) :

Une note rapide sur le nom de la succursale dans le .gitmodules déposer. Chacun de vos référentiels aura probablement au moins deux branches (probablement beaucoup plus) : les branches standard « develop » et « main ». Le nom de branche du sous-module Git dans le .gitmodules Le fichier doit correspondre à la branche dans le dépôt principal. Il indique essentiellement à Git quelle branche extraire du référentiel défini comme sous-module Git.
Vous pouvez modifier le .gitmodules fichier et mettez à jour la branche pour chacun des sous-modules.

Voici ce que c’est pareil .gitmodules à quoi ressemblerait le fichier venant de la branche ‘principale’ :

Dans le dépôt principal, vous devez ajouter un fichier pom qui répertorie tous les sous-modules Git en tant que modules Maven.
Voici ce que pom.xml le fichier ressemble pour le client principal dépôt :

Déploiement du code sur votre environnement local

Après avoir configuré votre environnement local, vous devez installer le code. Vous pouvez exécuter la commande build à partir du client principal repo (c’est ce que fait le pipeline de déploiement de code Cloud Manager). Il installera des packages de code pour chacun des sous-modules.

Vous pouvez également cloner le client-communs repo et votre propre dépôt de locataires et exécutez la commande build à partir de ces dépôts séparément.

Vous devez cloner votre référentiel de locataires si vous avez l’intention d’apporter des modifications.
Toute modification de code doit être effectuée dans les dépôts de sous-modules individuels, et non dans le client principal dépôt.

Travailler avec les sous-modules Git

Les développeurs travaillent normalement dans leur dépôt de locataires et parfois dans le client-communs dépôt. Ils commit comme d’habitude et push leurs engagements à distance. Les commits qui ont été poussés vers la télécommande doivent être synchronisés avec le client principal repo (dans le Git du client). Cette synchronisation peut être effectuée après chaque validation dans la branche configurée dans le .gitmodules ou avant le déploiement sur AEM.

Synchronisation des mises à jour des sous-modules vers le dépôt principal (dans le Git du client)

Voici ce que cela implique :

• clone (ou pull du client principal repo et assurez-vous qu’il n’y a pas de changements locaux
• Exécutez la commande suivante pour obtenir les dernières modifications des sous-modules :
  git submodule update --recursive --init --remote
• commit et push les mises à jour de la télécommande

Maintenant le client principal repo contient toutes les dernières modifications des sous-modules.
Ce processus peut être automatisé avec un pipeline CI/CD.

Avant le déploiement dans l’environnement AEMaaCS, les dernières mises à jour du client principal le dépôt dans le Git du client doit être synchronisé avec le dépôt correspondant client principal dépôt dans Git d’Adobe.

Synchronisation des mises à jour du dépôt principal dans le Git du client avec le dépôt correspondant dans Adobe Git

Les deux référentiels sont exactement identiques, le référentiel dans Adobe Git peut donc être configuré comme un miroir. Les changements ne se produiront que dans client principal dépôt dans le Git du client. Ce processus peut être automatisé avec un pipeline CI/CD.

Ajouter un nouveau locataire

Il est facile d’ajouter un nouveau locataire au projet principal. Les étapes sont les mêmes que lorsque les sous-modules Git initiaux ont été ajoutés au référentiel principal.

• Créez un référentiel pour le nouveau locataire. N’incluez aucun paramètre qui s’applique à l’ensemble de l’instance AEM, car ceux-ci doivent être discutés avec les développeurs des autres locataires et ajoutés au client-communs dépôt.
• clone (ou pull du client principal repo, assurez-vous qu’il n’y a pas de changements locaux
• Lorsque la nouvelle base de code du locataire est prête à être ajoutée, exécutez la commande suivante à partir du dossier de niveau supérieur dans le client principal projet:
  git submodule add <REPO_URL>
  où est l’URL du référentiel que vous souhaitez ajouter en tant que sous-module.
• Ouvrez le .gitmodules fichier et mettez à jour la branche du nouveau sous-module, si elle doit être différente de ce qui existait déjà.
• Exécutez la commande sync pour synchroniser les fichiers des sous-modules dans le client principal dépôt
  git submodule update --recursive --init --remote
• commit et push les mises à jour de la télécommande

Configurations du répartiteur

Le dernier élément du modèle multi-tenant réussi concerne les configurations du répartiteur. Chaque locataire doit définir son propre ferme et hôte virtuel et, à partir de là, des filtres spécifiques au locataire, des règles de cache, des en-têtes client et des règles de réécriture.

Conclure

Même si le modèle multi-locataire évoqué ci-dessus est l’un des plus basiques, il peut néanmoins s’avérer difficile à mettre en place. Même si, espérons-le, vous comprenez maintenant ce modèle et comment le configurer, des questions peuvent encore surgir au cours du processus.

Il existe de nombreux autres sujets connexes à explorer. Restez à l’écoute pour en savoir plus sur les pipelines de déploiement dans Cloud Manager, les détails de configuration du répartiteur et les pipelines CI/CD pour la synchronisation des référentiels.

Assurez-vous également de consulter cet article connexe : Stratégies de déploiement multi-locataires dans AEM avec Adobe Cloud Manager.