Hinweis: Dies ist ein etwas fortgeschritteneres Thema zu Edge Delivery Services und Dokumentenerstellung. Für eine Einführung in EDS und Dokumentenerstellung schauen Sie sich bitte zuerst dies zur Einordnung an.

Hintergrund zum dateibasierten AEM Edge Delivery Configs & Configuration Service

Als Adobe Edge Delivery Services (oder Helix, wie es intern genannt wird) erstmals startete, wurden alle wichtigen standortweiten Konfigurationen mithilfe von Konfigurationsdateien durchgeführt, die im Repository der Seite eingecheckt wurden. Die Bereitstellung einer neuen Konfiguration erfolgte, indem man auf den Branch main des Repo pushte, der diese Konfiguration live auf der Seite verlagerte. Ein Nachteil dabei war, dass jedes jeweilige Repository direkt an eine Seite und ein Dokumentenrepository gebunden sein musste. Man könnte dann nicht ein einziges Code-Repository mehrere Seiten steuern lassen – oder sogar mehrere Versionen einer einzigen Seite (wie dev/stg/prd Umgebungen für Inhalts- oder Konfigurationsstaging).

Infolgedessen und anderer technischer Bedenken wechselt Adobe zu einer neuen Architektur, die auf dem Configuration Service basiert. In diesem Paradigma werden Konfigurationen zentral von Adobe in ihrem API-gesteuerten Konfigurationsdienst gespeichert und versionisiert, und sobald Sie auf diesen Dienst migriert sind, haben die Dateien in Ihrem Edge Delivery-Projekt keinen Einfluss mehr auf die Website.

Voraussetzungen für den Wechsel zum Konfigurationsdienst

Wie auf https://www.aem.live/docs/config-service-setup#prerequisiteserwähnt, musst du, bevor du mit dem Wechsel zum Config Service beginnst, zuerst sicherstellen, dass dein Adobe-Nutzer als Administrator für deine Github-Organisation zugeordnet ist, damit du im Config Service die Befugnis hast, Änderungen vorzunehmen. Dein technischer Ansprechpartner bei Adobe, mit dem du normalerweise zu tun hast, sollte dich damit verbinden können.

Endpunkte und Konfigurationsoberflächen, die von einem Wechsel zum Konfigurationsdienst betroffen sind

Dies betrifft die folgenden Konfigurationsflächen in einem Edge Delivery-Projekt:

• Content Bus Mapping: Die Konfiguration in /fstab.yaml , bei der das Projekt auf einen Standort entweder in DA (oder anderswo, wie AEM/Universal Editor oder SharePoint) abgebildet wird, befindet sich jetzt im Config Service. Dies ist der kritischste Bit, der es ermöglicht, dass ein einzelnes Repo mehrere Seiten steuern kann (früher als "repoless"-Setup bekannt, da dadurch Code-Repo und Inhalts-Repo nicht untrennbar miteinander verbunden waren).

• Abfrageindizes: Die Indexkonfiguration für alle Sprachen wurde zuvor im Projekt in /helix-query.yaml

• Sitemap-Konfiguration: Die Sitemap-Konfiguration, die zuvor in /helix-sitemap.yaml erstellt wurde, befindet sich nun im Config Service.

• Sidekick-Konfiguration: Es gibt zwei verschiedene Arten von Sidekick-Konfigurationen, die früher im Git-Projekt enthalten waren, jetzt aber anderswo vorhanden sind.

  • DA-Plugins: Früher, in den frühen Tagen von DA, behielten wir DA-Plugins in der /tools/sidekick/config.json -Datei im Code-Repository. Das wäre für Dinge wie verschiedene DA-UI-Verbesserungen wie unseren Datumswähler, das AEM-Tags-Plugin usw. Dies wird nun im Library -Blatt in der DA-Konfiguration in DA selbst gespeichert, statt in der Codebasis.
  • Sidekick-Plugins/Konfiguration: Andere AEM Sidekick-Konfigurationen, wie etwa für Quick Edit oder AEM Experimentation, werden nun im Konfigurationsservice korrekt gehalten und nicht mehr in DA. Die Sidekick-Konfiguration im EDS-Git-Projekt hat keine Wirkung mehr.

