Compartilhar via


Migrar para o mecanismo de implantação direta

Importante

Esse recurso é experimental.

Os Pacotes de Ativos do Databricks foram originalmente criados com base no provedor Terraform do Databricks para gerenciar implantações. No entanto, em um esforço para se afastar dessa dependência, a CLI do Databricks versão 0.279.0 e superior dá suporte a dois mecanismos de implantação diferentes: terraform e direto. O mecanismo de implantação direta não depende do Terraform e logo se tornará o padrão. O mecanismo de implantação do Terraform eventualmente será descontinuado.

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

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

  • Nenhum requisito para baixar o Terraform e terraform-provider-databricks antes da implantação
  • Evita problemas com firewalls, proxies e registros de provedor personalizados
  • Diferenças detalhadas de alterações disponíveis usando bundle plan -o json
  • Implantação mais rápida
  • Tempo reduzido para liberar novos recursos de pacote, pois não é necessário se alinhar com a versão do provedor Terraform.

Como 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 variável de DATABRICKS_BUNDLE_ENGINE 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ê IDs da implantação existente.

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

    databricks bundle deploy -t my_target
    
  2. Migre a implantação:

    databricks bundle deployment migrate -t my_target
    
  3. Verifique se a migração foi bem-sucedida. O databricks bundle plan comando deve ter êxito e não deve mostrar nenhuma alteração.

    databricks bundle plan -t my_target
    
    • Se a verificação falhar, remova o novo arquivo de estado:

      rm .databricks/bundle/my_target/resources.json
      
    • Se a verificação tiver sido bem-sucedida, implante o pacote para sincronizar o arquivo de estado no workspace:

      databricks bundle deploy -t my_target
      

Implantar um novo pacote diretamente

O bundle migrate comando não funciona em pacotes que nunca foram implantados porque não há nenhum arquivo de estado. Em vez disso, defina a variável de DATABRICKS_BUNDLE_ENGINE ambiente e implante:

DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

Quais são as alterações no mecanismo de implantação direta?

O novo mecanismo de implantação direta se comporta principalmente da mesma forma que o mecanismo de implantação do Terrform, mas há algumas diferenças.

Cálculo da diferença de estado do recurso

Ao contrário do Terraform, que mantém um único estado de recurso (uma combinação de configuração local e estado remoto), o novo mecanismo mantém essas configurações separadas e apenas registra a configuração local em seu arquivo de estado.

O cálculo de diferenciação de estado de recursos é feito em duas etapas:

  1. A configuração do pacote local é comparada à configuração de instantâneo usada para a implantação mais recente. O estado remoto não desempenha nenhum papel.
  2. O estado remoto é comparado com a configuração instantânea usada para a implantação mais recente.

O resultado é que:

  • databricks.yml as alterações de recurso nunca são ignoradas e sempre dispararão uma atualização.
  • Os campos de recurso não tratados pela implementação não disparam um erro de resultado inconsistente. Esses recursos são implantados com êxito pelo mecanismo direto, mas isso pode resultar em um desvio. Os recursos implantados são atualizados durante o próximo plano ou implantação.

pesquisa de substituição $resources

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

No entanto, a resolução da $resources substituição no mecanismo de implantação direta (por exemplo, $resources.pipelines.my_pipeline.name) é executada 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. Esse é o estado buscado usando a solicitação apropriada GET para um determinado recurso.

O esquema usado para a $resource resolução está disponível 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.