Compartilhar via

Modos de implantação do Pacote de Ativos do Databricks

  • Artigo

Este artigo descreve a sintaxe usada para os modos de implantação do Pacote de Ativos do Databricks. Os pacotes permitem o gerenciamento programático de fluxos de trabalho do Azure Databricks. Confira O que são Pacotes de Ativos do Databricks?

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 entregas validadas. Os Pacotes de Ativos do Databricks fornecem uma coleção opcional de comportamentos padrão que correspondem a cada um desses modos. Para usar esses comportamentos para um destino em específico, defina um mode ou configure presets para um destino na configuração de mapeamento de targets. Para obter mais informações sobre targets, confira o mapeamento de destinos na configuração do pacote.

Modo de desenvolvimento

Para implantar seu pacote no modo de desenvolvimento, primeiro adicione o mapeamento mode, definido como development, ao destino pretendido. Por exemplo, este destino chamado dev é tratado como um destino de desenvolvimento:

targets:
  dev:
    mode: development

A implantação de um destino no modo de desenvolvimento, com a execução do comando databricks bundle deploy -t <target-name>, implementa os comportamentos apresentados a seguir, que podem ser personalizados ao usar configurações prévias:

  • Prefixa todos os recursos que não são implantados como arquivos ou notebooks com [dev ${workspace.current_user.short_name}] e marca cada trabalho e pipeline implantado com uma marca dev do Azure Databricks.
  • Marca todos os pipelines do Delta Live Tables implantados relacionados como development: true. Confira Usar o modo de desenvolvimento para executar atualizações de pipeline.
  • Permite o uso de --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, você pode definir o mapeamento compute_id aqui, ou como um mapeamento filho do mapeamento bundle, como a ID do cluster a ser usada.
  • Pausa todos os agendamentos e gatilhos em recursos implantados, como trabalhos ou monitores de qualidade. Retoma os agendamentos e gatilhos de um trabalho individual por meio da configuração de schedule.pause_status como UNPAUSED.
  • Permite execuções simultâneas em todos os trabalhos implantados para oferecer uma iteração mais rápida. Desabilita as execuções simultâneas de um trabalho individual por meio da configuração de max_concurrent_runs como 1.
  • Desabilita o bloqueio de implantação para oferecer uma iteração mais rápida. Esse bloqueio evita conflitos de implantação que provavelmente não ocorrerão no modo de desenvolvimento. Reabilita o bloqueio por meio da configuração de bundle.deployment.lock.enabled como true.

Modo de produção

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

targets:
  prod:
    mode: production

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

  • Valida se todos os pipelines do Delta Live Tables implantados relacionados estão marcados como development: false.

  • Valida se o GIT branch atual é igual ao GIT branch especificado no destino. Especificar um GIT branch no destino é opcional e pode ser feito com uma propriedade git adicional 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 a uma entidade de serviço. Consulte Gerenciar entidades de serviço e Especificar uma identidade de execução em um fluxo de trabalho do Databricks Asset Bundles. Caso você não use entidades 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 para um usuário 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 mapeamento de mode para development, definir o mapeamento de mode para production não permite substituir as definições de cluster existentes especificadas no arquivo de configuração do pacote relacionado, por exemplo, usando a opção --compute-id <cluster-id> ou o mapeamento de compute_id.

Configurações prévias personalizadas

Os Pacotes de Ativos do Databricks oferecem suporte para configurações prévias configuráveis para destinos, o que permite personalizar os comportamentos para os destinos. As configurações prévias disponíveis estão listadas na tabela a seguir:

Predefinição Descrição
name_prefix A sequência de prefixo a ser adicionada aos nomes dos recursos.
pipelines_development Indica 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 pausar a ser aplicado a todos os acionamentos e agendamentos. Os valores válidos são PAUSED ou UNPAUSED.
jobs_max_concurrent_runs O número máximo de execuções simultâneas permitido para trabalhos.
tags Um conjunto de rótulos key:value aplicável a todos os recursos que oferecem suporte para rótulos, que inclui trabalhos e experimentos. Os Pacotes de Ativos do Databricks não oferecem suporte aos rótulos para o recurso schema.

Observação

Caso tanto mode quanto presets estejam configurados, as configurações prévias realizam a substituição do comportamento padrão do modo, e as configurações de recursos individuais realizam a substituição das configurações prévias. Por exemplo, se um agendamento estiver definido como UNPAUSED, mas a configuração prévia trigger_pause_status estiver configurada como PAUSED, o agendamento será retomado.

O exemplo apresentado a seguir mostra uma configuração de configurações prévias personalizadas 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