• HTTP-Header-Konfiguration: Diese wurde früher im headers -Blatt von DA gespeichert, wird jetzt aber in den Konfigurationsdienst übertragen. Das gilt für die CORS-Konfiguration, wie zum Beispiel einen access-control-allow-origin -Header auf bestimmten Hosts anzubringen.

• Helix Preview/Publish Authentication: Für authentifizierte Preview/Publishing-Zugriffskontrolle verwenden wir ein Sheet-basiertes Authentifizierungsmodell, bei dem Sie in https://da.live/sheet#/[orgname]/[sitename]/.helix/configein data Sheet haben, in dem wir die admin.role.author oder admin.role.publish Rollen einzelner Adobe-Entitäts-IDs auflisten, die Benutzern/Profilen zugeordnet werden. Dies wurde nun mit dem Config Service gestrichen, und Benutzer werden direkt im Config Service für diese Vorschau-/Veröffentlichungsrollen, aber auch für Zugriffsanfragen verwaltet. Außerdem musste man bei authentifizierter Veröffentlichung zuvor ein unleserliches Adobe-Profil/Benutzer-ID wie "[email protected]" verwenden, das mit dem Benutzer-Login einer bestimmten Organisation zugeordnet wurde. Im Config Service erlaubt Helix, dass Sie Ihre E-Mail-Adresse anstelle der undefiniblen Entitäten-ID verwenden und sogar Benutzer Zugang anfordern können, wenn sie auf Vorschau-/Veröffentlichungsprobleme stoßen, was dann in einer Admin-Interface-App in DA angezeigt wird, um Zugriffsanfragen zu genehmigen oder abzulehnen.

• Robots.txt Konfiguration: Diese wurde früher im Git-Projekt in /robots.txt gehalten, ist jetzt aber im Config Service konfiguriert.

• CDN-Konfiguration: Diese wurde zuvor im .helix/config -Blatt in DA gespeichert, wird jetzt aber in den Konfigurationsdienst übertragen. Das wäre für die Einstellung von Werten wie:

  • cdn.prod.host
  • cdn.prod.type
  • cdn.prod.serviceId
  • cdn.prod.authToken

Schritte zum Verschieben einer bestehenden dateibasierten Edge-Delivery-Seite in den Konfigurationsdienst

Es gibt einen migrate -Befehl in der AEM Admin (Helix) API, der es ermöglicht, eine dateibasierte Edge Delivery-Einrichtung automatisch auf den Config Service zu übertragen. Es gibt allerdings einige Vorbehalte, also hier ist, was du darüber wissen solltest.

Zunächst nehmen wir an, du hast eine bestehende Seite, die auf DA mit dateibasierter Konfiguration erstellt wurde (ich weiß, dass ich einige solcher Seiten habe, ich bin vielleicht in der Minderheit, aber das ist mein Blogbeitrag – du solltest die Schritte für deinen eigenen Anwendungsfall noch einmal überprüfen).

Schritte:

1. Stelle sicher, dass du Administrator deiner Organisation bist: Wie oben erwähnt, arbeite mit Adobe zusammen, um sicherzustellen, dass du admin auf deiner Github-Organisation hast. Überprüfe das, indem du zu https://tools.aem.live/tools/site-admin/index.html gehst und dich dann anmeldest. Wenn es richtig funktioniert, solltest du eine erfolgreiche 200-Anfrage für https://admin.hlx.page/config/[orgname]/sites.json

2. Holen Sie sich Ihr Authentifizierungstoken: Mach Shift+Ctrl+I oder shift+cmd+I, um Entwicklertools zu öffnen, und schau dir die oben erwähnte sites.json an. Wenn du den Netzwerk-Tab öffnest und dir Headers ansiehst, siehst du einen x-auth-token Wert. Kopiere diesen Wert, da das das Inhabertoken ist, das du für die folgenden API-Anfragen verwenden musst, um mit dem AEM Configuration Service zu interagieren.

