Questions fréquentes sur Cloud Manager cloud-manager-faqs

Ce document répond aux questions les plus fréquentes sur Cloud Manager dans AEM as a Cloud Service.

Est-il possible d’utiliser Java™ 11 avec les versions de Cloud Manager ? java-11-cloud-manager

Oui. Ajoutez maven-toolchains-plugin avec les paramètres appropriés pour Java™ 11.

Le processus est documenté ici.

Par exemple, consultez l’exemple de code de projet wknd.

Ma version échoue et affiche une erreur concernant maven-scr-plugin, après le passage de Java™ 8 à Java™ 11. Que puis-je faire ? build-fails-maven-scr-plugin

Votre version d’AEM Cloud Manager peut échouer lorsque vous tentez de passer de Java™ 8 à 11. Si vous rencontrez l’erreur ci-dessous, vous devez supprimer maven-scr-plugin et convertir toutes les annotations OSGi en annotations OSGi R6.

[main] [ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.26.4:scr (generate-scr-scrdescriptor) on project helloworld.core: /build_root/build/testsite/src/main/java/com/adobe/HelloWorldServiceImpl.java : Unable to load compiled class: com.adobe.HelloWorldServiceImpl: com/adobe/HelloWorldServiceImpl has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 > [Help 1]

Pour plus d’informations sur la suppression de ce plug-in, rendez-vous ici.

Ma version échoue et affiche une erreur concernant RequireJavaVersion, après le passage de Java™ 8 à Java™ 11. Que puis-je faire ? build-fails-requirejavaversion

Pour les builds Cloud Manager, le maven-enforcer-plugin peut échouer avec cette erreur.

"[main] [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVersion".

Cette erreur est un problème connu dû au fait que Cloud Manager utilisait une version différente de Java™ pour exécuter la commande maven plutôt que de compiler le code. Omettez simplement requireJavaVersion de vos configurations maven-enforcer-plugin.

La vérification de la qualité du code a échoué et le déploiement est bloqué. Y a-t-il un moyen de contourner cette vérification ? deployment-stuck

Oui. Tous les échecs de vérification liés à la qualité du code, à l’exception de l’évaluation de la sécurité, ne sont pas des mesures critiques. Ils peuvent donc être contournés, dans le cadre d’un pipeline de déploiement, en développant les éléments dans l’interface utilisateur des résultats.

Un utilisateur ayant un rôle de responsable de déploiement, responsable de projet ou propriétaire d’entreprise peut, au choix, contourner les problèmes, auquel cas le pipeline continue, ou les accepter, auquel cas le pipeline s’arrête avec un échec.

Voir les documents Test de qualité du code et Configurer des pipelines hors production pour plus d’informations.

Puis-je utiliser SNAPSHOT pour la version du projet Maven ? use-snapshot

Oui. Pour les déploiements de développeurs, les fichiers pom.xml de la branche Git doivent contenir -SNAPSHOT à la fin de la valeur <version>.

Cette valeur permet de conserver les déploiements ultérieurs alors que la version n’a pas été modifiée. Pour les déploiements de développeurs, aucune version automatique n’est ajoutée ou générée pour la build maven.

Vous pouvez également définir la version sur -SNAPSHOT pour les builds ou déploiements d’évaluation et de production. Cloud Manager définit automatiquement un numéro de version approprié et crée pour vous une balise dans git. Cette balise peut être référencée ultérieurement, le cas échéant.

De plus amples détails sur la gestion des versions sont documentés ici.

Comment le contrôle de version des packages et des lots fonctionne-t-il pour les déploiements d’évaluation et de production ? snapshot-version

En cas de déploiement d’évaluation et de production, une version automatique est générée comme indiqué ici.

Pour le contrôle de version personnalisé dans les déploiements d’évaluation et de production, définissez une version maven en trois parties, telle que 1.0.0. Passez à la version supérieure à chaque déploiement en production.

Cloud Manager ajoute automatiquement sa version aux builds d’évaluation et de production et crée même une branche Git. Aucune configuration spécifique n’est nécessaire. Si vous ne définissez pas de version Maven comme décrit précédemment, le déploiement s’effectue quand même et une version est automatiquement définie.

Ma build Maven échoue lors des déploiements de Cloud Manager, mais elle est pourtant créée localement sans la moindre erreur. Qu’est-ce qui ne va pas ? maven-build-fail

Consultez cette ressource git pour plus d’informations.

Que faire si le déploiement de Cloud Manager échoue lors de l’étape de déploiement dans AEM as a Cloud Service ? cloud-manager-deployment-cloud-service

La raison la plus courante de l’échec des déploiements résulte d’autorisations insuffisantes pour l’utilisateur sling-distribution-importer. Dans ce cas, l’étape de déploiement échoue lors d’un déploiement de Cloud Manager et des erreurs telles que les suivantes sont générées.

[Queue Processor for Subscriber agent forwardPublisherSubscriber] org.apache.jackrabbit.vault.fs.io.Importer Error while committing changes. Retrying import from checkpoint at /. Retries 4/10
[Queue Processor for Subscriber agent forwardPublisherSubscriber] org.apache.sling.distribution.journal.impl.subscriber DistributionSubscriber Error processing queue item
org.apache.sling.distribution.common.DistributionException: Error processing distribution package
dstrpck-1583514457813-c81e7751-2da6-4d00-9814-434187f08d32. Retry attempts 162/infinite.
Caused by: org.apache.sling.api.resource.PersistenceException: Unable to commit changes to session.
Caused by: javax.jcr.AccessDeniedException: OakAccess0000: Access denied [EventAdminAsyncThread #7] org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher [null] Error processing distribution package` `dstrpck-1583514457813-c81e7751-2da6-4d00-9814-434187f08d32. Retry attempts 344/infinite. Message: Error trying to extract package at path /etc/packages/com.myapp/myapp-base.ui.content-5.1.0-SNAPSHOT.

L’utilisateur ou l’utilisatrice sling-distribution-importer a besoin d’autorisations supplémentaires pour les chemins de contenu définis dans ui.content package. Cette règle signifie généralement qu’il faut ajouter des autorisations pour /conf et /var.

La solution consiste à ajouter un script de configuration RepositoryInitializer OSGi à votre package de déploiement d’applications afin d’ajouter des listes de contrôle d’accès pour l’utilisateur sling-distribution-importer.

Dans l’exemple d’erreur précédent, le package myapp-base.ui.content-*.zip inclut le contenu situé sous /conf et /var/workflow. Pour que le déploiement réussisse, les autorisations pour sling-distribution-importer sous ces chemins d’accès sont nécessaires.

Voici un exemple org.apache.sling.jcr.repoinit.RepositoryInitializer-DistributionService.config de configuration OSGi qui permet d’ajouter des autorisations supplémentaires pour l’utilisateur ou l’utilisatrice sling-distribution-importer. Cette configuration ajoute des autorisations sous /var. Une telle configuration doit être ajoutée au package d’application sous /apps/myapp/config (où myapp est le dossier dans lequel le code de votre application est stocké).

Mon déploiement de Cloud Manager échoue à l’étape de déploiement dans AEM as a Cloud Service et j’ai déjà ajouté une configuration OSGi RepositoryInitializer. Que puis-je faire d’autre ? build-failures

Si l’ajout d’une configuration OSGi RepositoryInitializer n’a pas résolu l’erreur, elle peut être due à l’un des autres problèmes suivants.

  • Le déploiement peut échouer en raison d’une configuration OSGi incorrecte qui rompt un service prêt à l’emploi.

    • Vérifiez les journaux pendant le déploiement pour voir s’il existe des erreurs évidentes.
  • Le déploiement peut échouer en raison de configurations incorrectes du Dispatcher ou d’Apache.

    • Veillez à tester Apache et le Dispatcher localement à l’aide de l’image Docker incluse dans le SDK.
    • Voir la section Dispatcher en mode cloud pour savoir comment configurer le conteneur Docker du Dispatcher pour des tests locaux faciles.
  • Le déploiement peut échouer en raison d’une autre défaillance lors de la réplication des packages de contenu (distribution Sling) entre les instances de création et de publication.

    • Suivez ces étapes pour simuler le problème sur une configuration locale.

      1. Installer une instance de création et de publication locale à l’aide des derniers fichiers jar du SDK AEM.
      2. Connectez-vous à l’instance de création.
      3. Accédez à Outils -> Déploiement -> Distribution.
      4. Distribuez les packages de contenu faisant partie de la base de code et vérifiez si la file d’attente est bloquée avec une erreur.

Je ne parviens pas à définir une variable à l’aide d’une commande aio. Que puis-je faire ? set-variable

Il se peut que vous receviez une erreur 403 de ce type lorsque vous tentez de répertorier ou de définir les variables de pipeline à l’aide de commandes aio.

$ aio cloudmanager:list-pipeline-variables 222

Cannot get variables: https://cloudmanager.adobe.io/api/program/111/pipeline/222/variables (403 Forbidden)

$ aio cloudmanager:set-pipeline-variables 222 --variable TEST 1

Cannot get variables: https://cloudmanager.adobe.io/api/program/111/pipeline/222/variables (403 Forbidden)

$ aio cloudmanager:set-environment-variables 1755 --variable TEST 1

setting variables... !

Cannot set variables: https://cloudmanager.adobe.io/api/program/111/environment/222/variables (403 Forbidden)

Dans ce cas, la personne exécutant ces commandes doit être ajoutée au rôle Responsable de déploiement dans Admin Console.

Consultez Autorisations d’API pour plus d’informations.

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