Databricks modos de implantação do ativo Bundle

Este artigo descreve a sintaxe dos modos de implantação do pacote ativoDatabricks . Os pacotes permitem o gerenciamento programático do Databricks fluxo de trabalho. Veja o que são Databricks ativo Bundles?

No CI/CD fluxo de trabalho, 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 O ativo Bundles fornece uma coleção opcional de comportamentos default que correspondem a cada um desses modos. Para usar esses comportamentos para um alvo específico, defina mode ou configure presets para um alvo no mapeamento de configuração targets. Para obter informações sobre targets, consulte o mapeamento de alvos de configuração de pacotes.

Modo de desenvolvimento

Para implantar o pacote no modo de desenvolvimento, o senhor deve primeiro adicionar o mapeamento mode, definido como development, ao destino pretendido. Por exemplo, esse alvo chamado 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 DLT implantados relacionados como development: true.
• Habilita o uso do --compute-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 --compute-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, o senhor pode definir o mapeamento compute_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 o pacote no modo de produção, o senhor deve primeiro adicionar o mapeamento mode, definido como production, ao destino pretendido. Por exemplo, esse alvo chamado 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 DLT 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 o senhor use a entidade de serviço para implementações de produção. O senhor pode impor isso definindo run_as para 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 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

Databricks O ativo Bundles oferece suporte a predefinições configuráveis para alvos, o que permite que o senhor personalize os comportamentos dos alvos. As predefinições disponíveis estão listadas na tabela a seguir:

Preset	Descrição
name_prefix	As cadeias de caracteres de prefixo a serem anexadas aos nomes de recurso.
pipelines_development	Se o pipeline está ou não em modo de desenvolvimento. Os valores válidos são true ou false.
trigger_pause_status	Um status de pausa a ser aplicado a todos os acionadores e programadores. Os valores válidos são PAUSED ou UNPAUSED.
jobs_max_concurrent_runs	O número máximo de execuções concorrente permitidas para o trabalho.
tags	Um conjunto de key que se aplicam a todos os recursos que suportam tags, o que inclui trabalhos e experimentos. Databricks ativo Os pacotes não suportam tags para o recurso schema.
source_linked_deployment	Reservado para uso futuro. Se o recurso criado durante a implementação aponta ou não para os arquivos de origem em workspace em vez de suas cópias em workspace.

nota

Se ambos mode e presets estiverem definidos, as predefinições substituirão o comportamento do modo default e as configurações dos recursos individuais substituirão as predefinições. Por exemplo, se um programar estiver definido como UNPAUSED, mas a predefinição trigger_pause_status estiver definida como PAUSED, o programar não será pausado.

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