3. Erstellen Sie eine Kopie Ihrer Website: Es ist eine gute Idee, einen Testlauf auf deiner Seite (der mit dateibasierten Konfigurationen) durchzuführen, damit du diesen Prozess testen kannst, bevor du ihn auf Prod ausführst. Erstelle ein neues EDS-Repository und eine neue Seite und fülle sie mit demselben Codebase wie deine aktuelle Seite aus (falls du noch kein Entwicklungs-Repository hast). Idealerweise solltest du außerdem eine Entwickler-Content-Quelle befüllen, damit du eine voll ausgestattete und funktionsfähige Sandbox hast, mit der du herumspielen kannst.

4. Führe den Migry-Command Dry-Run aus: Führe folgenden Befehl aus, der einen Dry Run der Migration vom dateibasierten zum Config-Service durchführt:
   
   curl --request GET --url 'https://admin.hlx.page/config/{my-org}/sites/{my-site}.json?migrate=true&validate=true' -H "Authorization: token $MY_AUTH_TOKEN_NOTED_ABOVE"
   
   Wenn das funktioniert, wird ein Validierungstext wie folgt angezeigt, der anzeigt, ob die Migration funktioniert. In meinem Fall bedeutet das, dass ich NOCH NICHT bereit bin zu migrieren und Dinge zu beheben habe:
   
   "error": "validation failed.", "message": "/sidekick/plugins/0/environments/0 must be equal to one of the allowed values; /sidekick/plugins/2/environments/0 must be equal to one of the allowed values",
   
   Außerdem, wenn du bei deinem Aufruf eine 400-fehlerhafte Anfrage bekommst, kannst du auch den x-error -Header in der HTTP-Antwort verwenden, der dir auch über eventuelle Probleme in der Migr-Dryrun-Anfrage informiert:

   

   In diesem Fall sagt mir der Fehler, dass in meiner Liste der AEM Sidekick-Plugins das erste Plugin in /tools/sidekick/config.json ungültig ist, da die Konfiguration eines Plugins auf diese Weise im Config Service nicht mehr unterstützt wird. In diesem Beispiel muss ich dieses Plugin in das DA-Bibliotheksblatt für DA-Plugins migrieren.

   

5. Beheben Sie alle oben erwähnten Validierungsprobleme: Du musst alle auftretenden Probleme beheben und dann deine Validierungsanfrage erneut durchführen.
   
   Nimm alle bestehenden Plugins, die im Projekt als Sidekick-Plugins definiert sind, und leg sie in DA. Im Fall von Sidekick-Plugin-Problemen wie diesem würden DA-Plugins stattdessen in https://da.live/config#/[orgname]/[sitename]/ im Tab "Library" des Sheets konfiguriert.

   

   Oder ein anderes Problem wie dieses:

   

   Das deutet darauf hin, dass wir einige illegale Eigenschaften in unseren Headern hatten, die nicht mehr unterstützt werden (oder vielleicht nie unterstützt wurden und nichts kaputt gemacht haben, sodass sie versehentlich darin gelassen wurden).
   
   Sobald diese Probleme gelöst sind, sind Sie bereit, die Migration selbst durchzuführen.

6. Push/Migrate der sauberen und validierten Konfiguration zum Konfigurationsdienst: Um die Konfiguration zu pushen, verwenden Sie folgenden Befehl:
   
   curl --request POST --url 'https://admin.hlx.page/config/{my-org}/sites/{my-site}.json?migrate=true' -H "Authorization: token $MY_AUTH_TOKEN_NOTED_ABOVE"
   
   Im Wesentlichen derselbe Befehl wie oben, aber mit einem POST statt eines GET. Dadurch werden Sie zum Konfigurationsservice migriert.

