Bereitstellen für AEM as a Cloud Service deploying-to-aem-as-a-cloud-service

Einführung introduction

Die Grundlagen der Code-Entwicklung in AEM as a Cloud Service ähneln denen von AEM On-Premise- und Managed Services-Lösungen. Entwicklerinnen und Entwickler schreiben Code und testen ihn lokal, bevor sie ihn an Remote-Umgebungen auf AEM as a Cloud Service pushen. Dafür wird Cloud Manager benötigt, das ein optionales Tool zur Inhaltsbereitstellung für Managed Services war. Dieses Bereitstellungs-Tool ist nun das einzige Verfahren für die Bereitstellung von Code in Entwicklungs-, Staging- und Produktionsumgebungen von AEM as a Cloud Service. Zur schnellen Funktionsüberprüfung und zum Debugging vor der Bereitstellung der oben genannten Umgebungen kann der Code von einer lokalen Umgebung mit einer schnellen Entwicklungsumgebung synchronisiert werden.

Die Aktualisierung der AEM-Version ist stets ein separates Bereitstellungsereignis, das nicht mit dem Pushen von anwenderspezifischem Code verbunden ist. Anders gesagt: Bei Freigabe von anwenderspezifischem Code sollte mit jener AEM-Version getestet werden, die sich der Produktion befindet, da der Code auf dieser Version bereitgestellt wird. Aktualisierungen der AEM-Version, die danach erfolgen (die häufig erfolgen und automatisch angewendet werden), sollen mit dem bereits bereitgestellten Kunden-Code abwärtskompatibel sein.

In diesem Dokument wird beschrieben, wie Entwicklerinnen und Entwickler ihr Vorgehen anpassen sollten, um sowohl mit Aktualisierungen der AEM as a Cloud Service-Version als auch mit benutzerspezifischen Aktualisierungen zu arbeiten.

Benutzerspezifische Versionen customer-releases

Kodierung mit der richtigen AEM-Version coding-against-the-right-aem-version

Bei früheren AEM-Lösungen änderte sich die aktuelle AEM-Version selten (etwa 1-mal jährlich mit vierteljährlichen Service Packs); Kunden aktualisierten die Produktionsinstanzen im eigenen Tempo auf den neuesten Schnellstart, indem sie auf das API-JAR verwiesen. Anwendungen auf AEM as a Cloud Service jedoch werden häufiger automatisch auf die neueste Version von AEM aktualisiert. Daher sollte anwenderspezifischer Code für interne Freigaben für die neueste AEM-Version erstellt werden.

Wie bei vorhandenen Nicht-Cloud-AEM-Versionen wird eine lokale Offline-Entwicklung unterstützt, die auf einem bestimmten Schnellstart basiert. In den meisten Fällen ist dies das bevorzugte Debugging-Tool.

Um benutzerdefinierten Code für eine interne Version zu entwickeln, sollte die entsprechende Version des AEM as a Cloud Service-SDK heruntergeladen und installiert werden. Weitere Informationen zur Verwendung der AEM as a Cloud Service-Dispatcher-Tools finden Sie unter Dispatcher in der Cloud.

Das folgende Video bietet einen Überblick über die Bereitstellung von Code für AEM as a Cloud Service:

Implementieren eines Inhaltspakets über Cloud Manager und Package Manager deploying-content-packages-via-cloud-manager-and-package-manager

Implementierungen über Cloud Manager deployments-via-cloud-manager

Kundinnen und Kunden können benutzerspezifischen Code in Cloud-Umgebungen über Cloud Manager bereitstellen. Cloud Manager wandelt lokal assemblierte Inhaltspakete nach dem Sling-Funktionsmodell in ein Artefakt um. So wird eine Anwendung auf AEM as a Cloud Service beschrieben, wenn sie in einer Cloud-Umgebung ausgeführt wird. Wenn Sie die Pakete in Package Manager für Cloud-Umgebungen betrachten, können Sie deswegen feststellen, dass der Name „cp2fm“ enthält und alle Metadaten der umgewandelten Pakete entfernt wurden. Mit ihnen kann nicht interagiert werden; d. h. sie lassen nicht herunterladen, replizieren oder öffnen. Eine ausführliche Dokumentation zum Konverter finden Sie untersling-org-apache-sling-feature-cpconverter auf GitHub.

