Modos de implantação de pacotes de automação declarativa

Esta página descreve a sintaxe para os modos de implantação de Pacotes de Automação Declarativa. Os pacotes permitem o gerenciamento programático do fluxo de trabalho Databricks . Veja O que são pacotes de automação declarativa?

No fluxo de trabalho 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 pré-produção, seguido por um modo de produção para entregas validadas. O Declarative Automation Bundles fornece uma coleção opcional de comportamentos default que correspondem a cada um desses modos.

Os modos de implantação são opcionais. Você pode implantar pacotes sem definir um mode ou configurar presets. Os modos de implantação são uma forma prática de aplicar um conjunto de configurações de uso comum de uma só vez.

Modo de desenvolvimento

Para implantar seu pacote no modo de desenvolvimento, adicione o mapeamento mode , definido como development, ao destino desejado. Consulte o mapeamento de destinos da configuração do pacote. Por exemplo, este alvo denominado dev é tratado como um alvo de desenvolvimento:

YAML

targets:
  dev:
    mode: development

A implantação de um alvo no modo de desenvolvimento por meio da execução do comando databricks bundle deploy -t <target-name> implementa os seguintes comportamentos, que podem ser personalizados com o uso de predefinições:

• Prefixa todos os recursos que não são implantados como arquivos ou Notebook com o prefixo [dev ${workspace.current_user.short_name}] e marca cada Job implantado e pipeline com uma tag dev Databricks.
• Marca todos os pipelines LakeFlow Spark Declarative implantados relacionados como development: true.
• Habilita o uso do --cluster-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, que substitui toda e qualquer definição de cluster existente que já esteja especificada no arquivo de configuração do pacote relacionado. Em vez de usar --cluster-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, o senhor pode definir o mapeamento cluster_id aqui, ou como um mapeamento filho do mapeamento bundle, para o ID do clustering a ser usado.
• pausa todos os programas e aciona os recursos implantados, como monitores de trabalho ou de qualidade. Para desativar a programação e os acionadores de um trabalho individual, defina schedule.pause_status como UNPAUSED.
• Permite a execução concorrente em todos os trabalhos implantados para uma iteração mais rápida. Para desativar a execução concorrente de um trabalho individual, defina max_concurrent_runs como 1.
• Desativa o bloqueio de implantação para uma 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 para true.

Modo de produção

Para implantar seu pacote em modo de produção, adicione o mapeamento mode , definido como production, ao destino pretendido. Consulte o mapeamento de destinos da configuração do pacote. Por exemplo, este alvo denominado prod é tratado como um alvo de produção:

YAML

targets:
  prod:
    mode: production

A implantação de um alvo no modo de produção por meio da execução do comando databricks bundle deploy -t <target-name> implementa os seguintes comportamentos:

• Valida se todos os pipelines LakeFlow Spark Declarative implantados relacionados estão marcados como development: false.

• Valida se o ramo atual do Git é igual ao ramo do Git especificado no destino. A especificação de uma ramificação do Git no destino é opcional e pode ser feita com uma propriedade adicional git da seguinte forma:

  YAML

  git:
    branch: main

  Essa validação pode ser substituída pela especificação de --force enquanto implantado.

• Databricks recomenda que você use entidade de serviço para implantações de produção. Você pode impor isso definindo run_as para uma entidade de serviço. Consulte entidade de serviço e Especifique uma identidade de execução para um fluxo de trabalho de Pacotes de Automação Declarativa. Caso não utilize entidade de serviço, observe os seguintes comportamentos adicionais:

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

• Diferentemente do comportamento anterior de configuração do mapeamento mode para development, a configuração do mapeamento mode para production não permite substituir nenhuma definição de agrupamento existente especificada no arquivo de configuração do pacote relacionado, por exemplo, usando a opção --compute-id <cluster-id> ou o mapeamento compute_id.

Predefinições personalizadas

O Declarative Automation Bundles oferece suporte a predefinições configuráveis para destinos, o que permite personalizar os comportamentos desses destinos. Para obter informações sobre as configurações predefinidas disponíveis, consulte a referência de configuração.

nota

A menos que uma exceção seja especificada para uma predefinição, se ambos mode e presets estiverem definidos, as predefinições substituem o comportamento do modo default e as configurações de recursos individuais substituem as predefinições. Por exemplo:

• Se o max_concurrent_runs para um Job for 10, mas o preset jobs_max_concurrent_runs estiver definido como 20, o número máximo de execuções simultâneas do Job será 10.
• Se um programar estiver definido como UNPAUSED, mas a predefinição trigger_pause_status estiver definida como PAUSED, o programar será despausado.

O exemplo a seguir mostra uma configuração de predefinições personalizadas para o alvo chamada dev:

YAML

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