7. Validieren: Es gibt ein paar Dinge, die man sofort überprüfen sollte, sobald man umsteigt.

   1. Validiere Indizes: Geh zu https://tools.aem.live/tools/index-admin/index.html und überprüfe, dass deine Indizes korrekt erfasst wurden
   2. Sitemaps validieren: Geh zu https://tools.aem.live/tools/sitemap-admin/index.html und überprüfe, dass alle Sitemaps durchgekommen sind
   3. Validiere Nutzer: Geh zu https://tools.aem.live/tools/user-admin/index.html?org={orgname}&site={sitename} und stelle sicher, dass deine Vorschau-/Veröffentlichen-Nutzer dort angezeigt werden.
   4. Validiere Nutzer in DA: Gehe zu https://da.live/apps/aem-permissions#/{orgname}/{sitename} , wo du eine benutzerfreundliche Liste von Vorschau-/Veröffentlichungsberechtigungen sehen kannst, sobald sie DA ausgesetzt sind. Hier wirst du jetzt auch in der Lage sein
   5. Vorschau/Veröffentlichung validieren: Wenn Sie als Nutzer mit Vorschau-/Veröffentlichungsberechtigungen eingeloggt sind, stellen Sie sicher, dass Sie weiterhin die Möglichkeit haben, ordnungsgemäß vorzuschauen und zu veröffentlichen. Holen Sie sich einen Nutzer, der KEINEN Zugriff auf Vorschau oder Veröffentlichung hat, und stellen Sie sicher, dass es ordnungsgemäß gesperrt ist.
   6. Jede andere sonstige Bestätigung, von der du glaubst, dass sie für deine Seite notwendig ist.

8. Burn-in: QA und Burn-in mit dem Team, andere Preview-/Veröffentlichungsprobleme beheben und die neue Konfiguration mindestens eine Woche lang einbrennen, um eventuelle auftretende Probleme auszuschließen.

9. Konfigurationsdateien bereinigen: Sobald das Burn-in abgeschlossen ist, benötigen Sie Ihre In-Repo-Konfigurationen nicht mehr und können diese einzeln zurückziehen. Ich würde empfehlen, saubere Kopien deiner aktuellen Konfigurationen für die Versionskontrolle in Git zu speichern, nur für DR-Zwecke, falls jemand eine fehlerhafte API-Anfrage stellt, die aus welchem Grund auch immer nicht rückgängig gemacht werden kann.

Anmerkungen zu CI/CD-Implikationen des Konfigurationsdienstes

Eine Anmerkung hier zu CI/CD: Da Sie nun die inhärente Flexibilität eines API-gesteuerten Konfigurationsdienstes haben, haben Sie auch den Nachteil, dass Ihr git-gesteuertes CI/CD keinen Einfluss mehr hat.

Die gute Nachricht ist, dass es einige Tools wie den Version Admin gibt, um Konfigurationsänderungen und wer welche Änderungen vornimmt, im Blick zu behalten:

Die schlechte Nachricht ist, dass dadurch das eingebaute, auf Pull-Anfragen ausgerichtete CI/CD-Framework entfernt wird, das wir alle kennen und in Edge Delivery absolut lieben. Wenn Sie also Situationen haben, in denen ein Junior-Ingenieur Änderungen vorschlagen soll, wird es für ihn deutlich schwieriger sein, Ihnen eine Pull Request zu geben, die zeigt, dass ihre Konfigurationsänderung sicher vorgetragen werden kann.

Es wird dadurch komplizierter, dass die Autorisierung für die API auf deinem aktuell eingeloggten Nutzer basiert, was es etwas widerstandsfähig macht, einen persistenten Schlüsselsatz in eine CI/CD-Pipeline zu integrieren. Ich bin sicher, es ist machbar, es wird nur ein bisschen Basteln erfordern.

Dafür musst du (zum Zeitpunkt dieses Schreibens) deinen eigenen CI/CD-Prozess entwickeln, mit dem du dich wohlfühlst, entsprechend der Größe und Zusammensetzung deiner Organisation.

Ich hoffe, das hilft, und melde dich bitte, wenn du mit irgendetwas davon Probleme hast!

Über den Autor

Gefällt dir, was du gehört hast? Haben Sie Fragen dazu, was für Sie am besten ist? Wir würden uns sehr freuen! Kontaktieren Sie uns

Mehr Artikel, die Ihnen gefallen könnten