Pular para o conteúdo principal

Migre para o mecanismo de implantação direta.

info

Experimental

Este recurso é experimental.

Databricks Ativo Bundles foi originalmente construído sobre o provedorDatabricks Terraform para gerenciar implantações. No entanto, em um esforço para se afastar dessa dependência, a versão 0.279.0 e superiores Databricks CLI suportam dois mecanismos de implantação diferentes: Terraform e implantação direta . O mecanismo de implantação direta não depende do Terraform e em breve se tornará o default. O mecanismo de implantação Terraform será eventualmente descontinuado.

Quais são as vantagens da implantação direta?

O novo mecanismo de implantação direta utiliza o SDK Databricks Go e oferece os seguintes benefícios:

  • Não é necessário download Terraform e terraform-provider-databricks antes da implantação.
  • 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
  • Tempo reduzido para liberar um novo recurso de pacote, pois não há necessidade de alinhamento com a versão do 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 comando de migração de implantação de pacote 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, defina a DATABRICKS_BUNDLE_ENGINE variável de ambiente e implantada:

Bash
DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

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.

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 recursos

O uso mais comum de $resources é a resolução de IDs de substituição (por exemplo, $resources.jobs.my_job.id), que se comporta de maneira idêntica entre os mecanismos de implantação Terraform e direta.

No entanto, a resolução da substituição $resources no mecanismo de implantação direta (por exemplo, $resources.pipelines.my_pipeline.name) é 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 a resolução de $resource está disponível 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.