Przejść do systemu wdrażania bezpośredniego

Pakiety deklaratywne automatyzacji zostały pierwotnie utworzone na bazie dostawcy narzędzia Terraform usługi Databricks do zarządzania wdrożeniami. Jednak wersje Databricks CLI 0.279.0 i nowsze obsługują dwa różne mechanizmy wdrażania: terraform i direct. Mechanizm bezpośredniego wdrażania zapewnia istotne korzyści i nie zależy od Terraform.

Nowe pakiety utworzone przy użyciu interfejsu wiersza polecenia Databricks w wersji 1.3.0 lub nowszej domyślnie korzystają z mechanizmu bezpośredniego wdrażania. Pakiety nadal korzystające z silnika wdrożeniowego Terraform są automatycznie migrowane do silnika bezpośredniego, więc konfiguracja nie jest wymagana. Zobacz bezpośrednie wdrażanie.

Aby zapobiec automigracji, ustaw bundle.engine: terraform lub DATABRICKS_BUNDLE_ENGINE=terraform. Zapobiega to automatycznej migracji we wszystkich wersjach CLI Databricks. W wersjach CLI Databricks do 1.19 silnik Terraform jest nadal używany. W Databricks CLI od wersji 1.20.0 wzwyż powoduje to błąd. Zobacz Bezpośrednie wdrażanie nowego pakietu.

Ważne

W Databricks CLI w wersji 1.20.0 silnik wdrożeniowy Terraform został usunięty. Interfejs CLI Databricks nadal może automatycznie migrować pakiety ze stanem Terraform do silnika bezpośredniego, ale jeśli automatyczna migracja się nie powiedzie, wdrożenie zostaje przerwane. Aby kontynuować korzystanie z silnika wdrożeniowego Terraform, należy przypiąć Databricks CLI do wersji 1.19. Zobacz Deklaratywne pakiety automatyzacji wkrótce będą domyślnie korzystać z bezpośredniego mechanizmu wdrażania.

Zalety wdrażania bezpośredniego

Nowy mechanizm bezpośredniego wdrażania korzysta z pakietu Databricks Go SDK i zapewnia następujące korzyści:

  • Szybsze wdrożenia: wdrożenia pakietów są do 40% szybsze.
  • Bardziej zaawansowana i szczegółowa walidacja oraz planowanie: szczegółowe zestawienia różnic zmian z użyciem raportów bundle plan -o json, zawierających szczegółowe informacje dla poszczególnych pól wyjaśniające, co spowodowało dane działanie.
  • Plany wielokrotnego użycia: bundle deploy --plan plan.json uruchamia wcześniej utworzony plan, zapewniając, że do produkcji trafiają tylko zatwierdzone działania, a wdrożenia przebiegają szybciej, ponieważ pomijane jest obliczanie planu.
  • Prosta konfiguracja: unika się problemów z zaporami, serwerami proxy i niestandardowymi rejestrami dostawców.
  • Więcej zasobów: Obsługiwane są dodatkowe zasoby, takie jak katalogi, lokalizacje zewnętrzne, punkty końcowe AI Search i przestrzenie Genie.
  • Foldery niezmienne: zasoby można opcjonalnie wdrożyć w niezmiennym folderze tylko do odczytu w celu ochrony przed naruszeniami i spójności wdrażania. Zobacz immutable_folder.

Zacznij stosować bezpośrednie wdrożenie

Silnik bezpośredniego wdrożenia jest domyślnym dla nowych pakietów tworzonych z Databricks CLI w wersji 1.3.0 i wyższej. W Databricks CLI w wersji 1.14 i wyższych pakiety korzystające z silnika Terraform są automatycznie migrowane do silnika bezpośredniego podczas wdrożenia.

W Databricks CLI w wersjach 1.8 i wyższych można przenieść pakiet do silnika bezpośredniego, ustawiając engine: direct. Zobacz Bezpośrednie wdrażanie nowego pakietu.

Bezpośrednie wdrażanie nowego pakietu

Aby wyraźnie ustawić silnik bezpośredniego wdrożenia, wykonaj jedno z następujących zadań:

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

Porównanie mechanizmów wdrażania

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.

Usunięto ustawienia konfiguracji

Te dwa mechanizmy inaczej obsługują ustawienia, które usuwasz z konfiguracji pakietu:

  • W silniku Terraform usunięcie pola typu set z databricks.yml pozostawia odpowiadającą mu wartość bez zmian na platformie. Narzędzie Terraform zarządza tylko polami, które są jawnie obecne w konfiguracji, więc usunięte pole zachowuje dowolną wartość w momencie ostatniego wdrożenia.
  • W przypadku silnika bezpośredniego usunięcie ustawionego pola z elementu databricks.yml przywraca wartość domyślną zasobu. Ponieważ silnik bezpośredni porównuje konfigurację lokalną z poprzednią migawką, pole, które nie jest już obecne, jest traktowane jako zmiana, a podczas następnego wdrożenia zasób zostaje zaktualizowany do wartości domyślnej.

Aby utrwałyć wartość, ustaw ją jawnie w konfiguracji, zamiast polegać na wcześniej wdrożonej wartości.

Wyszukiwanie substytucji 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.

Zgodność zasobów

Następujące zasoby wymagają aparatu wdrażania bezpośredniego i nie są obsługiwane przez aparat wdrażania programu Terraform:

Ponadto pole lifecycle.started jest dostępne tylko w mechanizmie wdrażania bezpośredniego i tylko dla apps, clusters i sql_warehouses. Po ustawieniu na true zasób jest wdrażany w trybie uruchomionym. Zobacz cykl życia.

  • Ostatnia aktualizacja o