Pular para o conteúdo principal
Última atualização em

Migre para o mecanismo de implantação direta.

Pacotes de Automação Declarativa foi construído originalmente sobre o Provedor Databricks Terraform para gerenciar implementações. No entanto, as versões 0.279.0 e superiores da CLI do Databricks suportam dois mecanismos de implantação diferentes: *terraform* e *direct*. O mecanismo de implantação direta oferece vantagens significativas e não depende do Terraform.

New bundles created using Databricks CLI version 1.3.0 and acima use the direct deployment engine by default. Bundles still using the Terraform deployment engine are automatically migrated to the direct engine, so no configuration is required. See Começar using direct deployment.

Para evitar a migração automática, defina bundle.engine: terraform ou DATABRICKS_BUNDLE_ENGINE=terraform. Isso evita a migração automática em todas as versões da CLI do Databricks. Nas versões da CLI do Databricks até 1.19, o mecanismo do Terraform continua sendo usado. Na versão 1.20.0 e acima da CLI do Databricks, isso resulta em um erro. Consulte Implantação direta de um novo pacote.

importante

Na versão 1.20.0 da CLI do Databricks, o mecanismo de implantação do Terraform foi removido. A CLI do Databricks ainda pode migrar automaticamente bundles com o estado do Terraform para o mecanismo direto, mas se a migração automática falhar, a implantação será abortada. Para continuar usando o mecanismo de implantação do Terraform, faça o pin para a versão 1.19 da CLI do Databricks. Consulte Os Pacotes de Automação Declarativa usarão em breve o mecanismo de implantação direta por default.

Vantagens da implantação direta​

O novo mecanismo de implantação direta usa o SDK do Databricks para Go e apresenta os seguintes benefícios:

  • Implantações mais rápidas : As implantações de pacotes são até 40% mais rápidas.
  • Validação e planejamento mais poderosos e detalhados : Diffs detalhados de alterações usando relatórios bundle plan -o json de detalhes por campo explicando o que acionou uma determinada ação.
  • Planos reproduzíveis : bundle deploy --plan plan.json executa um plano criado anteriormente, garantindo que apenas ações aprovadas cheguem à produção e implantações mais rápidas, pois o cálculo do plano é ignorado.
  • **Configuração simples**: Problemas com firewalls, proxies e registros de provedores personalizados são evitados.
  • Mais recursos : recursos adicionais, como catálogos, locais externos, Endpoints de pesquisa AI e Genie spaces, são suportados.
  • Pastas imutáveis : os ativos podem, opcionalmente, ser implantados em uma pasta imutável e somente leitura para proteção contra adulteração e consistência de implantação. Consulte immutable_folder.

Começar a usar a implantação direta​

O mecanismo de implantação direto é o default para novos pacotes criados com a CLI do Databricks versão 1.3.0 e acima. Na CLI do Databricks versão 1.14 e superior, os pacotes que usam o mecanismo Terraform são migrados automaticamente para o mecanismo direto na implantação.

Nas versões 1,8 e acima da CLI do Databricks, você pode migrar um bundle para o mecanismo direto definindo engine: direct. Consulte Implantar diretamente um novo pacote.

Implantar diretamente um novo pacote​

Para definir o mecanismo de implantação direta explicitamente, faça o seguinte:

  • Defina bundle.engine no seu arquivo databricks.yml:

    YAML
    bundle:
      engine: direct

  • Defina a DATABRICKS_BUNDLE_ENGINE variável de ambiente e implantada:

    Bash
    DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

Se tanto a configuração quanto a variável de ambiente estiverem definidas, a configuração terá precedência.

Comparação de Mecanismos de Implantação​

O novo mecanismo de implantação direta funciona praticamente da mesma forma que o mecanismo de implantação do Terrform, mas existem algumas diferenças.

Cálculo da diferença de estado do recurso​

Diferentemente do Terraform, que mantém um único estado de recurso (uma mistura de configuração local e estado remoto), o novo mecanismo mantém esses elementos separados e registra apenas a configuração local em seu arquivo de estado.

O cálculo da diferença de estado do recurso é feito em duas etapas:

  1. A configuração do pacote local é comparada à configuração do Snapshot usada na implantação mais recente. O Estado remoto não desempenha nenhum papel.
  2. O estado remoto é comparado à configuração do Snapshot usada na implantação mais recente.

O resultado é que:

  • databricks.yml As alterações nos recursos nunca são ignoradas e sempre acionarão uma atualização.
  • Os campos recurso não tratados pela implementação não geram um erro de resultado inconsistente. Esses recursos são implantados com sucesso pelo motor direto, mas isso pode resultar em uma deriva. Os recursos de implante são atualizados durante o próximo planejamento ou implante.

Configurações removidas​

Os dois motores lidam com as configurações que o senhor remove da sua configuração de pacote de forma diferente:

  • Com o mecanismo Terraform, remover um campo definido do seu databricks.yml deixa o valor correspondente inalterado na plataforma. O Terraform só gerencia campos que estão explicitamente presentes na configuração, então um campo removido mantém o valor que tinha no momento do último deployment.
  • Com o motor direto, remover um campo definido do seu databricks.yml reverte o valor para o default do recurso. Como o mecanismo direto compara sua configuração local com o Snapshot anterior, um campo que não está mais presente é tratado como uma alteração, e o recurso é atualizado para seu valor default no próximo deployment.

Para persistir um valor, defina-o explicitamente na sua configuração em vez de depender do valor previamente implantado.

Pesquisa de substituição de recurso​

Substituições de recursos estão disponíveis para resolver IDs de recursos, por exemplo, ${resources.jobs.my_job.id}. Veja Substituições. A resolução de substituições de recursos no mecanismo de implantação direta é realizada em duas etapas:

  1. As referências que apontam para campos presentes na configuração local são resolvidas para o valor fornecido na configuração local.
  2. As referências que não estão presentes na configuração local são resolvidas a partir do estado remoto. Este é o estado obtido usando a solicitação GET apropriada para um determinado recurso.

O esquema usado para resolver uma substituição ${resource.*} está no arquivo out.fields.txt. Os campos marcados como ALL e STATE podem ser usados para resolução local. Os campos marcados como ALL ou REMOTE podem ser usados para resolução remota.

Compatibilidade de recurso​

Os recursos a seguir exigem o mecanismo de implantação direta e não são compatíveis com o mecanismo de implantação do Terraform:

Além disso, o campo lifecycle.started está disponível apenas no mecanismo de implantação direta e somente para apps, clusters e sql_warehouses. Quando definido como true, ele implanta o recurso em modo iniciado. Consulte ciclo de vida.

Nesta página