Modos de Implementação de Pacotes de Automação Declarativa

Esta página descreve a sintaxe para os modos de implementação do Declarative Automation Bundles. Os pacotes permitem o gerenciamento programático de fluxos de trabalho do Azure Databricks. Veja o que são os Pacotes de Automação Declarativa?

Em fluxos de trabalho de CI/CD, os desenvolvedores normalmente codificam, testam, implantam e executam soluções em várias fases ou modos. Por exemplo, o conjunto mais simples de modos inclui um modo de desenvolvimento para validação de pré-produção, seguido por um modo de produção para produtos validados. Os Pacotes de Automação Declarativa fornecem uma coleção opcional de comportamentos padrão que correspondem a cada um destes modos.

Os modos de implantação são opcionais. Pode implementar bundles sem definir a mode ou configurar presets. Os modos de implementação são úteis para aplicar, de uma só vez, um conjunto de parâmetros frequentemente utilizados.

Modo de desenvolvimento

Para implementar o seu bundle em modo de desenvolvimento, adicione o mode mapeamento, definido para development, ao alvo pretendido. Ver mapeamento de alvos de configuração de pacotes. Por exemplo, esse destino nomeado dev é tratado como um destino de desenvolvimento:

targets:
  dev:
    mode: development

A implantação de um destino no modo de desenvolvimento executando o databricks bundle deploy -t <target-name> comando implementa os seguintes comportamentos, que podem ser personalizados usando predefinições:

• Antecipe todos os recursos que não são implantados como ficheiros ou notebooks com o prefixo [dev ${workspace.current_user.short_name}] e marque cada tarefa e pipeline implantados com uma etiqueta dev do Azure Databricks.
• Marca todos os Lakeflow Spark Declarative Pipelines relacionados implantados como development: true.
• Permite o uso de --cluster-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, que substitui quaisquer definições de cluster existentes já especificadas no ficheiro de configuração do pacote relacionado. Em vez de usar --cluster-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, você pode definir o mapeamento de cluster_id aqui, ou como um mapeamento filho do mapeamento de bundle, para a ID do cluster a ser usado.
• Pausa todos os agendamentos e disparadores em recursos implementados, como trabalhos ou monitores de qualidade. Retome as agendas e gatilhos para uma tarefa individual definindo schedule.pause_status como UNPAUSED.
• Permite execuções simultâneas em todos os trabalhos implantados para uma iteração mais rápida. Desative as execuções simultâneas para um trabalho individual definindo max_concurrent_runs como 1.
• Desativa o bloqueio de implantação para iteração mais rápida. Esse bloqueio evita conflitos de implantação que provavelmente não ocorrerão no modo de desenvolvimento. Reative o bloqueio definindo bundle.deployment.lock.enabled como true.

Modo de produção

Para distribuir o seu pacote em modo de produção, adicione o mapeamento mode, configurado para production, ao destino pretendido. Ver mapeamento de alvos de configuração de pacotes. Por exemplo, esse destino nomeado prod é tratado como um destino de produção:

targets:
  prod:
    mode: production

A implantação de um destino no modo de produção executando o databricks bundle deploy -t <target-name> comando implementa os seguintes comportamentos:

• Valida que todos os pipelines declarativos relacionados do Lakeflow Spark implantados estão marcados como development: false.

• Valida se a ramificação atual do Git é igual à ramificação do Git especificada no destino. A especificação de uma ramificação Git no destino é opcional e pode ser feita com uma propriedade adicional git da seguinte maneira:

  git:
    branch: main
  

  Essa validação pode ser substituída especificando --force durante a implantação.

• O Databricks recomenda que você use entidades de serviço para implantações de produção. Você pode impor isso configurando run_as como um principal de serviço. Consulte princípios de serviço e Especifique uma identidade de execução para um fluxo de trabalho de Pacotes de Automação Declarativa. Se não forem utilizados principais de serviço, observe os seguintes comportamentos adicionais:

  • Valida que artifact_path, file_path, root_path ou state_path mapeamentos não são substituídos para um utilizador específico.
  • Valida que os mapeamentos run_as e permissions são especificados para esclarecer quais identidades têm permissões específicas para implantações.

• Ao contrário do comportamento anterior para definir o mode mapeamento como development, definir o mode mapeamento como production não permite substituir quaisquer definições de cluster existentes especificadas no arquivo de configuração de pacote relacionado, por exemplo, usando a --compute-id <cluster-id> opção ou o compute_id mapeamento.

Predefinições personalizadas

Os Pacotes de Automação Declarativa suportam predefinições configuráveis para alvos, o que permite personalizar os comportamentos dos alvos. Para predefinições disponíveis, consulte a referência de configuração.

O exemplo a seguir mostra uma configuração de predefinições personalizada para o destino chamado dev:

targets:
  dev:
    presets:
      name_prefix: 'testing_' # prefix all resource names with testing_
      pipelines_development: true # set development to true for pipelines
      trigger_pause_status: PAUSED # set pause_status to PAUSED for all triggers and schedules
      jobs_max_concurrent_runs: 10 # set max_concurrent runs to 10 for all jobs
      tags:
        department: finance