Inhaltspakete, die für Anwendungen auf AEM as a Cloud Service geschrieben wurden, müssen eine saubere Trennung zwischen unveränderlichen und veränderlichen Inhalten aufweisen. Cloud Manager installiert nur die veränderlichen Inhalte und gibt außerdem eine Meldung wie die folgende aus:

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

Im Rest dieses Abschnitts werden die Komposition und die Implikationen unveränderlicher bzw. veränderlicher Pakete beschrieben.

Unveränderliche Inhaltspakete immutabe-content-packages

Sämtlicher Inhalt und Code, der im unveränderlichen Repository persistent ist, muss in Git eingecheckt und mit Cloud Manager bereitgestellt werden. Anders gesagt: Im Gegensatz zu aktuellen AEM-Lösungen wird Code niemals direkt in einer laufenden AEM-Instanz bereitgestellt. Durch diesen Workflow wird sichergestellt, dass der Code, der für eine bestimmte Version in beliebigen Cloud-Umgebungen ausgeführt wird, identisch ist. So wird das Risiko unbeabsichtigter Code-Varianten in der Produktion eliminiert. Beispiel: Die OSGi-Konfiguration sollte der Quell-Code-Verwaltung übergeben und nicht zur Laufzeit über den Konfigurations-Manager der AEM-Web-Konsole verwaltet werden.

Da Anwendungsänderungen aufgrund des Bereitstellungsmusters durch einen Umschalter aktiviert werden, dürfen sie nicht von Änderungen im veränderlichen Repository abhängig sein, mit Ausnahme von Dienstbenutzerinnen und -benutzern, ihren ACLs, Knotentypen und Änderungen der Indexdefinition.

Kundinnen und Kunden mit vorhandener Code-Basis müssen die in der AEM-Dokumentation beschriebene Repository-Umstrukturierung durchführen, um dafür zu sorgen, dass die zuvor unter „/etc“ befindlichen Inhalte an den richtigen Speicherort verschoben werden.

Für diese Code-Pakete gelten einige zusätzliche Einschränkungen, z. B. werden keine Installations-Hooks unterstützt.

OSGi-Konfiguration osgi-configuration

Wie bereits erwähnt, sollte die OSGi-Konfiguration an die Quell-Code-Verwaltung übermittelt werden und nicht über die Web-Konsole. Zu geeigneten Verfahren gehören:

Weitere Informationen zur OSGi-Konfiguration finden Sie unter Konfigurieren von OSGi für AEM as a Cloud Service.

Veränderlicher Inhalt mutable-content

Manchmal kann es nützlich sein, Inhaltsänderungen in der Quell-Code-Verwaltung vorzubereiten, damit sie von Cloud Manager bereitgestellt werden können, sobald eine Umgebung aktualisiert wird. Es kann beispielsweise sinnvoll sein, bestimmte Stammordnerstrukturen zu initialisieren. Sie können auch Änderungen in bearbeitbaren Vorlagen anordnen, um Richtlinienkomponenten zu aktivieren, die durch die Anwendungsbereitstellung aktualisiert wurden.

Es gibt zwei Strategien zur Beschreibung der Inhalte, die von Cloud Manager im veränderlichen Repository bereitgestellt werden: veränderliche Inhaltspakete und repoinit-Anweisungen.

Veränderliche Inhaltspakete mutable-content-packages

Inhalte wie Ordnerpfadhierarchien, Service-Benutzer und Zugangssteuerungen (ACLs) werden in der Regel in ein AEM-Projekt übertragen, das auf Maven-Archetypen basiert. Zu den Methoden gehören das Exportieren aus AEM oder das direkte Schreiben als XML. Bei der Erstellung und Bereitstellung packt Cloud Manager das resultierende veränderliche Inhaltspaket. Die veränderbaren Inhalte werden in der Bereitstellungsphase in der Pipeline zu drei verschiedenen Zeitpunkten installiert:

Vor dem Start der neuen Version des Programms:

