Configurer le trafic sur le réseau CDN cdn-configuring-cloud

AEM as a Cloud Service propose un ensemble de fonctionnalités configurables au niveau de la couche CDN gérée par Adobe qui modifient la nature des requêtes entrantes ou des réponses sortantes. Les règles suivantes, décrites en détail dans cette page, peuvent être déclarées pour obtenir le comportement suivant :

Les règles de filtrage du trafic (dont le WAF), qui contrôlent le trafic autorisé ou refusé par le CDN, peuvent également être configurées sur le CDN. Cette fonctionnalité est déjà disponible et vous pouvez en savoir plus à ce sujet sur la page Règles de filtre de trafic y compris les règles WAF .

En outre, si le réseau de diffusion de contenu ne peut pas contacter son origine, vous pouvez écrire une règle qui fait référence à une page d’erreur personnalisée auto-hébergée (qui est alors rendue). Pour en savoir plus à ce sujet, consultez l’article Configuration des pages d’erreur CDN .

Toutes ces règles, déclarées dans un fichier de configuration dans le contrôle de code source, sont déployées à l’aide du pipeline de configuration de Cloud Manager. Gardez à l’esprit que la taille cumulée du fichier de configuration, y compris les règles de filtrage du trafic, ne peut pas dépasser 100 Ko.

Ordre d’évaluation order-of-evaluation

Fonctionnellement, les différentes fonctionnalités mentionnées précédemment sont évaluées dans l’ordre suivant :

Configuration initial-setup

Avant de pouvoir configurer le trafic sur le réseau de diffusion de contenu, vous devez effectuer les opérations suivantes :

config/
     cdn.yaml

Remarques

Syntaxe configuration-syntax

Les types de règle dans les sections ci-dessous partagent une syntaxe commune.

Une règle est référencée par un nom, une "clause de condition" et des actions.

La clause when détermine si une règle sera évaluée, en fonction de propriétés telles que le domaine, le chemin, les chaînes de requête, les en-têtes et les cookies. La syntaxe est la même pour tous les types de règles. Pour plus d’informations, reportez-vous à la section Structure de condition de l’article Règles de filtrage du trafic .

Les détails du noeud actions diffèrent par type de règle et sont décrits dans les sections individuelles ci-dessous.

Demander des transformations request-transformations

Les règles de transformation de requêtes vous permettent de modifier les requêtes entrantes. Les règles prennent en charge les chemins d’accès, paramètres de requête et en-têtes (y compris les cookies) de définition, de dédéfinition et de modification en fonction de diverses conditions de correspondance, y compris des expressions régulières. Vous pouvez également définir des variables qui pourront être référencées ultérieurement dans la séquence d’évaluation.

Les cas d’utilisation sont variés et incluent des réécritures d’URL pour simplifier l’application ou mapper les URL héritées.

Comme mentionné précédemment, il existe une limite de taille au fichier de configuration, de sorte que les organisations ayant des exigences plus importantes doivent définir des règles dans la couche apache/dispatcher.

Exemple de configuration :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev", "stage", "prod"]
data:
  requestTransformations:
    removeMarketingParams: true
    rules:
      - name: set-header-rule
        when:
          reqProperty: path
          like: /set-header
        actions:
          - type: set
            reqHeader: x-some-header
            value: some value

      - name: unset-header-rule
        when:
          reqProperty: path
          like: /unset-header
        actions:
          - type: unset
            reqHeader: x-some-header

      - name: unset-matching-query-params-rule
        when:
          reqProperty: path
          equals: /unset-matching-query-params
        actions:
          - type: unset
            queryParamMatch: ^removeMe_.*$

      - name: unset-all-query-params-except-exact-two-rule
        when:
          reqProperty: path
          equals: /unset-all-query-params-except-exact-two
        actions:
          - type: unset
            queryParamMatch: ^(?!leaveMe$|leaveMeToo$).*$

      - name: multi-action
        when:
          reqProperty: path
          like: /multi-action
        actions:
          - type: set
            reqHeader: x-header1
            value: body set by transformation rule
          - type: set
            reqHeader: x-header2
            value: '201'

      - name: replace-html
        when:
          reqProperty: path
          like: /mypath
        actions:
          - type: transform
           reqProperty: path
           op: replace
           match: \.html$
           replacement: ""

Actions

Les actions disponibles sont expliquées dans le tableau ci-dessous.

Les actions peuvent être liées ensemble. Par exemple :

actions:
    - type: transform
      reqProperty: path
      op: replace
      match: \.html$
      replacement: ""
    - type: transform
      reqProperty: path
      op: tolower

