Przejść do systemu wdrażania bezpośredniego

Ważne

Ta funkcja jest eksperymentalna.

Pakiety deklaratywne automatyzacji zostały pierwotnie utworzone na bazie dostawcy narzędzia Terraform usługi 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. Poleceniebundle deployment migrate konwertuje plik stanu Terrform (terraform.tfstate) na plik stanu wdrożenia bezpośredniego (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 powiedzie się, usuń nowy plik stanu:

     rm .databricks/bundle/my_target/resources.json
     

   • Jeśli weryfikacja zakończy się pomyślnie, wdróż pakiet w celu zsynchronizowania pliku 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 wykonaj jedną z następujących czynności:

• Ustaw bundle.engine w swoim pliku databricks.yml:

  bundle:
    engine: direct
  

• Ustaw zmienną środowiskową DATABRICKS_BUNDLE_ENGINE i wdróż:

  DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target
  

Jeśli konfiguracja i zmienna środowiskowa są ustawione, konfiguracja ma pierwszeństwo.

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. W szczególności silnik bezpośredni śledzi lokalny i zdalny stan zasobów oddzielnie i rozwiązuje zamiany zasobów w dwóch krokach.

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 zastępstwa zasobów

Podstawianie zasobów są dostępne do rozpoznawania identyfikatorów zasobów, na przykład ${resources.jobs.my_job.id}. Zobacz Substytucje. Rozwiązanie podstawień zasobów w silniku bezpośredniego wdrażania 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 rozwiązywania zamiennika ${resource.*} znajduje się 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.