Uso de canalizaciones de configuración config-pipelines

Descubra cómo puede utilizar las canalizaciones de configuración para implementar diferentes configuraciones en AEM as a Cloud Service, como la configuración de reenvío de registros, las tareas de mantenimiento relacionadas con la depuración y varias configuraciones de CDN.

Información general overview

Una canalización de configuración de Cloud Manager implementa archivos de configuración (creados en formato YAML) en un entorno de destino. Se pueden configurar varias funciones de AEM as a Cloud Service de esta manera, incluido el reenvío de registros, las tareas de mantenimiento relacionadas con la depuración y varias funciones de CDN.

Las canalizaciones de configuración se pueden implementar mediante Cloud Manager para los tipos de entorno de desarrollo, ensayo y producción en programas de producción (que no sean de zonas protegidas). Los archivos de configuración se pueden implementar en entornos de desarrollo rápido (RDE) con herramientas de línea de comandos.

Las siguientes secciones de este documento proporcionan información importante sobre cómo se pueden utilizar las canalizaciones de configuración y cómo se deben estructurar las configuraciones para ellas. Describe conceptos generales compartidos en todas las funciones o en un subconjunto de ellas compatibles con las canalizaciones de configuración.

Configuraciones compatibles configurations

La siguiente tabla ofrece una lista completa de estas configuraciones con vínculos a documentación dedicada que describe su sintaxis de configuración distinta y otra información.

Tipo
Valor YAML kind
Descripción
Reglas de filtro de tráfico, incluido WAF
CDN
Declarar reglas para bloquear el tráfico malintencionado
Solicitar transformaciones
CDN
Declarar reglas para transformar la forma de la solicitud de tráfico
Transformaciones de respuesta
CDN
Declarar reglas para transformar la forma de la respuesta de una solicitud determinada
Redirecciones del lado del cliente
CDN
Declarar redirecciones del lado del cliente de estilo 301/302
Selectores de origen
CDN
Declarar reglas para enrutar el tráfico a diferentes back-ends, incluidas las aplicaciones que no sean de Adobe
Páginas de error de CDN
CDN
AEM Anule la página de error predeterminada si no se puede alcanzar el origen de la, haciendo referencia a la ubicación del contenido estático autoalojado en el archivo de configuración
Purga de CDN
CDN
Declare las claves API de depuración utilizadas para depurar la CDN
Token HTTP de CDN administrado por el cliente
CDN
AEM Declare el valor de la clave X–Edge necesaria para llamar a la CDN de Adobe desde una CDN de cliente
Autenticación básica
CDN
Declare los nombres de usuario y contraseñas para un cuadro de diálogo de autenticación básico que proteja ciertas direcciones URL.
Tarea de mantenimiento de purga de versiones
MaintenanceTasks
AEM Optimice el repositorio de declarando reglas sobre cuándo se deben purgar las versiones de contenido
Tarea de mantenimiento de purga del registro de auditoría
MaintenanceTasks
AEM Optimizar el registro de auditoría de la para un mayor rendimiento declarando reglas sobre cuándo se deben purgar los registros
Reenvío de registros
LogForwarding
Configure los extremos y las credenciales para reenviar registros a varios destinos, incluido Azure Blob Storage, Datadog, HTTPS, Elasticsearch, Splunk)

Creación y administración de canalizaciones de configuración creating-and-managing

Para obtener información sobre cómo crear y configurar canalizaciones, consulte el documento Canalizaciones de CI/CD.

Al crear una canalización de configuración en Cloud Manager, asegúrese de seleccionar una implementación dirigida en lugar de código de pila completa al configurar la canalización.

Como se mencionó anteriormente, la configuración para RDE se implementa usando herramientas de línea de comandos en lugar de una canalización.

Sintaxis común common-syntax

Cada archivo de configuración comienza con propiedades similares al siguiente fragmento de ejemplo:

  kind: "LogForwarding"
  version: "1"
  metadata:
    envTypes: ["dev"]
