Usar 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.

Para projetos do Entrega de publicação, os pipelines de configuração podem ser implantados via Cloud Manager para tipos de ambiente de desenvolvimento, preparo e produção. Os arquivos de configuração podem ser implantados em ambientes de desenvolvimento rápido (RDEs) usando a ferramenta de linha de comando.

Os pipelines de configuração também podem ser implantados por meio do Cloud Manager para Projetos do Edge Delivery.

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 compatíveis 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.

Criar e gerenciar pipelines de configuração creating-and-managing

Para obter informações sobre como criar e configurar os pipelines de configuração do Entrega de publicação, consulte 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.

Para obter informações sobre como criar e configurar pipelines de configuração do Edge Delivery, consulte o artigo Adicionar um pipeline de Edge Delivery.

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 de pastas 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 é 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 (ou pipeline) do tipo secreto, é possível que as propriedades secretas variem em cada ambiente, conforme ilustrado pela seguinte 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 é 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 é 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.

Edge Delivery Services yamls-for-eds

Os pipelines de configuração do Edge Delivery não têm ambientes de desenvolvimento, preparo e produção separados. Em ambientes de Entrega de publicação, as alterações avançam pelos níveis de desenvolvimento, preparo e produção. Por outro lado, um pipeline de configuração do Edge Delivery aplica a configuração diretamente a todos os mapeamentos de domínio registrados no Cloud Manager para um site do Edge Delivery.

Assim, implante uma estrutura de arquivo simples como:

/config
  cdn.yaml
  logForwarding.yaml

Se uma regra precisar diferir de acordo com o site do Edge Delivery, use a sintaxe when para distinguir as regras umas das outras. Por exemplo, observe que o domínio corresponde a dev.example.com no trecho abaixo, que pode ser diferenciado do domínio 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

Ao incluir o campo de metadados envTypes, somente o valor prod deve ser usado (a omissão do campo de metadados envTypes também é boa). Para a tier reqProperty, somente o valor publish deve ser usado.

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.

Observe que as variáveis de ambiente secretas são usadas para publicar projetos de entrega; consulte a seção Variáveis de pipeline secretas para projetos Edge Delivery Services.

O trecho a seguir é 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"

Para obter detalhes sobre como usar variáveis de ambiente, consulte Variáveis de ambiente do Cloud Manager.

Variáveis de pipeline secretas secret-pipeline-vars

Para Projetos Edge Delivery Services, use variáveis de pipeline do Cloud Manager do tipo segredo para que informações confidenciais não precisem ser armazenadas no controle do código-fonte. A caixa de seleção Etapa Aplicada deve usar a opção implantar.

A sintaxe é idêntica ao trecho mostrado na seção anterior.

Para obter detalhes sobre como usar variáveis de pipeline, consulte Variáveis de pipeline no Cloud Manager.