Beim Start der neuen Version des Programms, aber vor der Umstellung:

Nach der Umstellung auf die neue Programmversion:

Die Installation veränderlicher Inhalte in Autoren- oder Veröffentlichungsinstanzen lässt sich einschränken, indem Sie Pakete unter /apps in einen „install.author“- oder „install.publish“-Ordner einbetten. Eine Umstrukturierung, die dieser Trennung Rechnung trägt, wurde in AEM 6.5 vorgenommen. Einzelheiten zur empfohlenen Projektumstrukturierung finden Sie in der Dokumentation zu AEM 6.5.

Außerdem gibt es kein Verfahren, um Änderungen durch veränderliche Inhaltspakete nach deren Anwendung zurückzunehmen. Wenn Kundinnen oder Kunden ein Problem entdecken, können sie es in ihrer nächsten Code-Version beheben oder – als letzte Möglichkeit – das ganze System auf einen Zeitpunkt vor der Bereitstellung zurücksetzen.

Für alle enthaltenen Pakete von Drittanbietern muss die Kompatibilität mit AEM as a Cloud Service validiert werden, andernfalls führt ihre Einbeziehung zu einem Bereitstellungsfehler.

Wie bereits erwähnt, sollten sich Kundinnen bzw. Kunden mit bestehender Code-Basis an die Umstrukturierung des Repositorys halten, die durch die in der AEM 6.5-Dokumentation beschriebenen Änderungen des 6.5-Repositorys erforderlich ist.

Repoinit repoinit

In folgenden Fällen ist es vorzuziehen, in den OSGi-Werkseinstellungen manuell explizite repoinit-Anweisungen für die Inhaltserstellung zu kodieren:

Aufgrund der folgenden Vorteile ist bei diesen Anwendungsfällen für die Inhaltsänderung bevorzugt „repoinit“ zu verwenden:

Wenn Cloud Manager das Programm bereitstellt, werden diese Anweisungen unabhängig von der Installation jeglicher Inhaltspakete ausgeführt.

Gehen Sie wie folgt vor, um weitere repoinit-Anweisungen zu erstellen:

Weitere Einzelheiten über repoinit finden Sie in der Sling-Dokumentation

Package Manager-„one-offs“ für Pakete mit veränderlichen Inhalten package-manager-oneoffs-for-mutable-content-packages

Es gibt Anwendungsfälle, in denen ein Inhaltspaket als „one off“ (einmalig) installiert werden sollte. Zum Beispiel beim Importieren bestimmter Inhalte aus der Produktions- in die Staging-Umgebung, um ein Problem in der Produktion zu debuggen. Für solche Szenarien kann Package Manager in Umgebungen mit AEM as a Cloud Service verwendet werden.

Da Package Manager auf einem Laufzeitkonzept basiert, ist es unmöglich, Inhalte oder Code im unveränderlichen Repository zu installieren. Daher dürfen diese Inhaltspakete nur aus veränderlichen Inhalten bestehen (hauptsächlich /content oder /conf). Wenn das Inhaltspaket gemischte Inhalte enthält, d. h. sowohl veränderliche als auch unveränderliche, werden nur die veränderlichen Inhalte installiert.

Sämtliche über Cloud Manager installierten Inhaltspakete (sowohl veränderliche als auch unveränderliche) werden in der Benutzeroberfläche von AEM Package Manager mit einem eingefrorenen Status angezeigt. Diese Pakete können nicht neu installiert, neu erstellt oder auch nur heruntergeladen werden. Sie werden mit dem Suffix cp2fm aufgeführt, was darauf hinweist, dass ihre Installation von Cloud Manager verwaltet wurde.

Einschließen von Drittanbieterpaketen including-third-party

Es kommt häufig vor, dass Kundinnen und Kunden vorgefertigte Pakete aus Drittanbieterquellen (zum Beispiel von Software-Anbietern wie Übersetzungspartnern von Adobe) einbeziehen. Es wird empfohlen, diese Pakete in einem Remote-Repository zu hosten und in pom.xml auf sie zu verweisen. Diese Methode ist für öffentliche Repositorys und auch für private Repositorys mit Kennwortschutz möglich, wie unter Unterstützung für kennwortgeschützte Maven-Repositorys beschrieben.

