Show Menu
SUJETS×

Recherche et indexation de contenu

Changements de l’AEM en tant que Cloud Service

Avec l’AEM en tant que Cloud Service, l’Adobe s’éloigne d’un modèle centré sur les instances AEM pour passer à une vue basée sur les services avec des Conteneurs n-x, pilotés par des pipelines CI/CD dans Cloud Manager. Au lieu de configurer et de gérer les index sur des instances d'AEM uniques, la configuration d'index doit être spécifiée avant un déploiement. Les changements de configuration dans la production enfreignent clairement les politiques de CI/CD. Il en va de même pour les changements d'index, car ils peuvent avoir un impact sur la stabilité et les performances du système si elles ne sont pas spécifiées et réindexées avant leur mise en production.
Voici une liste des principaux changements par rapport à AEM version 6.5 et antérieure :
  1. Les utilisateurs n’auront plus accès au Gestionnaire d’index d’une seule instance AEM pour déboguer, configurer ou gérer l’indexation. Il n'est utilisé que pour le développement local et les déploiements sur site.
  2. Les utilisateurs ne changeront pas d’index sur une seule instance AEM et n’auront plus à s’inquiéter des vérifications de cohérence ou de la réindexation.
  3. En général, les changements d’index sont amorcés avant d’être mis en production afin de ne pas contourner les passerelles de qualité dans les pipelines CI/CD de Cloud Manager et de ne pas avoir d’incidence sur les IPC métier en production.
  4. Toutes les mesures connexes, y compris les performances de recherche en production, seront disponibles pour les clients au moment de l’exécution afin de fournir une vue holistique sur les sujets de recherche et d’indexation.
  5. Les clients pourront configurer des alertes en fonction de leurs besoins.
  6. Les SRE surveillent la santé du système 24 heures sur 24, 7 jours sur 7 et prendront les mesures nécessaires et le plus tôt possible.
  7. La configuration de l’index est modifiée par le biais de déploiements. Les modifications apportées à la définition de l’index sont configurées comme les autres modifications apportées au contenu.
  8. À un niveau élevé, AEM Cloud Service, avec l'introduction du modèle de déploiement Blue-Green, deux ensembles d'index existeront : l'un pour l'ancienne version (bleu), l'autre pour la nouvelle version (vert).
  9. Les clients peuvent déterminer si la tâche d’indexation est terminée sur la page de création de Cloud Manager et ils recevront une notification lorsque la nouvelle version sera prête à recevoir du trafic.
  10. Limites : actuellement, la gestion des index sur AEM en tant que Cloud Service n'est prise en charge que pour les index de type lucene.

Utilisation

La définition d'index peut comprendre les trois cas d'utilisation suivants :
  1. ajouter une nouvelle définition d'index client
  2. Mise à jour d’une définition d’index existante. Cela signifie en effet l’ajout d’une nouvelle version d’une définition d’index existante.
  3. Suppression d’un index existant redondant ou obsolète.
Pour les points 1 et 2 ci-dessus, vous devez créer une nouvelle définition d’index dans le cadre de votre base de code personnalisé dans le calendrier de publication de Cloud Manager correspondant. Pour plus d’informations, voir la documentation Déploiement sur AEM as a Cloud Service Déploiement sur AEM en tant que Cloud Service.

Préparation de la nouvelle définition d'index

Vous devez préparer un nouveau package de définition d'index qui contient la définition d'index réelle, en suivant ce modèle de dénomination :
<indexName>[-<productVersion>]-custom-<customVersion>
qui doit ensuite passer sous ui.apps/src/main/content/jcr_root la barre. Les dossiers de sous-racine ne sont pas pris en charge pour l'instant.
Le package de l'exemple ci-dessus est créé comme com.adobe.granite:new-index-content:zip:1.0.0-SNAPSHOT .

Déploiement des définitions d’index

