Migrar para o motor de implementação direta

Os Pacotes de Automação Declarativa foram originalmente construídos sobre o fornecedor Databricks Terraform para gerir implementações. No entanto, as versões 0.279.0 e superiores do Databricks CLI suportam dois motores de implementação diferentes: terraform e direct. O motor de implementação direta oferece vantagens significativas e não depende do Terraform.

Os novos pacotes criados com a versão 1.3.0 ou superior da CLI do Databricks utilizam, por defeito, o motor de implementação direta. Os bundles que ainda utilizam o motor de implementação Terraform são automaticamente migrados para o motor direto, pelo que não é necessária qualquer configuração. Veja como começar a usar a implementação direta.

Para evitar a migração automática, defina bundle.engine: terraform ou DATABRICKS_BUNDLE_ENGINE=terraform. Isto impede a migração automática em todas as versões da CLI Databricks. Nas versões da CLI Databricks até à 1.19, o motor Terraform continua a ser utilizado. Na versão 1.20.0 do Databricks CLI e superior, resulta num erro. Veja Implementação direta de um novo pacote.

Importante

Na versão 1.20.0 da CLI do Databrick, o motor de implementação do Terraform foi removido. A CLI Databricks ainda pode migrar automaticamente bundles com estado Terraform para o motor direto, mas se a migração automática falhar, a implementação é abortada. Para continuar a usar o motor de implementação do Terraform, fixe na versão 1.19 da CLI do Databricks. Ver Declarative Automation Bundles em breve utilizarão por defeito o motor de implementação direta.

Vantagens de implantação direta

O novo motor de implementação direta utiliza o SDK Databricks Go e tem os seguintes benefícios:

  • Implementações mais rápidas: As implementações em bundles são até 40% mais rápidas.
  • Validação e planeamento mais poderosos e detalhados: Diferenças detalhadas das alterações usando bundle plan -o json relatórios por campo que explicam o que desencadeou uma determinada ação.
  • Planos reutilizáveis: bundle deploy --plan plan.json executa um plano previamente criado, garantindo que apenas as ações aprovadas sejam aplicadas em produção e implantações mais rápidas, uma vez que o cálculo do plano é omitido.
  • Configuração simples: Problemas com firewalls, proxies e registos personalizados de fornecedores são evitados.
  • Mais recursos: São suportados recursos adicionais como catálogos, localizações externas, endpoints de pesquisa por IA e espaços Genie.
  • Pastas imutáveis: Os recursos podem, opcionalmente, ser implementados numa pasta imutável, apenas de leitura, para proteção contra adulterações e consistência da implementação. Vê immutable_folder.

Comece a usar a implementação direta

O motor de implementação direta é o padrão para novos bundles criados com Databricks CLI versão 1.3.0 e superior. Na versão 1.14 e posteriores da CLI do Databricks, bundles que utilizam o motor Terraform são automaticamente migrados para o motor direto na implementação.

Nas versões 1.8 e superiores da CLI do Databricks, pode migrar um bundle para o motor direto definindo engine: direct. Veja Implementação direta de um novo pacote.

Implantar diretamente um novo pacote

Para definir explicitamente o motor de implementação direta, execute um dos seguintes procedimentos:

  • Coloque bundle.engine no seu databricks.yml:

    bundle:
  engine: direct

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

    DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

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

Comparação de motores de implementação

O novo motor de implantação direta comporta-se maioritariamente da mesma forma que o motor de implantação Terrform, mas existem algumas diferenças.

Cálculo da diferença de estado dos recursos

Ao contrário do Terraform, que mantém um único estado de recurso (uma mistura de configuração local e estado remoto), o novo motor mantém estes estados separados e regista apenas a configuração local no seu ficheiro de estado.

O cálculo da diferença de estado dos recursos é feito em dois passos:

  1. A configuração local do bundle é comparada com a configuração snapshot usada na implementação mais recente. O estado remoto não tem qualquer papel.
  2. O estado remoto é comparado com a configuração snapshot usada na implementação mais recente.

O resultado é que:

  • databricks.yml As alterações de recursos nunca são ignoradas e vão sempre desencadear uma atualização.
  • Campos de recurso não tratados pela implementação não desencadeiam um erro de resultado inconsistente. Estes recursos são implementados com sucesso pelo motor direto, mas isso pode resultar numa deriva. Os recursos destacados são atualizados durante o próximo plano ou implementação.

Definições de configuração removidas

Os dois mecanismos tratam de forma diferente as definições que remove da configuração do pacote:

  • Com o motor do Terraform, ao remover um campo definido explicitamente do seu databricks.yml, o valor correspondente permanece inalterado na plataforma. O Terraform só gere campos que estão explicitamente presentes na configuração, por isso um campo removido mantém o valor que tinha na altura da última implementação.
  • Com o motor direto, remover um campo definido do teu databricks.yml reverte o valor para o padrão do recurso. Como o motor direto compara a sua configuração local com o snapshot anterior, um campo que já não está presente é tratado como uma alteração, e o recurso é atualizado para o seu valor padrão na próxima implementação.

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

Procura de substituição de recursos

Existem substituições de recursos disponíveis para resolver IDs de recursos, por exemplo, ${resources.jobs.my_job.id}. Ver Substituições. A resolução das substituições de recursos no motor de implementação direta é realizada em dois passos:

  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. 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 o pedido apropriado GET para um dado recurso.

O esquema utilizado para resolver uma ${resource.*} substituição encontra-se no ficheiro 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 recursos

Os seguintes recursos requerem o motor de implementação direta e não são suportados pelo motor de implementação Terraform:

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

  • Última atualização a