Wenn das Speichern des Pakets in einem Remote-Repository nicht möglich ist, können Kundinnen und Kunden es in einem lokalen, Dateisystem-basierten Maven-Repository platzieren, das im Rahmen des Projekts an SCM übermittelt wird. Es wird durch alles, was davon abhängig ist, referenziert. Das Repository wird in diesem Fall wie im nachfolgend dargestellten POM des Projekts deklariert:

<repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>

Alle enthaltenen Drittanbieter-Pakete müssen den in diesem Artikel beschriebenen Richtlinien zur Codierung und Verpackung für AEM as a Cloud Service entsprechen. Andernfalls entsteht ein Implementierungsfehler.

Das folgende Maven-Fragment POM.xml zeigt, wie Drittanbeiter-Pakete über die Maven-Plug-in-Konfiguration filevault-package-maven-plugin in das „Container“-Paket des Projekts, in der Regel „all“ genannt, eingebettet werden können.

...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <embeddeds>

          ...

          <!-- Include any other extra packages  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Funktionsweise von rollierenden Bereitstellungen how-rolling-deployments-work

Genauso wie AEM-Aktualisierungen werden benutzerspezifische Versionen mithilfe einer rollierenden Implementierungsstrategie bereitgestellt, um unter den richtigen Bedingungen Ausfallzeiten im Author-Cluster zu verhindern. Die allgemeine Ereignisabfolge, in der Knoten mit der alten und der neuen Version des Kunden-Codes dieselbe Version des AEM-Codes ausführen, wird unten beschrieben.

Indizes indexes

Neue oder geänderte Indizes verursachen einen zusätzlichen Indizierungs- oder Neuindizierungsschritt, bevor die neue Version den Traffic aufnehmen kann. Details zur Indexverwaltung in AEM as a Cloud Service finden Sie in unter Inhaltssuche und -indizierung.  Sie können den Indizierungsstatus von Build-Seiten in Cloud Manager überprüfen und eine Benachrichtigung erhalten, wenn die neue Version für Traffic bereit ist.

Derzeit funktioniert AEM as a Cloud Service nicht mit Indexverwaltungs-Tools wie dem ACS Commons Ensure Oak Index-Tool.

Replikation replication

Der Veröffentlichungsmechanismus ist rückwärtskompatibel mit den AEM Replication Java™-APIs.

Um mit Replikation und dem Cloud-fähigen AEM-Schnellstart entwickeln und testen zu können, müssen die klassischen Replikationsfunktionen in einem Author/Publish-Setup verwendet werden. Wenn der Einstiegspunkt der Benutzeroberfläche auf AEM Author für die Cloud entfernt wird, gehen die Benutzenden für die Konfiguration zu http://localhost:4502/etc/replication.

Rückwärtskompatibler Code für rollierende Bereitstellungen backwards-compatible-code-for-rolling-deployments

Wie oben erläutert, beinhaltet die kontinuierliche Bereitstellungsstrategie von AEM as a Cloud Service, dass sich sowohl die alten als auch die neuen Versionen gleichzeitig ausführen lassen. Seien Sie daher vorsichtig bei Code-Änderungen, die nicht rückwärtskompatibel mit der alten, weiter verwendeten AEM-Version sind.

Darüber hinaus sollte die alte Version auf Kompatibilität mit allen neuen Strukturen für veränderliche Inhalte getestet werden, die von der neuen Version angewendet werden, wenn ein Rollback stattfindet, da veränderliche Inhalte nicht entfernt werden.

Änderungen von Dienstbenutzenden und ACLs service-users-and-acl-changes

Das Ändern von Dienstbenutzenden oder ACLs, die auf Inhalte oder Code zugreifen, kann zu Fehlern in den älteren AEM-Versionen führen, die den Zugriff auf diese Inhalte oder den Code mit veralteten Dienstbenutzenden zur Folge haben. Um diesem Verhalten entgegenzuwirken, wird empfohlen, die Änderungen auf mindestens zwei Versionen zu verteilen, wobei die erste Version als Bindeglied fungiert, bevor in der folgenden Version bereinigt wird.

