Häufig gestellte Fragen zu Cloud Manager

Dieses Dokument enthält Antworten auf die am häufigsten gestellten Fragen zu Cloud Manager in AEM as a Cloud Service.

Kann Java 11 mit Cloud Manager-Builds verwendet werden?

Ja. Sie müssen das maven-toolchains-plugin mit den richtigen Einstellungen für Java 11 hinzufügen.

Der Prozess wird hier dokumentiert.

Ein Beispiel finden Sie unter WKND-Beispielprojekt-Code.

Mein Build schlägt nach dem Wechsel von Java 8 zu Java 11 mit einer Fehlermeldung über das maven-scr-plugin fehl. Was kann ich tun?

Ihr AEM Cloud Manager-Build schlägt fehl beim Versuch, den Build von Java 8 auf 11 umzuschalten. Wenn der unten stehende folgen Fehler auftritt, müssen Sie das maven-scr-plugin entfernen und alle OSGi-Anmerkungen in OSGi R6-Anmerkungen konvertieren.

[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]

Anweisungen zum Entfernen dieses Plug-ins finden Sie hier.

Mein Build schlägt nach dem Wechsel von Java 8 zu Java 11 mit einem Fehler bezüglich RequireJavaVersion fehl. Was kann ich tun?

Bei Cloud Manager-Builds kann das maven-enforcer-plugin mit diesem Fehler fehlschlagen.

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

Dies ist ein bekanntes Problem, da Cloud Manager eine andere Version von Java verwendet, um den maven-Befehl auszuführen, anstatt Code zu kompilieren. Lassen Sie einfach requireJavaVersion in den Konfigurationen Ihres maven-enforcer-plugin weg.

Die Code-Qualitätsprüfung ist fehlgeschlagen und unsere Implementierung ist blockiert. Gibt es eine Möglichkeit, diese Überprüfung zu umgehen?

Ja. Alle Fehler bei der Überprüfung der Code-Qualität mit Ausnahme der Sicherheitseinstufung sind nicht kritische Metriken, sodass sie als Teil einer Implementierungs-Pipeline übersprungen werden können, indem die Elemente in der Ergebnis-Benutzeroberfläche erweitert werden.

Benutzende mit der Rolle Implementierungs-Manager, Projekt-Manager oder Geschäftsinhaber können die Fehler außer Kraft setzen. In diesem Fall wird die Pipeline fortgesetzt. Sie können die Fehler aber auch akzeptieren. In diesem Fall stoppt die Pipeline mit einem Fehler.

Weitere Informationen finden Sie in den Dokumenten Testen der Code-Qualität und Konfigurieren von Nicht-Produktions-Pipelines.

Kann ich SNAPSHOT für die Version des Maven-Projekts verwenden?

Ja. Bei Entwicklerbereitstellungen müssen die pom.xml-Dateien der Git-Verzweigung am Ende des <version>-Werts -SNAPSHOT enthalten.

Dadurch kann die nachfolgende Bereitstellung weiterhin installiert werden, wenn sich die Version nicht geändert hat. In Entwicklerbereitstellungen wird keine automatische Version für den Maven-Build hinzugefügt oder generiert.

Sie können die Version für Staging- und Produktions-Builds oder -Implementierungen auch auf -SNAPSHOT setzen. Cloud Manager legt automatisch eine geeignete Versionsnummer fest und erstellt für Sie in Git ein Tag. Falls erforderlich, kann auf dieses Tag später verwiesen werden.

Weitere Informationen zur Versionsverwaltung sind hier dokumentiert.

Wie funktioniert die Paket-Versionierung für Staging- und Produktionsimplementierungen?

Bei der Staging- und Produktionsimplementierung wird wie hier dokumentiert eine automatische Version erzeugt.

Legen Sie für die benutzerdefinierte Versionierung in Staging- und Produktionsimplementierungen eine geeignete dreiteilige Maven-Version wie 1.0.0 fest. Erhöhen Sie die Version jedes Mal, wenn Sie sie in der Produktion bereitstellen.

Cloud Manager fügt Staging- und Produktions-Builds automatisch eine eigene Version hinzu und erstellt sogar eine Git-Verzweigung. Es ist keine spezielle Konfiguration notwendig. Wenn Sie keine Maven-Version wie zuvor beschrieben festlegen, ist die Implementierung trotzdem erfolgreich und eine Version wird automatisch festgelegt.

Mein Maven-Build schlägt bei Cloud Manager-Implementierungen fehl, lokal wird er jedoch ohne Fehler erstellt. Was läuft da schief?

