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 RDE no son compatibles.

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.

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.

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"]

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.