Adobe Cloud Manager facilite la création et les déploiements de code pour AEM as a Cloud Service. Des échecs peuvent se produire lors des étapes du processus de création, ce qui nécessite une action pour les résoudre. Ce guide décrit les échecs courants du déploiement et comment les aborder au mieux.
L’étape de validation permet simplement de s’assurer que les configurations Cloud Manager de base sont valides. Les échecs de validation courants sont les suivants :
La phase de test de création et d’unité exécute une version Maven (mvn clean package
) du projet extrait de la branche Git configurée du pipeline.
Les erreurs identifiées dans cette phase doivent être reproductibles en local pour la création du projet, à l’exception des suivantes :
pom.xml
. Notez que l’inclusion des référentiels Maven est déconseillée, car elle augmente les délais de création..sleep(..)
dans le code test.L’analyse du code effectue une analyse du code statique à l’aide d’un mélange de bonnes pratiques Java et spécifiques à AEM.
L’analyse du code entraîne un échec de génération si le code contient des vulnérabilités de sécurité critique. Il est possible de remplacer des violations moindres, mais il est recommandé de les corriger. Notez que l’analyse du code est imparfaite et peut entraîner des faux positifs.
Pour résoudre les problèmes d’analyse du code, téléchargez le rapport au format CSV fourni par Cloud Manager via le Détails du téléchargement et passez en revue les entrées.
Pour plus d’informations, voir AEM règles spécifiques, voir la documentation de Cloud Manager règles d’analyse de code spécifiques à AEM personnalisées.
L’image de version est chargée de combiner les artefacts de code créés à l’étape Test de création et d’unité avec la version AEM, afin de former un seul artefact déployable.
Bien que tous les problèmes de création et de compilation de code soient détectés lors des tests de création et d’unité, des problèmes de configuration ou de structure peuvent être identifiés lors de la tentative de combiner l’artefact de création personnalisé avec la version d’AEM.
Lorsque plusieurs configurations OSGi sont résolues via le mode d’exécution pour l’environnement d’AEM cible, l’étape de création d’image échoue avec l’erreur :
[ERROR] Unable to convert content-package [/tmp/packages/enduser.all-1.0-SNAPSHOT.zip]:
Configuration 'com.example.ExampleComponent' already defined in Feature Model 'com.example.groupId:example.all:slingosgifeature:xxxxx:X.X',
set the 'mergeConfigurations' flag to 'true' if you want to merge multiple configurations with same PID
filevault-package-maven-plugin
configuration défini sur <cloudManagerTarget>none</cloudManagerTarget>
.Les scripts repoinit définissent le contenu de base, les utilisateurs, les listes de contrôle d’accès, etc. Dans AEM as a Cloud Service, les scripts repoinit sont appliqués lors de la création de l’image. Toutefois, sur AEM quickstart local du SDK, ils sont appliqués lorsque la configuration d’usine repoinit OSGi est activée. Pour cette raison, les scripts Repoinit peuvent échouer discrètement (avec journalisation) sur le démarrage rapide local du SDK d’AEM, mais entraîner l’échec de l’étape de création d’image et l’arrêt du déploiement.
Les scripts repoinit définissent le contenu de base, les utilisateurs, les listes de contrôle d’accès, etc. Dans le démarrage rapide local du SDK AEM, les scripts repoinit sont appliqués lorsque la configuration d’usine OSGi repoinit est activée, ou en d’autres termes, une fois le référentiel principal et des modifications de contenu peuvent avoir été effectuées directement ou par le biais de modules de contenu. Dans AEM as a Cloud Service, les scripts repoinit sont appliqués pendant la création d’image à un référentiel qui ne contient pas nécessairement de contenu dont dépend le script repoinit.
Ce problème affecte uniquement les environnements hors production qui ne se mettent PAS automatiquement à jour vers la dernière version d’AEM.
AEM as a Cloud Service inclut automatiquement la dernière version des composants principaux dans chaque version d’AEM, ce qui signifie qu’une fois qu’un environnement as a Cloud Service est, automatiquement ou manuellement mis à jour, la dernière version des composants principaux y est déployée.
Est possible car l’étape de création d’image échoue lorsque :
core
Projet (lot OSGi)Pour éviter cet échec, chaque fois qu’une mise à jour de l’environnement as a Cloud Service AEM est disponible, incluez la mise à jour dans le cadre du prochain build/déploiement et assurez-vous toujours que les mises à jour sont incluses après l’incrémentation de la version des composants principaux dans la base de code de l’application.
Symptômes :
L’étape Créer l’image échoue avec un rapport d’erreur indiquant que
com.adobe.cq.wcm.core.components...
Les modules situés dans des plages de versions spécifiques n’ont pas pu être importés par la variable core
projet.
[ERROR] Bundle com.example.core:0.0.3-SNAPSHOT is importing package(s) Package com.adobe.cq.wcm.core.components.models;version=[12.13,13) in start level 20 but no bundle is exporting these for that start level in the required version range.
[ERROR] Analyser detected errors on feature 'com.adobe.granite:aem-ethos-app-image:slingosgifeature:aem-runtime-application-publish-dev:1.0.0-SNAPSHOT'. See log output for error messages.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
Cause : Le lot OSGi de l’application (défini dans la variable core
projet) importe les classes Java de la dépendance Core Components, à un niveau de version différent de celui du déploiement sur AEM as a Cloud Service.
Résolution:
Si les solutions de dépannage ci-dessus ne résolvent pas le problème, créez un cas d’assistance Adobe via :
Adobe Admin Console > Onglet Assistance > Créer un cas
Si vous êtes membre de plusieurs organisations d’Adobe, assurez-vous que l’organisation d’Adobe dont le pipeline échoue est sélectionnée dans le sélecteur d’organisations d’Adobe avant de créer le cas.
L’étape Déployer sur est chargée de prendre l’artefact de code généré dans Build Image (Créer l’image), de démarrer de nouveaux services AEM Author et Publish à l’aide de celui-ci et, en cas de succès, de supprimer les anciens services AEM Author et Publish. Les modules de contenu modifiable et les index sont également installés et mis à jour au cours de cette étape.
Familiarisez-vous avec AEM journaux as a Cloud Service avant de déboguer l’étape Déployer sur . Le aemerror
Le journal contient des informations sur le démarrage et l’arrêt des capsules qui peuvent être pertinentes pour le déploiement sur les problèmes. Notez que le journal disponible via le bouton Télécharger le journal de l’étape Déployer vers de Cloud Manager n’est pas la aemerror
et ne contient pas d’informations détaillées relatives au démarrage de vos applications.
Les trois Principales raisons pour lesquelles l’étape Déployer sur peut échouer :
Le code qui s’exécute au démarrage du service d’AEM récemment déployé prend tellement de temps que Cloud Manager expire avant que le déploiement ne puisse se terminer. Dans ce cas, le déploiement peut réussir, même si l’état de Cloud Manager signalé comme ayant échoué.
aemerror
journaux des services AEM Author et Publish à l’heure de l’échec (heure du journal dans GMT), comme indiqué par Cloud Manager, et recherchez les messages de journal indiquant les processus d’exécution de journal personnalisés.La plupart des violations de code et de configuration sont interceptées plus tôt dans la version. Il est toutefois possible que le code personnalisé ou la configuration soient incompatibles avec l’as a Cloud Service AEM et restent non détectés jusqu’à ce qu’il s’exécute dans le conteneur.
aemerror
journaux des services AEM Author et Publish à l’heure (heure de connexion au format GMT) de l’échec, comme indiqué par Cloud Manager.
/var
est modifiable contenant une variété de contenu d’exécution transitoire. Inclusion /var
dans des packages de contenu (par exemple ui.content
) déployées via Cloud Manager peut entraîner l’échec de l’étape Déploiement .
Ce problème est difficile à identifier, car il n’entraîne pas d’échec lors du déploiement initial, mais uniquement lors des déploiements suivants. Les symptômes visibles sont les suivants :
La validation de ce problème est la cause du comportement défaillant :
En déterminant qu’au moins un module de contenu fait partie du déploiement, écrit sur /var
.
Vérifiez que la Principale file d’attente de distribution (en gras) est bloquée à l’adresse :
Auteur AEM > Outils > Déploiement > Distribution
En cas d’échec du déploiement suivant, téléchargez les journaux "Déployer sur" de Cloud Manager à l’aide du bouton Télécharger le journal :
… et vérifiez qu’il y a environ 60 minutes entre les instructions du journal :
2020-01-01T01:01:02+0000 Begin deployment in aem-program-x-env-y-dev [CorrelationId: 1234]
… et …
2020-01-01T02:04:10+0000 Failed deployment in aem-program-x-env-y-dev
Notez que ce journal ne contiendra pas ces indicateurs sur les déploiements initiaux qui signalent une réussite, plutôt que uniquement sur les déploiements en échec suivants.
/var
sur AEM Publish. Cela entraîne l’échec du déploiement du module de contenu sur le service AEM Publish./var
Les ressources ne sont pas nécessaires pour supprimer les ressources sous /var
des modules de contenu déployés dans le cadre de votre application./var
les ressources sont nécessaires, définissez les structures de noeud à l’aide de repoinit. Les scripts repoinit peuvent être ciblés sur AEM Author, AEM Publish ou les deux, via les modes d’exécution OSGi./var
Les ressources ne sont requises que sur AEM auteur et ne peuvent pas être modélisées raisonnablement à l’aide de repoinit, déplacez-les vers un module de contenu distinct, qui n’est installé que sur l’auteur AEM par incorporation dans le all
module dans un dossier du mode d’exécution Auteur AEM (<target>/apps/example-packages/content/install.author</target>
).sling-distribution-importer
utilisateur du service, comme décrit dans cette section Adobe KB.Si les solutions de dépannage ci-dessus ne résolvent pas le problème, créez un cas d’assistance Adobe via :
Adobe Admin Console > Onglet Assistance > Créer un cas
Si vous êtes membre de plusieurs organisations d’Adobe, assurez-vous que l’organisation d’Adobe dont le pipeline échoue est sélectionnée dans le sélecteur d’organisations d’Adobe avant de créer le cas.