Variables variables

Vous pouvez définir des variables pendant la transformation de requête, puis les référencer ultérieurement dans la séquence d’évaluation. Pour plus d’informations, consultez le diagramme ordre d’évaluation .

Exemple de configuration :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["prod", "dev"]
data:
  requestTransformations:
    rules:
      - name: set-variable-rule
        when:
          reqProperty: path
          equals: /set-variable
        actions:
          - type: set
            var: some_var_name
            value: some_value

  responseTransformations:
    rules:
      - name: set-response-header-while-variable
        when:
          var: some_var_name
          equals: some_value
        actions:
          - type: set
            respHeader: x-some-header
            value: some header value

Transformations de réponse response-transformations

Les règles de transformation de réponse vous permettent de définir et de désinitialiser des en-têtes des réponses sortantes du CDN. Consultez également l’exemple ci-dessus pour référencer une variable précédemment définie dans une règle de transformation de requête.

Exemple de configuration :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["prod", "dev"]
data:
  responseTransformations:
    rules:
      - name: set-response-header-rule
        when:
          reqProperty: path
          like: /set-response-header
        actions:
          - type: set
            value: value-set-by-resp-rule
            respHeader: x-resp-header

      - name: unset-response-header-rule
        when:
          reqProperty: path
          like: /unset-response-header
        actions:
          - type: unset
            respHeader: x-header1

      # Example: Multi-action on response header
      - name: multi-action-response-header-rule
        when:
          reqProperty: path
          like: /multi-action-response-header
        actions:
          - type: set
            respHeader: x-resp-header-1
            value: value-set-by-resp-rule-1
          - type: set
            respHeader: x-resp-header-2
            value: value-set-by-resp-rule-2

Actions

Les actions disponibles sont expliquées dans le tableau ci-dessous.

Sélecteurs d’origine origin-selectors

Vous pouvez utiliser le réseau de diffusion de contenu AEM pour acheminer le trafic vers différents serveurs principaux, y compris les applications non Adobes (par chemin ou sous-domaine, par exemple).

Exemple de configuration :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  originSelectors:
    rules:
      - name: example-com
        when: { reqProperty: path, like: /proxy-me* }
        action:
          type: selectOrigin
          originName: example-com
          # skpCache: true
    origins:
      - name: example-com
        domain: www.example.com
        # ip: '1.1.1.1'
        # forwardHost: true
        # forwardCookie: true
        # forwardAuthorization: true
        # timeout: 20

Actions

L’action disponible est expliquée dans le tableau ci-dessous.

Origines

Les connexions aux origines sont uniquement SSL et utilisent le port 443.

Proxys vers les Edge Delivery Services proxying-to-edge-delivery

Dans certains cas, des sélecteurs d’origine doivent être utilisés pour acheminer le trafic AEM Publish vers AEM Edge Delivery Services :

Voici un exemple de règle de sélecteur d’origine qui peut accomplir ceci :

kind: CDN
version: '1'
data:
  originSelectors:
    rules:
      - name: select-edge-delivery-services-origin
        when:
          allOf:
            - reqProperty: tier
              equals: publish
            - reqProperty: domain
              equals: <Production Host>
            - reqProperty: path
              matches: "^^(/scripts/.*|/styles/.*|/fonts/.*|/blocks/.*|/icons/.*|.*/media_.*|/favicon.ico)"
        action:
          type: selectOrigin
          originName: aem-live
    origins:
      - name: aem-live
        domain: main--repo--owner.aem.live

Redirections côté client client-side-redirectors

Vous pouvez utiliser des règles de redirection côté client pour les redirections 301, 302 et les redirections côté client similaires. Si une règle correspond, le CDN répond avec une ligne d’état qui inclut le code d’état et le message (par exemple, HTTP/1.1 301 Déplacé définitivement), ainsi que le jeu d’en-têtes d’emplacement.

Les emplacements absolus et relatifs avec des valeurs fixes sont autorisés.

Gardez à l’esprit que la taille cumulée du fichier de configuration, y compris les règles de filtrage du trafic, ne peut pas dépasser 100 Ko.

Exemple de configuration :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  experimental_redirects:
    rules:
      - name: redirect-absolute
        when: { reqProperty: path, equals: "/page.html" }
        action:
          type: redirect
          status: 301
          location: https://example.com/page
      - name: redirect-relative
        when: { reqProperty: path, equals: "/anotherpage.html" }
        action:
          type: redirect
          location: /anotherpage