Partilhar via

Modos de implantação do Databricks Asset Bundle

  • Artigo

Este artigo descreve a sintaxe para os modos de implantação do Databricks Asset Bundle . Os pacotes permitem o gerenciamento programático de fluxos de trabalho do Azure Databricks. Consulte O que são Databricks Asset Bundles?

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 resultados validados. O Databricks Asset Bundles fornece uma coleção opcional de comportamentos padrão que correspondem a cada um desses modos. Para usar esses comportamentos para um destino específico, defina um mode ou configure presets para um destino no mapeamento de configuração targets. Para obter informações sobre targetso , consulte mapeamento de destinos de configuração de pacote.

Modo de desenvolvimento

Para implantar seu pacote no modo de desenvolvimento, você deve primeiro adicionar o mapeamento de mode, definido como development, ao destino pretendido. 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:

  • Precede todos os recursos que não são implantados como arquivos ou blocos de anotações com o prefixo [dev ${workspace.current_user.short_name}] e marca cada trabalho implantado e pipeline com uma dev marca do Azure Databricks.
  • Marca todos os pipelines relacionados implantados do Delta Live Tables como development: true.
  • Permite o uso de chamadas relacionadas ao --compute-id <cluster-id> comando, que substitui todas e quaisquer definições de cluster existentes já especificadas no arquivo de bundle deploy configuração do pacote relacionado. Em vez de usar --compute-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, você pode definir o mapeamento de compute_id aqui, ou como um mapeamento filho do mapeamento de bundle, para a ID do cluster a ser usado.
  • Pausa todas as agendas e gatilhos em recursos implantados, como trabalhos ou monitores de qualidade. Interrompa agendas e gatilhos para um trabalho 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 implantar seu pacote no modo de produção, você deve primeiro adicionar o mapeamento de mode, definido como production, ao destino pretendido. 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 relacionados do Delta Live Tables implementados 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 definindo run_as como uma entidade de serviço. Consulte Gerenciar entidades de serviço e Especificar uma identidade de execução para um fluxo de trabalho do Databricks Asset Bundles. Se você não usar entidades de serviço, observe os seguintes comportamentos adicionais:

    • Valida que artifact_path, file_path, root_pathou state_path mapeamentos não são substituídos para um usuário específico.
    • Valida que os run_as mapeamentos 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

O Databricks Asset Bundles suporta predefinições configuráveis para destinos, o que permite personalizar os comportamentos para destinos. As predefinições disponíveis estão listadas na tabela a seguir:

Predefinição Description
name_prefix A cadeia de caracteres de prefixo a ser anexada aos nomes de recursos.
pipelines_development Se o pipeline está ou não no modo de desenvolvimento. Os valores válidos são true ou false.
trigger_pause_status Um status de pausa para aplicar a todos os gatilhos e agendas. Os valores válidos são PAUSED ou UNPAUSED.
jobs_max_concurrent_runs O número máximo permitido de execuções simultâneas para trabalhos.
tags Um conjunto de etiquetas key:value que se aplica a todos os recursos que suportam etiquetas, incluindo trabalhos e experiências. Os pacotes de ativos Databricks não suportam tags para o schema recurso.
source_linked_deployment Reservado para uso futuro. Se os recursos criados durante a implantação apontam ou não para os arquivos de origem no espaço de trabalho em vez de suas cópias do espaço de trabalho.

Nota

Se mode e presets estiverem definidas, as predefinições substituirão o comportamento do modo padrão e as configurações de recursos individuais substituirão as predefinições. Por exemplo, se uma agenda estiver definida como UNPAUSED, mas a predefinição de trigger_pause_status estiver definida como PAUSED, a agenda não será pausada.

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