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.

Novos bundles criados usando a CLI do Databricks versão 1.3.0 e acima usam o mecanismo de implantação direta por default. Pacotes criados usando versões anteriores da CLI podem ser migrados do motor de implantação Terraform para o motor de implantação direto usando os passos de migração descritos nesta página.

importante

A Databricks recomenda migrar para o mecanismo direto, uma vez que o mecanismo de implantação do Terraform será descontinuado em breve e o mecanismo de implantação direto se tornará o default. Consulte Pacotes de Automação Declarativa em breve passarão a usar por padrão o mecanismo de implantação direta.

Quais são as 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:

  • Evita problemas com firewalls, proxies e registros de provedores personalizados.
  • Diferenças detalhadas das alterações disponíveis usando bundle plan -o json
  • Implantação mais rápida
  • Não é necessário download Terraform e terraform-provider-databricks antes da implantação.
  • Redução do tempo para lançar novos recursos de pacote, pois não há necessidade de alinhamento com um lançamento de provedor Terraform.

Como faço para começar a usar a implantação direta?​

Para começar a usar o novo mecanismo de implantação direta:

  • Para pacotes existentes, migre-os usando databricks bundle deployment migrate.
  • Para novos pacotes, implante-os com a DATABRICKS_BUNDLE_ENGINE variável de ambiente definida como direct.

Migrar um pacote existente​

O mecanismo de implantação direta usa seu próprio arquivo de estado JSON. O esquema é diferente do arquivo de estado JSON do Terraform. O comandobundle deployment migrate converte o arquivo de estado do Terrform (terraform.tfstate) no arquivo de estado de implantação direta (resources.json). O comando lê os IDs da implantação existente.

  1. Realize uma implantação completa com o Terraform:

    Bash
    databricks bundle deploy -t my_target

  2. Migrar a implantação:

    Bash
    databricks bundle deployment migrate -t my_target

  3. Verifique se a migração foi bem-sucedida. O comando databricks bundle plan deve ser executado com sucesso e não deve mostrar nenhuma alteração.

    Bash
    databricks bundle plan -t my_target

    • Se a verificação falhar, remova o novo arquivo de estado:

      Bash
      rm .databricks/bundle/my_target/resources.json

    • Se a verificação for bem-sucedida, implante o pacote para sincronizar o arquivo de estado com o workspace:

      Bash
      databricks bundle deploy -t my_target

Direct implantou um novo pacote​

O comando bundle migrate não funciona em pacotes que nunca foram implantados porque não há arquivo de estado. Em vez disso, faça uma das seguintes opções:

  • 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.

Quais são as mudanças no mecanismo de implantação direta?​

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. Especificamente, o mecanismo direto rastreia o estado local e remoto do recurso separadamente e resolve as substituições de recurso em dois passos.

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.

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