Usar 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.
Para los proyectos de Publish Delivery, las canalizaciones de configuración se pueden implementar mediante Cloud Manager en los tipos de entorno de desarrollo, ensayo y producción. Los archivos de configuración se pueden implementar en entornos de desarrollo rápido (RDE) con herramientas de línea de comandos.
Las canalizaciones de configuración también se pueden implementar a través de Cloud Manager para proyectos de Edge Delivery.
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.
- Crear y administrar 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.
- Variables de canalización secretas: ejemplos de uso de variables de entorno para no revelar secretos en las configuraciones de proyectos de Edge Delivery Services.
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.
kindCDNCDNCDNCDNCDNCDNCDNCDNMaintenanceTasksMaintenanceTasksLogForwardingAPICreación y administración de canalizaciones de configuración creating-and-managing
Para obtener información sobre cómo crear y configurar canalizaciones de configuración de Publish Delivery, consulte 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.
Para obtener información sobre cómo crear y configurar canalizaciones de configuración de Edge Delivery, consulte el artículo Agregar una canalización de Edge Delivery.
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"]
kindversionenvTypesmetadata. Para Publish Delivery, los valores posibles son dev, stage, prod o cualquier combinación, y determina para qué tipos de entorno se procesa la configuración. Por ejemplo, si la matriz solo incluye dev, la configuración no se carga en entornos de ensayo o producción, aunque la configuración esté implementada allí. Para Edge Delivery, solo se debe usar un valor de 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 bien
/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, es suficiente un solo archivo YAML. 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 es 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"]
Mediante variables de entorno (o canalización) de tipo secreto, es posible que propiedades secretas varíen por entorno, como se muestra en la siguiente referencia de ${{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 es 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 es 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.
Edge Delivery Services yamls-for-eds
Las canalizaciones de configuración de Edge Delivery no tienen entornos de desarrollo, ensayo y producción independientes. En los entornos de envío de publicación, los cambios progresan en los niveles de desarrollo, ensayo y producción. Por el contrario, una canalización de configuración de Edge Delivery aplica la configuración directamente a todas las asignaciones de dominio registradas en Cloud Manager para un sitio de Edge Delivery.
Por lo tanto, implemente una estructura de archivos sencilla como:
/config
cdn.yaml
logForwarding.yaml
Si una regla necesita ser diferente para cada sitio de Edge Delivery, use la sintaxis when para distinguir las reglas entre sí. Por ejemplo, observe que el dominio coincide con dev.example.com en el siguiente fragmento de código, que se puede distinguir del dominio www.example.com.
kind: "CDN"
version: "1"
data:
trafficFilters:
rules:
# Block simple path
- name: block-path
when:
allOf:
- reqProperty: domain
equals: "dev.example.com"
- reqProperty: path
equals: '/block/me'
action: block
Si se incluye el campo de metadatos envTypes, solo se debe utilizar el valor prod (omitir el campo de metadatos envTypes también es correcto). Para tier reqProperty, solo se debe usar el valor publish.
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.
Tenga en cuenta que las variables de entorno secretas se utilizan para proyectos de Entrega de publicación; consulte la sección Variables de canalización secretas para proyectos de Edge Delivery Services.
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"
Para obtener más información sobre cómo usar variables de entorno, consulte Variables de entorno de Cloud Manager.
Variables de canalización secretas secret-pipeline-vars
Para proyectos de Edge Delivery Services, use variables de canalización de Cloud Manager de tipo secret, de modo que no sea necesario almacenar la información confidencial en el control de código fuente. El cuadro de selección Paso aplicado debe utilizar la opción implementar.
La sintaxis es idéntica al fragmento de código mostrado en la sección anterior.
Para obtener más información sobre cómo usar variables de canalización, consulte Variables de canalización en Cloud Manager.