Modos de implantação do pacote ativo do Databricks

Este artigo descreve a sintaxe dos modos de implantação do Databricks ativo Bundle . Os pacotes permitem o gerenciamento programático do fluxo de trabalho do Databricks. Consulte O que são pacotes Databricks ativos?

No fluxo 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 entregas validadas. Databricks ativo Bundles fornece uma coleção opcional de comportamentos default que correspondem a cada um desses modos. Suas implantações de pacote configurável podem usar esses comportamentos com uma declaração de modo de uma linha, em vez de especificar manualmente esses comportamentos default no arquivo de configuração do pacote configurável – e talvez esquecer de adicionar ou configurar um ou mais comportamentos pretendidos ao longo do caminho.

Modo de desenvolvimento

Para implantar seu pacote no modo de desenvolvimento, você deve primeiro adicionar o mapeamento mode , definido como development, ao destino pretendido. Por exemplo, este alvo denominado dev é tratado como um alvo de desenvolvimento:

targets:
  dev:
    mode: development

implantar um destino de desenvolvimento executando o comando databricks bundle deploy -t <target-name> implementa os seguintes comportamentos:

Acrescenta todos os recursos que não são implantados como arquivos ou Notebook com o prefixo [dev ${workspace.current_user.userName}] e tags s cada Job e pipeline implantado com dev tags do Databricks .
Marca todos os pipeline Delta Live Tables implantados relacionados como development: true. Consulte Usar o modo de desenvolvimento para atualizações de pipeline de execução.
Permite o uso de --compute-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, que substitui toda e qualquer definição clusters existente que já esteja especificada no arquivo de configuração do pacote configurável relacionado. Em vez de usar --compute-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, você pode definir o mapeamento compute_id aqui, ou como um mapeamento filho do mapeamento bundle, para o ID dos clusters a serem usados.
pausar todos os programas e gatilhos no Job implantado relacionado.
Permite a execução simultânea em todos Job implantados relacionados.

Modo de produção

Para implantar seu pacote no modo de produção, primeiro você deve adicionar o mapeamento mode , definido como production, ao destino pretendido. Por exemplo, este destino denominado prod é tratado como um destino de produção:

targets:
  prod:
    mode: production

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

Valida que todos os pipelines Delta Live Tables implantados relacionados 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 git adicional, conforme a seguir:
```
git:
  branch: main
```
Esta validação pode ser substituída especificando --force durante a implantação.
Databricks recomenda que o senhor use a entidade de serviço para implementações de produção. O senhor pode impor isso definindo run_as como uma entidade de serviço. Consulte gerenciar entidade de serviço e Specify a execution identity for a Databricks ativo Bundles fluxo de trabalho. Se o senhor não usar a entidade de serviço, observe os seguintes comportamentos adicionais:
- Valida que 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 para definir o mapeamento mode como development, definir o mapeamento mode como production não permite substituir nenhuma definição de cluster 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.