Propiedad
Descripción
Predeterminado
kind
Una cadena que determina qué tipo de configuración, como reenvío de registros, reglas de filtro de tráfico o transformaciones de solicitud
Obligatorio, sin valor predeterminado
version
Una cadena que representa la versión del esquema
Obligatorio, sin valor predeterminado
envTypes
Esta matriz de cadenas es una propiedad secundaria del nodo metadata. Los valores posibles son dev, stage, prod o cualquier combinación, y determina para qué tipos de entorno se procesará la configuración. Por ejemplo, si la matriz solo incluye dev, la configuración no se cargará en entornos de ensayo o producción, aunque la configuración esté implementada allí.
Todos los tipos de entorno (dev, stage, prod)

Puede usar la utilidad yq para validar localmente el formato YAML del archivo de configuración (por ejemplo, yq cdn.yaml).

Estructura de carpetas folder-structure

Una carpeta con el nombre /config o similar debe estar en la parte superior del árbol, con uno o más archivos YAML en algún lugar del árbol debajo de ella.

Por ejemplo:

/config
  cdn.yaml

o

/config
  /dev
    cdn.yaml

Los nombres de carpeta y archivos por debajo de /config son arbitrarios. Sin embargo, el archivo YAML debe incluir un valor de propiedad kind válido.

Normalmente, las configuraciones se implementan en todos los entornos. Si todos los valores de propiedad son idénticos para cada entorno, un solo archivo YAML será suficiente. Sin embargo, es común que los valores de las propiedades difieran entre entornos, por ejemplo al probar un entorno más bajo.

Las secciones siguientes ilustran algunas estrategias para estructurar los archivos.

Un solo archivo de configuración para todos los entornos single-file

La estructura de archivos será similar a la siguiente:

/config
  cdn.yaml
  logForwarding.yaml

Utilice esta estructura cuando la misma configuración sea suficiente para todos los entornos y para todos los tipos de configuración (CDN, reenvío de registros, etc.). En este escenario, la propiedad de matriz envTypes incluiría todos los tipos de entorno.

   kind: "cdn"
   version: "1"
   metadata:
     envTypes: ["dev", "stage", "prod"]

Si se usan variables de entorno de tipo secreto, es posible que propiedades secretas varíen por entorno, tal como ilustra la referencia ${{SPLUNK_TOKEN}}

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "AEMaaCS"

Un Archivo Independiente Por Tipo De Entorno file-per-env

La estructura de archivos será similar a la siguiente:

/config
  cdn-dev.yaml
  cdn-stage.yaml
  cdn-prod.yaml
  logForwarding-dev.yaml
  logForwarding-stage.yaml
  logForwarding-prod.yaml

Utilice esta estructura cuando pueda haber diferencias en los valores de las propiedades. En los archivos, se esperaría que el valor de la matriz envTypes se correspondiera con el sufijo, por ejemplo
cdn-dev.yaml y logForwarding-dev.yaml con un valor de ["dev"], cdn-stage.yaml y logForwarding-stage.yaml con un valor de ["stage"], etc.

Una carpeta por entorno folder-per-env

En esta estrategia, hay una carpeta config independiente por entorno, con una canalización independiente declarada en Cloud Manager para cada una.

Este enfoque es especialmente útil si tiene varios entornos de desarrollo, donde cada uno tiene valores de propiedad únicos.

La estructura de archivos será similar a la siguiente:

/config/dev1
  cdn.yaml
  logForwarding.yaml
/config/dev2
  cdn.yaml
  logForwarding.yaml
/config/prod
  cdn.yaml
  logForwarding.yaml

Una variación de este enfoque es mantener una rama separada por entorno.

Variables de entorno secretas secret-env-vars

Para que la información confidencial no tenga que almacenarse en el control de código fuente, los archivos de configuración admiten variables de entorno Cloud Manager de tipo secret. En algunas configuraciones, incluido el reenvío de registros, las variables de entorno secretas son obligatorias para determinadas propiedades.

El siguiente fragmento es un ejemplo de cómo se utiliza la variable de entorno secreta ${{SPLUNK_TOKEN}} en la configuración.

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "AEMaaCS"

Consulte el documento Variables de entorno de Cloud Manager para obtener detalles sobre cómo usar variables de entorno.

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab