Ejemplos de configuración de Adobe Managed CDN en AEM as a Cloud Service

Cuando se lanzó AEM as a Cloud Service por primera vez (y hasta el pasado Adobe Summit, en realidad), la única forma de configurar el comportamiento de la CDN era utilizar las configuraciones de Apache para actualizar cache-control lógica y utilizarla para definir el comportamiento de la caché. Pero eso no ayudó con las necesidades más avanzadas que normalmente uno configuraría por su cuenta en un diseño de CDN de traiga su propio en Fastly, Akamai o Cloudflare.
Pero a partir de este punto, hay un nuevo conjunto de funciones de CDN administradas que puede aprovechar en su programa AEM Cloud Service, lo que tiene implicaciones masivas sobre cómo simplificar una configuración híbrida de AEM Cloud Service y AEM Edge Delivery (ahora conocida como "AEM Live").

Este video le brinda una descripción general y, a continuación, analizaré algunos ejemplos de configuración.

Lo que necesitará

En estos ejemplos se supone que está ejecutando AEM as a Cloud Service en una suscripción de pago. Desafortunadamente, estos ejemplos no funcionan con un Sandbox (MUY A MI PESAR), ya que todas las instancias de Sandbox de AEMaaCS comparten una serie de configuraciones, incluida la configuración de CDN. Por lo tanto, los nombres de host personalizados, los certificados SSL personalizados y las configuraciones de CDN personalizadas no podrán probarlos sin una instalación de AEM as a Cloud Service de pago y con licencia.

A continuación, para realizar las funciones de redireccionamiento que se indican a continuación, deberá unirse al programa de adopción temprana y habilitar esta función en su programa AEM como se describe aquí.

Configuración de la canalización de configuración

Lo primero que debe hacer es configurar la configuración en el proyecto AEM.

Cree un directorio de configuración en la raíz de su proyecto llamado /config y coloque un archivo en ese directorio llamado cdn.yaml. (Esa canalización también puede recoger otras configuraciones, que pronto incluirán la siempre esquiva canalización LogForwarding ). Consulte esta documentación para obtener más información.

Puede configurar su canalización para que solo funcione con Dev o configurar canalizaciones de configuración separadas para DEV, STG y PROD. La única forma de probar sus configuraciones será ejecutarlas a través de estas canalizaciones, por lo que definitivamente desea que esto esté separado de su canalización Full-Stack.

Afortunadamente, las canalizaciones de configuración solo tardan entre 1 y 2 minutos en ejecutarse cada vez, por lo que la iteración es en su mayoría indolora.

Un conjunto de ejemplos de problemas a resolver

Como ejemplo de los problemas que hay que resolver con este tipo de configuración, digamos que tienes una configuración con algunos elementos como el siguiente diagrama:

Es decir, tienes:

• AEM como servicio en la nube
• Algunos elementos que deben servirse desde la pila de AEMaaCS Dispatcher/Publisher
• Algunos AEM Edge Delivery (AEM.live/Helix/Franklin) diferentes Sitios
• Algunos contenidos heredados de AEM 6.5 que aún no se han migrado y que se encuentran en equipos autoalojados
• Algunos otros recursos que no son de AEM, como equipos de Commerce, uno o dos sitios de Wordpress u otros recursos que no están en la pila de AEM.

Con eso, hablemos de algunas de las configuraciones que puede emplear.

Cómo redirigir a diferentes backends en función de la ruta

Supongamos que tienes un mapeo como este:

• Todo lo que esté en /content/dam debe servirse desde la instancia de AEMaaCS Assets
• Cualquier cosa en /blog/ debe ir a su sitio de wordpress
• Todo lo que / se servirá desde Edge Delivery

A continuación, se muestra cómo se configuraría en la asignación de CDN administrada. En primer lugar, las configuraciones asumen que la dirección PREDETERMINADA de todo el tráfico será hacia su pila de AEMaaCS Dispatcher/Publish. No hay forma de decir explícitamente "tal o cual tráfico va a AEMaaCS", solo se dice lo que NO va a AEMaaCS.
Entonces, para este ejemplo:

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

Nota sobre lo anterior: hay propiedades que hemos agregado para garantizar que /systemready y /content/test-site* se pasen a AEMaaCS. En este caso, incluso si solo utiliza la instancia de AEM como DAM, las pruebas funcionales OOTB deberán pasar por AEM y producirán un error en las canalizaciones a menos que puedan llegar a AEM.

Cómo hacer una redirección geográfica basada en el país

Para realizar la redirección geográfica basada en el país, puede usar la propiedad clientCountry que viene de forma gratuita en la CDN para basar su redirección.
Tu configuración aquí podría verse así:

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

Cómo hacer la lógica de redireccionamiento del cliente

Supongamos que tiene una redirección base que desea realizar para su sitio de entrega perimetral antes de que lleguen las solicitudes. Por ejemplo, supongamos que su sitio heredado utilizaba una estructura de directorios basada en la configuración regional (como en_uk, en_sg, en_us, etc.) y ha pasado a un modelo basado en lenguaje más plano (es decir, . solo /en/home). Además, digamos que usaste .html al final de todas las páginas anteriores, pero en Edge Delivery no.
La siguiente lógica de redireccionamiento tomaría cualquier solicitud de página que llegue desde /en_us/home.html y las redirigiría a /en/home.

## 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' 

Cómo redirigir y conservar la cadena de consulta

En Adobe Managed CDN hay diferentes propiedades para url y 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'

¡Esperemos que esto ayude!

Sobre el autor

¿Te gusta lo que escuchaste? ¿Tiene preguntas sobre lo que es adecuado para usted? ¡Nos encantaría hablar! Contáctenos

Episodios de podcast y publicaciones de blog