Konfigurationsbeispiele für Adobe Managed CDN auf AEM as a Cloud Service

Als AEM as a Cloud Service zum ersten Mal veröffentlicht wurde (und eigentlich bis zum letzten Adobe Summit), bestand die einzige Möglichkeit, das Verhalten des CDN zu konfigurieren, darin, Ihre Apache-Konfigurationen zu verwenden, um cache-control Logik zu aktualisieren und diese zum Definieren des Cache-Verhaltens zu verwenden. Aber das half nicht bei fortgeschritteneren Anforderungen, die man normalerweise selbst in einem Bring-Your-Own-CDN-Layout in Fastly, Akamai oder Cloudflare konfigurieren würde.
Ab diesem Zeitpunkt gibt es jedoch eine Reihe neuer Managed CDN-Funktionen, die Sie in Ihrem AEM Cloud Service-Programm nutzen können, was massive Auswirkungen auf die Vereinfachung einer hybriden Einrichtung von AEM Cloud Service und AEM Edge Delivery (jetzt als "AEM Live" bezeichnet) hat.

Dieses Video gibt Ihnen einen Überblick, und im Folgenden gehe ich auf einige Konfigurationsbeispiele ein.

Was du brauchst

In diesen Beispielen wird davon ausgegangen, dass Sie AEM as a Cloud Service mit einem kostenpflichtigen Abonnement ausführen. Leider funktionieren diese Beispiele nicht mit einer Sandbox (SEHR ZU MEINEM LEIDWESEN), da die AEMaaCS Sandbox-Instanzen alle eine Reihe von Konfigurationen gemeinsam nutzen, einschließlich der CDN-Konfiguration. Benutzerdefinierte Hostnamen, benutzerdefinierte SSL-Zertifikate und benutzerdefinierte CDN-Konfigurationen, die Sie ohne eine kostenpflichtige und lizenzierte AEM as a Cloud Service-Installation nicht testen können.

Um die unten aufgeführten Umleitungsfunktionen ausführen zu können, müssen Sie als Nächstes dem Early-Adopter-Programm beitreten und diese Funktion in Ihrem AEM-Programm aktivieren, wie hier beschrieben.

Einrichten der Konfigurationspipeline

Als Erstes müssen Sie Ihre Konfiguration in Ihrem AEM-Projekt einrichten.

Erstellen Sie im Stammverzeichnis Ihres Projekts ein Konfigurationsverzeichnis mit dem Namen /config , und platzieren Sie eine Datei mit dem Namen cdn.yamlin diesem Verzeichnis . (Andere Konfigurationen können auch von dieser Pipeline übernommen werden, einschließlich der immer schwer fassbaren LogForwarding -Pipeline.) Weitere Informationen finden Sie in dieser Dokumentation .

Sie können Ihre Pipeline so einrichten, dass sie nur mit Dev funktioniert, oder separate Config-Pipelines für DEV, STG und PROD einrichten. Die einzige Möglichkeit, Ihre Konfigurationen zu testen, besteht darin, sie über diese Pipelines auszuführen, sodass Sie dies auf jeden Fall von Ihrer Full-Stack-Pipeline trennen möchten.

Glücklicherweise dauert es jedes Mal nur 1-2 Minuten, bis die Config-Pipelines ausgeführt werden, sodass die Iteration meist schmerzlos ist.

Ein Beispiel für zu lösende Probleme

Als Beispiel für die Probleme, die durch diese Art der Konfiguration gelöst werden müssen, nehmen wir an, Sie haben ein Setup mit einigen Elementen wie dem folgenden Diagramm:

D.h. Sie haben:

• AEM als Cloud-Dienst
• Einige Elemente, die von Ihrem AEMaaCS Dispatcher/Publisher-Stack bereitgestellt werden müssen
• Einige verschiedene AEM Edge-Bereitstellung (AEM.live/Helix/Franklin) Lagen
• Einige ältere, noch nicht migrierte AEM 6.5-Inhalte, die sich in selbstgehosteten Geräten befinden
• Einige andere Ressourcen, die nicht von AEM stammen, wie z. B. Commerce-Ausrüstung, ein oder zwei Wordpress-Sites oder andere Ressourcen, die sich überhaupt nicht in Ihrem AEM-Stack befinden.

Lassen Sie uns nun über einige der Konfigurationen sprechen, die Sie verwenden können.

So leiten Sie basierend auf dem Pfad zu verschiedenen Backends um

Nehmen wir an, Sie haben eine Zuordnung wie diese:

• Alles, was sich in /content/dam befindet, sollte von Ihrer AEMaaCS Assets-Instanz bereitgestellt werden
• Alles, was in /blog/ ist, sollte auf Ihre WordPress-Seite gelangen
• Alles, was von / wird, wird von Edge Delivery bereitgestellt

