Häufig gestellte Fragen zu Cloud Manager cloud-manager-faqs

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? java-11-cloud-manager

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

Der Prozess wird dokumentiert. Siehe Assistent zur Projekterstellung.

Ein Beispiel finden Sie unter WKND-Beispielprojekt-Code.

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

Ihr AEM Cloud Manager-Build schlägt möglicherweise fehl, wenn versucht wird, den Build von Java™ 8 auf 11 umzuschalten. Wenn der unten stehende 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 unter Von SCR-Anmerkungen zu OSGi-Anmerkungen.

Nach dem Wechsel von Java™ 8 zu Java™ 11 schlägt mein Build mit einer Fehlermeldung über RequireJavaVersion fehl. Was kann ich tun? build-fails-requirejavaversion

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 Java™-Version verwendet, um den Maven-Befehl auszuführen, anstatt Code zu kompilieren. Lassen Sie requireJavaVersion in Ihren maven-enforcer-plugin-Konfigurationen weg.

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

Ja. Alle Fehler bei der Überprüfung der Code-Qualität mit Ausnahme der Sicherheitseinstufung sind nicht kritische Metriken. Daher können sie im Rahmen einer Bereitstellungs-Pipeline umgangen werden, indem die Elemente in der Ergebnis-Benutzeroberfläche erweitert werden.

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

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

Dieser Wert ermöglicht die Installation einer nachfolgenden Bereitstellung, selbst wenn die Version unverändert blieb. 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. Falls erforderlich, kann auf dieses Tag später verwiesen werden.

Weitere Informationen zur Versionsverwaltung finden Sie unter Umgang mit Maven-Projektversionen.

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

Bei Staging- und Produktionsbereitstellungen wird eine automatische Version generiert. Siehe Umgang mit Maven-.

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 festlegen, ist die Bereitstellung dennoch 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 ist die Ursache? maven-build-fail

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? cloud-manager-deployment-cloud-service

Der häufigste Grund für fehlgeschlagene Bereitstellungen sind unzureichende 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.

Benutzerinnen und Benutzer von sling-distribution-importer benötigen zusätzliche Berechtigungen für die im ui.content package definierten Inhaltspfade. Diese Konfiguration erfordert in der Regel das Hinzufügen von Berechtigungen für /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, sind Berechtigungen für die sling-distribution-importer unter diesen Pfaden erforderlich.

Hier ist ein Beispiel für eine org.apache.sling.jcr.repoinit.RepositoryInitializer-DistributionService.config-OSGi-Konfiguration, die zusätzliche Berechtigungen für Benutzerinnen und Benutzer von sling-distribution-importer 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? build-failures

Wenn Hinzufügen einer OSGi-Konfiguration für RepositoryInitializer den Fehler nicht behoben hat, kann dies auf eines der folgenden Probleme zurückzuführen sein:

  • Die Bereitstellung schlägt aufgrund einer ungültigen OSGi-Konfiguration fehl, die einen Standard-Service unterbricht.

    • Überprüfen Sie die Protokolle während der Bereitstellung, um festzustellen, ob offensichtliche Fehler vorliegen.
  • Die Bereitstellung schlägt aufgrund ungültiger Dispatcher- oder Apache-Konfigurationen fehl.

    • Achten Sie darauf, Ihre Apache- und Dispatcher-Konfigurationen lokal mit dem im SDK enthaltenen Docker-Image zu testen.
    • Unter Dispatcher in der Cloud finden Sie Informationen zum Einrichten des Dispatcher-Docker-Containers für einfache lokale Tests.
  • Die Bereitstellung schlägt aufgrund eines anderen Fehlers während der Replikation der Inhaltspakete (Sling-Verteilung) von der Autoren- zu der Veröffentlichungsinstanz fehl.

    • Führen Sie diese Schritte aus, um das Problem bei einem lokalen Setup zu simulieren.

      1. Installieren Sie eine Autoren- und eine Veröffentlichungsinstanz lokal mit den 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? set-variable

Wenn Sie versuchen, Pipeline-Variablen mithilfe von aio-Befehlen aufzulisten oder festzulegen, erhalten Sie 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 müssen die Personen, die diese Befehle ausführen, in der Admin Console zur Rolle der Bereitstellungs-Manager hinzugefügt werden.

Weitere Informationen finden Sie unter API-Berechtigungen.

recommendation-more-help
experience-manager-cloud-service-help-main-toc