Weitere Informationen dazu finden Sie in dieser Git-Ressource.

Was ist zu tun, wenn die Implementierung von Cloud Manager beim Bereitstellungsschritt in der AEM as a Cloud Service-Umgebung fehlschlägt?

Der häufigste Grund für fehlgeschlagene Implementierungen liegt in unzureichenden Berechtigungen für den sling-distribution-importer-Benutzer. In diesem Fall schlägt der Bereitstellungsschritt während einer Cloud Manager-Implementierung fehl und es werden Fehler wie die folgenden erzeugt.

[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.

Der sling-distribution-importer-Benutzer benötigt zusätzliche Berechtigungen für die im ui.content package definierten Inhaltspfade. Das bedeutet in der Regel, dass wir sowohl für /conf als auch für /var Berechtigungen hinzufügen müssen.

Die Lösung besteht darin, Ihrem Programm-Implementierungspaket ein RepositoryInitializer OSGi-Konfigurations-Skript hinzuzufügen, um ACLs für die sling-distribution-importer-Benutzerinnen und -Benutzer hinzuzufügen.

Im obigen Beispielfehler enthält das Paket myapp-base.ui.content-*.zip Inhalte unter /conf und /var/workflow. Damit die Implementierung erfolgreich ist, werden Berechtigungen für den sling-distribution-importer unter diesen Pfaden benötigt.

Hier ist ein Beispiel für eine org.apache.sling.jcr.repoinit.RepositoryInitializer-DistributionService.config-OSGi-Konfiguration, die zusätzliche Berechtigungen für sling-distribution-importer-Benutzerinnen und -Benutzer hinzufügt. Die Konfiguration fügt Berechtigungen unter /var hinzu. Eine solche Konfiguration muss dem Anwendungspaket unter /apps/myapp/config hinzugefügt werden (wobei myapp der Ordner ist, in dem Ihr Anwendungscode gespeichert ist).

Meine Cloud Manager-Implementierung schlägt beim Bereitstellungsschritt in AEM as a Cloud Service fehl und ich habe bereits eine OSGi-Konfiguration für RepositoryInitializer hinzugefügt. Was kann ich sonst noch tun?

Wenn das Hinzufügen einer OSGi-Konfiguration für RepositoryInitializer den Fehler nicht behoben hat, kann dies auf eines dieser zusätzlichen Probleme zurückzuführen sein.

  • Die Implementierung schlägt möglicherweise aufgrund einer fehlerhaften OSGi-Konfiguration fehl, die einen vorkonfigurierten Service beschädigt.

    • Überprüfen Sie die Protokolle während der Implementierung, um festzustellen, ob offensichtliche Fehler vorliegen.

  • Die Implementierung kann aufgrund falscher Dispatcher- oder Apache-Konfigurationen fehlschlagen.

    • Achten Sie darauf, Ihre Apache- und Dispatcher-Konfigurationen lokal mit dem im SDK enthaltenen Docker-Image zu testen.
    • Informationen zum Einrichten des Dispatcher-Docker-Containers für einfache lokale Tests finden Sie unter Dispatcher in der Cloud.

  • Die Implementierung könnte aufgrund eines anderen Fehlers während der Replikation der Inhaltspakete (Sling-Verteilung) vom den Autoren- zu den Veröffentlichungsinstanzen fehlschlagen.

    • Führen Sie diese Schritte aus, um das Problem bei einem lokalen Setup zu simulieren.
      1. Installieren Sie eine Autoren- und eine Publishig-Instanz (unter Verwendung der neuesten AEM SDK-jars).
      2. Melden Sie sich bei der Autoreninstanz an.
      3. Gehen Sie zu Tools > Implementierung > Verteilung.
      4. Verteilen Sie die Inhaltspakete, die Teil der Code-Basis sind, und überprüfen Sie, ob die Warteschlange mit einem Fehler blockiert wird.

Ich kann eine Variable nicht mit einem aio-Befehl festlegen. Was kann ich tun?

Wenn Sie versuchen, Pipeline-Variablen über aio-Befehle aufzulisten oder zu setzen, erhalten Sie möglicherweise einen 403-Fehler wie den folgenden.

$ 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)

In diesem Fall muss der Benutzer, der diese Befehle ausführt, in der Admin Console zur Rolle des Implementierungs-Managers hinzugefügt werden.

Weitere Informationen finden Sie unter API-Berechtigungen.

Auf dieser Seite