Il existe un problème connu avec Jackrabbit Filevault Maven Package Plugin version 1.1.0 qui ne vous permet pas d'ajouter oak:index aux modules de <packageType>application</packageType> . Pour contourner ce problème, utilisez la version 1.0.4 .
Les définitions d’index sont désormais marquées comme personnalisées et avec version :
  • La définition d’index elle-même (par exemple /oak:index/ntBaseLucene-custom-1 )
Par conséquent, pour déployer un index, la définition de l’index ( /oak:index/definitionname ) doit être fournie via ui.apps Git et le processus de déploiement de Cloud Manager.
Une fois la nouvelle définition d’index ajoutée, la nouvelle application doit être déployée via Cloud Manager. Au moment du déploiement, deux tâches sont démarrées, chargées d'ajouter (et de fusionner si nécessaire) les définitions d'index à MongoDB et Azure Segment Store pour l'auteur et la publication, respectivement. Les référentiels sous-jacents sont réindexés avec les nouvelles définitions d'index, avant que le commutateur Blue-Green n'ait lieu.
Pour plus de détails sur la structure de package requise pour AEM en tant que Cloud Service, voir la structure de projet de l' AEM document.

Gestion des index à l’aide de déploiements Blue-Green

Présentation de la gestion des index

La gestion des index consiste à ajouter, supprimer et modifier des index. La modification de la définition d'un index est rapide, mais l'application de la modification (souvent appelée "création d'un index", ou, pour les index existants, "réindexation") nécessite du temps. Elle n'est pas instantanée : le référentiel doit être analysé pour que les données soient indexées.

Qu'est-ce que le déploiement bleu-vert

Le déploiement Blue-Green peut réduire les temps d’inactivité. Il permet également des mises à niveau sans interruption de service et permet des remises en service rapides. L’ancienne version de l’application (bleue) s’exécute en même temps que la nouvelle version de l’application (verte).

Zones en lecture seule et en lecture-écriture

Certaines zones du référentiel (parties en lecture seule du référentiel) peuvent être différentes dans l'ancienne (bleue) et dans la nouvelle version (verte) de l'application. Les zones en lecture seule du référentiel sont généralement " /app " et " /libs ". Dans l’exemple suivant, l’italique est utilisé pour marquer les zones en lecture seule, tandis que l’gras est utilisé pour les zones en lecture-écriture.
  • /
  • /apps (lecture seule)
  • /content
  • /libs (lecture seule)
  • /oak:index
  • /oak:index/acme.
  • /jcr:system
  • /system
  • /var
Les zones de lecture-écriture du référentiel sont partagées entre toutes les versions de l'application, tandis que pour chaque version de l'application, il existe un ensemble spécifique de /apps et /libs .

Gestion des index sans déploiement bleu-vert

Lors du développement ou de l’utilisation sur site d’installations, les index peuvent être ajoutés, supprimés ou modifiés au moment de l’exécution. Les index sont utilisés dès qu'ils sont disponibles. Si un index n'est pas censé être utilisé dans l'ancienne version de l'application, il est généralement créé lors d'un arrêt planifié. Il en va de même lors de la suppression d'un index ou de la modification d'un index existant. Lors de la suppression d’un index, il devient indisponible dès sa suppression.

Gestion des index avec déploiement bleu-vert

Avec des déploiements bleu-vert, il n'y a pas de temps d'arrêt. Toutefois, pour la gestion des index, cela nécessite que les index ne soient utilisés que par certaines versions de l’application. Par exemple, lorsque vous ajoutez un index dans la version 2 de l’application, vous ne souhaitez pas qu’il soit encore utilisé par la version 1 de l’application. L’inverse est le cas lorsqu’un index est supprimé : un index supprimé dans la version 2 est toujours nécessaire dans la version 1. Lors de la modification d'une définition d'index, nous voulons que l'ancienne version de l'index soit utilisée uniquement pour la version 1 et la nouvelle version de l'index uniquement pour la version 2.
Le tableau suivant présente 5 définitions d’index : index cqPageLucene est utilisé dans les deux versions alors que index damAssetLucene-custom-1 est utilisé uniquement dans la version 2.
<indexName>-custom-<customerVersionNumber> est nécessaire pour que AEM, en tant que Cloud Service, puisse marquer cela comme un remplacement pour un index existant.
Index
Index prêt à l'emploi
Utilisation dans la version 1
Utilisation dans la version 2
/oak:index/damAssetLucene
Oui
Oui
Non
/oak:index/damAssetLucene-custom-1
Oui (personnalisé)
Non
Oui
/oak:index/acme.product-custom-1
Non
Oui
Non
/oak:index/acme.product-custom-2
Non
Non
Oui
/oak:index/cqPageLucene
Oui
Oui
Oui
Le numéro de version est incrémenté chaque fois que l'index est modifié. Pour éviter que des noms d'index personnalisés ne entrent en collision avec des noms d'index du produit lui-même, les index personnalisés, ainsi que les modifications apportées aux index prêts à l'emploi, doivent se terminer par -custom-<number> .

