Przejść do systemu wdrażania bezpośredniego

Pakiety zasobów Databricks zostały pierwotnie utworzone na podstawie dostawcy Terraform Databricks do zarządzania wdrożeniami. Jednak w celu uniezależnienia się od tej zależności, Databricks CLI w wersji 0.279.0 lub nowszej obsługuje dwa różne mechanizmy wdrażania: terraform i direct. Silnik wdrażania bezpośredniego nie zależy od narzędzia Terraform i niedługo stanie się domyślną opcją. Silnik wdrażania Terraform zostanie w końcu wycofany z użycia.

Jakie są zalety wdrożenia bezpośredniego?

Nowy aparat wdrażania bezpośredniego używa Databricks Go SDK i zapewnia następujące korzyści:

• Nie trzeba pobierać programu Terraform i terraform-provider-databricks przed wdrożeniem
• Pozwala uniknąć problemów z zaporami, serwerami proxy i rejestrami dostawców niestandardowych
• Szczegółowe różnice zmian są dostępne za pomocą bundle plan -o json
• Szybsze wdrażanie
• Skrócony czas wydawania nowych zasobów pakietu, ponieważ nie ma potrzeby dopasowywania do wydania dostawcy programu Terraform

Jak rozpocząć korzystanie z wdrożenia bezpośredniego?

Aby rozpocząć korzystanie z nowego silnika wdrażania bezpośredniego:

• W przypadku istniejących pakietów zmigruj je przy użyciu polecenia databricks bundle deployment migrate.
• W przypadku nowych pakietów wdróż je przy użyciu zmiennej środowiskowej ustawionej DATABRICKS_BUNDLE_ENGINE na wartość direct.

Migrowanie istniejącego pakietu

Aparat wdrażania bezpośredniego używa własnego pliku stanu JSON. Schemat różni się od pliku stanu JSON programu Terraform. Polecenie bundle deployment migrate konwertuje plik stanu Terraform (terraform.tfstate) na plik stanu bezpośredniego wdrożenia (resources.json). Polecenie odczytuje identyfikatory z istniejącego wdrożenia.

1. Wykonaj pełne wdrożenie za pomocą narzędzia Terraform:

   databricks bundle deploy -t my_target
   

2. Migrowanie wdrożenia:

   databricks bundle deployment migrate -t my_target
   

3. Sprawdź, czy migracja zakończyła się pomyślnie. Polecenie databricks bundle plan powinno zakończyć się powodzeniem, i nie powinno pokazywać żadnych zmian.

   databricks bundle plan -t my_target
   

   • Jeśli weryfikacja nie powiodła się, usuń nowy plik stanu:

     rm .databricks/bundle/my_target/resources.json
     

   • Jeśli weryfikacja zakończyła się pomyślnie, wdróż pakiet, aby zsynchronizować plik stanu z obszarem roboczym:

     databricks bundle deploy -t my_target
     

Bezpośrednie wdrażanie nowego pakietu

Polecenie bundle migrate nie działa w przypadku pakietów, które nigdy nie zostały wdrożone, ponieważ nie ma pliku stanu. Zamiast tego ustaw zmienną środowiskową DATABRICKS_BUNDLE_ENGINE i wdróż:

DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

Jakie są zmiany w silniku wdrażania bezpośredniego?

Nowy aparat wdrażania bezpośredniego działa głównie tak samo jak aparat wdrażania Terrform, ale istnieją pewne różnice.

Obliczanie różnic stanu zasobu

W przeciwieństwie do programu Terraform, który utrzymuje jeden stan zasobu (połączenie konfiguracji lokalnej i stanu zdalnego), nowy silnik przechowuje je oddzielnie i rejestruje tylko konfigurację lokalną w swoim pliku stanu.

Obliczanie różnic stanu zasobów odbywa się w dwóch krokach:

1. Konfiguracja pakietu lokalnego jest porównywana z konfiguracją migawki używaną do ostatniego wdrożenia. Stan zdalny nie odgrywa żadnej roli.
2. Stan zdalny jest porównywany z konfiguracją migawki używaną do ostatniego wdrożenia.

Wynikiem jest to, że:

• databricks.yml zmiany zasobów nigdy nie są ignorowane i zawsze wyzwalają aktualizację.
• Pola zasobów, które nie są obsługiwane przez implementację, nie powodują niespójnego błędu wyniku. Te zasoby są wdrażane pomyślnie przez silnik bezpośredni, ale może to spowodować odchylenie. Wdrożone zasoby są aktualizowane podczas następnego planu lub wdrażania.

wyszukiwanie zamienników dla $resources

Najczęstszym zastosowaniem $resources jest rozpoznawanie identyfikatorów podstawiania (na przykład $resources.jobs.my_job.id), które zachowują się identycznie między mechanizmami Terraform a bezpośrednimi mechanizmami wdrożeniowymi.

Jednak rozwiązywanie podstawienia $resources w silniku bezpośredniego wdrażania (na przykład $resources.pipelines.my_pipeline.name) jest wykonywane w dwóch krokach.

1. Odwołania do pól, które znajdują się w konfiguracji lokalnej, są rozwiązywane na wartości podane w tej konfiguracji.
2. Odwołania, które nie znajdują się w konfiguracji lokalnej, są rozpoznawane ze stanu zdalnego. Jest to stan pobrany przy użyciu odpowiedniego GET żądania dla danego zasobu.

Schemat używany do $resource rozwiązania jest dostępny w pliku out.fields.txt. Pola oznaczone jako ALL i STATE mogą być używane do rozpoznawania lokalnego. Pola oznaczone jako ALL lub REMOTE mogą być używane do zdalnego rozpoznawania.