Uso de pipelines de configuração config-pipelines

Saiba como você pode usar pipelines de configuração para implantar diferentes configurações no AEM as a Cloud Service, como configurações de encaminhamento de logs, tarefas de manutenção relacionadas à limpeza e várias configurações de CDN.

Visão geral overview

Um pipeline de configuração do Cloud Manager implanta arquivos de configuração (criados no formato YAML) em um ambiente de destino. Vários recursos do AEM as a Cloud Service podem ser configurados dessa maneira, incluindo o encaminhamento de logs, tarefas de manutenção relacionadas à limpeza e vários recursos de CDN.

Os pipelines de configuração podem ser implantados por meio do Cloud Manager para tipos de ambiente de desenvolvimento, preparo e produção em programas de produção (não sandbox). Os arquivos de configuração podem ser implantados em ambientes de desenvolvimento rápido (RDEs) usando a ferramenta de linha de comando.

As seções a seguir deste documento fornecem uma visão geral de informações importantes sobre como os pipelines de configuração podem ser usados e como as configurações para eles devem ser estruturadas. Ele descreve conceitos gerais compartilhados entre todos ou um subconjunto dos recursos compatíveis com os pipelines de configuração.

Configurações suportadas configurations

A tabela a seguir oferece uma lista abrangente dessas configurações com links para a documentação dedicada descrevendo sua sintaxe de configuração distinta e outras informações.

Criação e gerenciamento de pipelines de configuração creating-and-managing

Para obter informações sobre como criar e configurar pipelines, consulte o documento Pipelines de CI/CD.

Ao criar um pipeline de configuração no Cloud Manager, selecione uma Implantação direcionada em vez de Código de pilha completa ao configurar o pipeline.

Como observado anteriormente, a configuração de RDEs é implantada usando a ferramenta de linha de comando, em vez de um pipeline.

Sintaxe comum common-syntax

Cada arquivo de configuração começa com propriedades que se assemelham ao seguinte trecho de exemplo:

  kind: "LogForwarding"
  version: "1"
  metadata:
    envTypes: ["dev"]

Você pode usar o utilitário yq para validar localmente a formatação YAML do seu arquivo de configuração (por exemplo, yq cdn.yaml).

Estrutura da pasta folder-structure

Uma pasta chamada /config ou semelhante deve estar na parte superior da árvore, com mais um arquivo YAML em algum lugar em uma árvore abaixo dela.

Por exemplo:

/config
  cdn.yaml

ou

/config
  /dev
    cdn.yaml

Os nomes de pasta e arquivos abaixo de /config são arbitrários. Entretanto, o arquivo YAML deve incluir um valor de propriedade kind válido.

Normalmente, as configurações são implantadas em todos os ambientes. Se todos os valores de propriedade forem idênticos para cada ambiente, um único arquivo YAML será suficiente. No entanto, é comum que os valores de propriedade sejam diferentes entre os ambientes, por exemplo, ao testar um ambiente mais baixo.

As seções a seguir ilustram algumas estratégias para estruturar seus arquivos.

Um único arquivo de configuração para todos os ambientes single-file

A estrutura do arquivo será semelhante ao seguinte:

/config
  cdn.yaml
  logForwarding.yaml

Use essa estrutura quando a mesma configuração for suficiente para todos os ambientes e para todos os tipos de configuração (CDN, encaminhamento de logs etc.). Neste cenário, a propriedade de matriz envTypes incluiria todos os tipos de ambiente.

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

Usando variáveis de ambiente do tipo secreto, é possível que propriedades secretas variem de acordo com o ambiente, conforme ilustrado pela referência ${{SPLUNK_TOKEN}}

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

Um Arquivo Separado Por Tipo De Ambiente file-per-env

A estrutura do arquivo será semelhante ao seguinte:

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

Use esta estrutura quando houver diferenças nos valores de propriedade. Nos arquivos, é de se esperar que o valor da matriz envTypes corresponda ao sufixo, por exemplo
cdn-dev.yaml e logForwarding-dev.yaml com um valor de ["dev"], cdn-stage.yaml e logForwarding-stage.yaml com um valor de ["stage"], e assim por diante.

Uma Pasta Por Ambiente folder-per-env

Nesta estratégia, há uma pasta config separada por ambiente, com um pipeline separado declarado no Cloud Manager para cada uma.

Essa abordagem é particularmente útil se você tiver vários ambientes de desenvolvimento, em que cada um tem valores de propriedade exclusivos.

A estrutura do arquivo será semelhante ao seguinte:

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

Uma variação dessa abordagem é manter uma ramificação separada por ambiente.

Variáveis de ambiente secreto secret-env-vars

Para que informações confidenciais não precisem ser armazenadas no controle do código-fonte, os arquivos de configuração dão suporte a variáveis de ambiente do Cloud Manager do tipo secret. Para algumas configurações, incluindo o encaminhamento de logs, as variáveis de ambiente secretas são obrigatórias para determinadas propriedades.

O trecho abaixo é um exemplo de como a variável de ambiente secreta ${{SPLUNK_TOKEN}} é usada na configuração.

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

Consulte o documento Variáveis de ambiente do Cloud Manager para obter detalhes sobre como usar as variáveis de ambiente.