Indexänderungen index-changes

Wenn Änderungen an Indizes vorgenommen werden, muss die neue Version ihre Indizes bis zum Ende weiter verwenden, während die alte Version ihre eigenen, geänderten Indizes nutzt. Die Entwicklerinnen und Entwickler sollten die Indexverwaltungsmethoden befolgen, die unter Inhaltssuche und -indizierung beschrieben sind.

Konservative Codierung für Rollbacks conservative-coding-for-rollbacks

Wenn nach der Bereitstellung ein Fehler gemeldet oder erkannt wird, ist möglicherweise ein Rollback zur alten Version erforderlich. Stellen Sie sicher, dass der neue Code mit allen neuen Strukturen kompatibel ist, die von dieser neuen Version erstellt wurden, da die neuen Strukturen (alle veränderlichen Inhalte) nicht zurückgesetzt werden. Wenn der alte Code nicht kompatibel ist, müssen die Korrekturen in späteren Kundenversionen vorgenommen werden.

Schnelle Entwicklungsumgebung (RDE) rde

Schnelle Entwicklungsumgebungen (oder kurz: RDEs) ermöglichen es Entwicklerinnen und Entwicklern, Änderungen schnell bereitzustellen und zu überprüfen und so den Zeitaufwand für das Testen von Funktionen zu minimieren, die bereits nachweislich in einer lokalen Entwicklungsumgebung funktionieren.

Im Gegensatz zu normalen Entwicklungsumgebungen, die Code über die Cloud Manager-Pipeline bereitstellen, verwenden Entwicklerinnen und Entwickler Befehlszeilen-Tools, um Code aus einer lokalen Entwicklungsumgebung mit der RDE zu synchronisieren. Nachdem die Änderungen erfolgreich in einer RDE getestet wurden, stellen Sie sie über die Cloud Manager-Pipeline in einer regulären Cloud-Entwicklungsumgebung bereit, wodurch der Code die entsprechenden Qualitätsprüfungen durchläuft.

Ausführungsmodi runmodes

In bestehenden AEM-Lösungen haben Kundinnen und Kunden die Möglichkeit, Instanzen mit beliebigen Ausführungsmodi auszuführen und OSGi-Konfigurationen anzuwenden oder OSGi-Pakete in diesen spezifischen Instanzen zu installieren. Zu den definierten Ausführungsmodi gehören normalerweise der Service (Autor und Veröffentlichen) sowie die Umgebung (RDE, dev, stage, prod).

AEM as a Cloud Service hingegen ist eigenwilliger bezüglich der Frage, welche Ausführungsmodi verfügbar sind und wie ihnen OSGi-Pakete und OSGi-Konfigurationen zugeordnet werden können:

AEM as a Cloud Service lässt die Verwendung von Ausführungsmodi nicht zu, um Inhalte für bestimmte Umgebungen oder Dienste zu installieren. Wenn eine Entwicklungsumgebung mit Daten oder HTML-Dateien bestückt werden muss, die sich nicht in der Staging- oder Produktionsumgebung befinden, kann Package Manager verwendet werden.

Folgende Konfigurationen für den Ausführungsmodus werden unterstützt:

Es wird jene OSGi-Konfiguration verwendet, die über die meisten passenden Ausführungsmodi verfügt.

Bei der lokalen Entwicklung wird ein Ausführungsmodus-Startparameter -r verwendet, um die OSGi-Konfiguration für den Ausführungsmodus anzugeben.

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

Konfiguration von Wartungsaufgaben in der Quell-Code-Verwaltung maintenance-tasks-configuration-in-source-control

Die Konfiguration von Wartungsaufgaben muss in der Quell-Code-Verwaltung persistiert werden, da der Bildschirm Tools > Vorgänge in Cloud-Umgebungen nicht mehr verfügbar ist. Dadurch wird sichergestellt, dass Änderungen vorsätzlich persistiert werden, anstatt reaktiv angewendet und dann vergessen zu werden. Weitere Informationen finden Sie unter Wartungsaufgaben in AEM as a Cloud Service.