So konfigurieren Sie dies in der Managed CDN-Zuordnung. Zunächst einmal gehen die Konfigurationen davon aus, dass die STANDARD-Richtung des gesamten Datenverkehrs zu Ihrem AEMaaCS Dispatcher/Publish-Stack führt. Es gibt keine Möglichkeit, explizit zu sagen, dass dieser und jener Datenverkehr an AEMaaCS geht, Sie sagen nur, was NICHT an AEMaaCS geht.
Also, für dieses Beispiel:

originSelectors:
    rules:
      - name: support
        when: { reqProperty: path, like: /blog* } 
        action:
          type: selectOrigin
          originName: KRUSTY-WORDPRESS-BLOG
      - name: edge-delivery-site1
        when: 
          allOf: 
            - reqProperty: path
              like: /* 
            - reqProperty: path
              doesNotMatch: /content/dam* 
            - reqProperty: path
              doesNotMatch: /content/test-site*
            - reqProperty: path
              doesNotMatch: /systemready*
            - reqProperty: domain
              doesNotMatch: author* 
        action:
          type: selectOrigin
          originName: edge-delivery-site1
    origins:
      - name: KRUSTY-WORDPRESS-SITE
        domain: whyamiusingthisplatform.com
        forwardHost: false
      - name: edge-delivery-site1
        domain: main--projectname--siteowner.aem.live
        forwardHost: false

Hinweis zu den oben genannten Punkten: Es gibt Eigenschaften, die wir hinzugefügt haben, um sicherzustellen, dass /systemready und /content/test-site* an AEMaaCS übergeben werden. Selbst wenn Sie Ihre AEM-Instanz nur als DAM verwenden, müssen die OOTB-Funktionstests in diesem Fall AEM durchlaufen und Ihre Pipelines schlagen fehl, es sei denn, sie können AEM erreichen.

So führen Sie eine länderbasierte Geo-Umleitung durch

Um eine länderbasierte Geoumleitung durchzuführen, können Sie die clientCountry Eigenschaft verwenden, die kostenlos im CDN enthalten ist, um Ihre Umleitung zu erstellen.
Ihre Konfiguration hier könnte wie folgt aussehen:

data:
  experimental_redirects:
    rules:
## HOMEPAGE REDIRECTS BY GEO
      - name: homepage-redirect-us
        when:
          allOf:
            - reqProperty: clientCountry
              - in: 
                - US
                - CA
                - UK
                - IR 
            - { reqProperty: path, equals: "/" }
        action:
          type: redirect
          location: https://mycoolsite/en/home

Ausführen der Clientumleitungslogik

Angenommen, Sie haben eine Basisumleitung, die Sie für Ihre Edge-Bereitstellungswebsite durchführen möchten, bevor Anforderungen an sie gesendet werden. Angenommen, Ihre Legacy-Website verwendet eine gebietsschemabasierte Verzeichnisstruktur (z. B. en_uk, en_sg, en_ususw.) und Sie sind zu einem flacheren sprachbasierten Modell gewechselt (z. B. nur /en/home). Nehmen wir auch an, Sie haben .html am Ende all Ihrer vorherigen Seiten, aber bei Edge Delivery tun Sie dies nicht.
Die folgende Umleitungslogik nimmt alle Seitenanforderungen, die von /en_us/home.html eingehen, und leitet sie an /en/homeweiter.

## LOCALE REDIRECTS BY GEO + STRIP *.HTML
      - name: redirect-en
        when: { reqProperty: path, like: "/en_*" }
        action:
          type: redirect
          status: 302
          location:
            reqProperty: path
            transform:
              - op: replace
                match: '^/en_(..)(.*).html*$'
                replacement: '/en\2' 

Umleiten und Beibehalten der Abfragezeichenfolge

Im Adobe Managed CDN gibt es unterschiedliche Eigenschaften für url und path.

      - name: china-redirect-dotgeo
        when:
          allOf:
            - {reqProperty: path, like: "*.geo.html*" }
            - { reqProperty: clientCountry, equals: "CN" }
        action:
          type: redirect
          status: 302
          location:
            reqProperty: url
            transform:
              - op: replace
                match: '^\/(en_us)(.*)\.geo\.html(.*)$'
                replacement: '/zh-cn\2\3'

Hoffentlich hilft das!

Über den Autor

Gefällt Ihnen, was Sie gehört haben? Haben Sie Fragen dazu, was für Sie das Richtige ist? Wir würden uns freuen, mit Ihnen zu sprechen! Kontaktieren Sie uns

Podcast-Episoden & Blogbeiträge