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: Una lista de configuraciones que se pueden implementar con canalizaciones de configuración
- Creación y administración de canalizaciones de configuración: cómo crear una canalización de configuración.
- Sintaxis común: sintaxis compartida entre configuraciones
- Estructura de carpetas: Describe la estructura que esperan las canalizaciones de configuración para las configuraciones
- Variables de entorno secretas: ejemplos de uso de variables de entorno para no revelar secretos en las configuraciones
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.
kind
CDN
CDN
CDN
CDN
CDN
CDN
CDN
MaintenanceTasks
MaintenanceTasks
LogForwarding
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"]
kind
version
envTypes
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í.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 ejemplocdn-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.