Modifications apportées aux index prêts à l’emploi

Une fois que l’Adobe a modifié un index prêt à l’emploi tel que "damAssetLucene" ou "cqPageLucene", un nouvel index nommé damAssetLucene-2 ou cqPageLucene-2 est créé ou, si l’index a déjà été personnalisé, la définition d’index personnalisé est fusionnée avec les modifications de l’index prêt à l’emploi, comme illustré ci-dessous. La fusion des modifications se produit automatiquement. Cela signifie que vous n'avez rien à faire si un index prêt à l'emploi change. Cependant, il est possible de personnaliser à nouveau l’index ultérieurement.
Index
Index prêt à l'emploi
Utilisation dans la version 2
Utilisation dans la version 3
/oak:index/damAssetLucene-custom-1
Oui (personnalisé)
Oui
Non
/oak:index/damAssetLucene-2-custom-1
Oui (automatiquement fusionné à partir de damAssetLucene-custom-1 et damAssetLucene-2)
Non
Oui
/oak:index/cqPageLucene
Oui
Oui
Non
/oak:index/cqPageLucene-2
Oui
Non
Oui

Restrictions

Actuellement, la gestion des index n'est prise en charge que pour les index de type lucene .

Suppression d'un index

Si un index doit être supprimé dans une version ultérieure de l’application, vous pouvez définir un index vide (un index sans données à indexer), avec un nouveau nom. Par exemple, vous pouvez lui donner un nom /oak:index/acme.product-custom-3 . Cette opération remplace l’index /oak:index/acme.product-custom-2 . Une fois /oak:index/acme.product-custom-2 supprimé par le système, l'index vide /oak:index/acme.product-custom-3 peut également être supprimé.

ajouter un index

Pour ajouter un index nommé "/oak:index/acme.product-custom-1" à utiliser dans une nouvelle version de l’application et ultérieure, l’index doit être configuré comme suit :
acme.product-1-custom-1
Cette opération consiste à ajouter un identifiant personnalisé au nom de l’index, suivi d’un point ( . ). L’identifiant doit comporter entre 2 et 5 caractères.
Comme ci-dessus, cela permet de s’assurer que l’index n’est utilisé que par la nouvelle version de l’application.

Modification d’un index

Lorsqu’un index existant est modifié, un nouvel index doit être ajouté avec la définition d’index modifiée. Par exemple, considérez que l’index existant "/oak:index/acme.product-custom-1" a été modifié. L'ancien index est stocké sous /oak:index/acme.product-custom-1 et le nouvel index sous /oak:index/acme.product-custom-2 .
L’ancienne version de l’application utilise la configuration suivante :
/oak:index/acme.product-custom-1
La nouvelle version de l’application utilise la configuration suivante (modifiée) :
/oak:index/acme.product-custom-2

Disponibilité de l'index/Tolérance aux pannes

Il est recommandé de créer des index de duplicata pour les fonctions extrêmement importantes (en gardant à l'esprit la convention d'attribution de noms pour les index mentionnés ci-dessus), de sorte que dans le cas de corruption d'index ou de tout événement imprévu de ce type, un index de secours est disponible pour répondre aux requêtes.