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.

Ist die Verwendung von Java™ 11 mit Cloud Manager-Builds möglich?

Ja. Fügen Sie die maven-toolchains-plugin mit den richtigen Einstellungen für Java™ 11.

Der Prozess wird hier dokumentiert.

Ein Beispiel finden Sie unter WKND-Beispielprojekt-Code.

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

Ihr AEM Cloud Manager-Build schlägt möglicherweise fehl, wenn versucht wird, den Build von Java™ 8 auf 11 zu wechseln. Wenn der folgende Fehler auftritt, müssen Sie maven-scr-plugin und konvertieren Sie alle OSGi-Anmerkungen in OSGi R6-Anmerkungen.

[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 mit einem Fehler bezüglich RequireJavaVersion nach dem Wechsel von Java™ 8 zu Java™ 11 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".

Dieser Fehler ist ein bekanntes Problem, da Cloud Manager eine andere Version von Java™ verwendet, um den Maven-Befehl im Vergleich zum Kompilierungscode auszuführen. Lassen Sie einfach requireJavaVersion in den Konfigurationen Ihres maven-enforcer-plugin weg.

Die Code-Qualitätsprüfung ist fehlgeschlagen und die 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 Bereitstellungs-Pipeline übersprungen werden können, indem die Elemente in der Ergebnis-Benutzeroberfläche erweitert werden.

Benutzer mit der Rolle Bereitstellungs-Manager, Projekt-Manager oder Geschäftsinhaber können die Probleme außer Kraft setzen. In diesem Fall wird die Pipeline fortgesetzt. Sie können die Probleme 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.

Mit diesem Wert 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 -Bereitstellungen auch auf -SNAPSHOT setzen. Cloud Manager legt automatisch eine geeignete Versionsnummer fest und erstellt für Sie in Git ein Tag. Auf dieses Tag kann bei Bedarf später verwiesen werden.

Weitere Informationen zur Versionsverwaltung finden Sie hier dokumentiert.

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

In Staging- und Produktionsimplementierungen wird eine automatische Version wie hier dokumentiert.

Für die benutzerdefinierte Versionierung in Staging- und Produktionsbereitstellungen legen Sie eine korrekte 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 Bereitstellung weiterhin erfolgreich und eine Version wird automatisch festgelegt.

Mein Maven-Build schlägt bei Cloud Manager-Bereitstellungen 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 Bereitstellungen 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. Diese Regel bedeutet normalerweise, dass Berechtigungen für beide /conf und /var.

Die Lösung besteht darin, Ihrem Programm-Bereitstellungspaket 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 Bereitstellung erfolgreich ist, müssen Berechtigungen für die 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 Bereitstellung 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, damit Sie sehen können, ob offensichtliche Fehler vorliegen.

  • Die Bereitstellung kann aufgrund fehlerhafter Dispatcher- oder Apache-Konfigurationen fehlschlagen.

    • Stellen Sie sicher, dass Sie Ihre Apache- und Dispatcher-Konfigurationen lokal mit dem im SDK enthaltenen Docker-Bild testen.
    • Siehe Dispatcher in der Cloud Informationen zum Einrichten des Dispatcher Docker-Containers für einfache lokale Tests.

  • Die Bereitstellung 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, damit Sie das Problem bei einem lokalen Setup simulieren können.
      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 > Bereitstellung > 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?

Sie können eine 403 Fehler wie der folgende, wenn versucht wird, Pipeline-Variablen über aio Befehle.

$ 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, zum Bereitstellungsmanager Rolle in der Admin Console.

Weitere Informationen finden Sie unter API-Berechtigungen.

Auf dieser Seite