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 utworzone przy użyciu wcześniejszych wersji CLI można migrować z mechanizmu wdrażania Terraform do mechanizmu wdrażania bezpośredniego, wykonując kroki migracji opisane na tej stronie.

Ważne

Databricks zaleca migrację do silnika bezpośredniego, ponieważ silnik wdrażania Terraform wkrótce zostanie wycofany, a silnik wdrażania bezpośredniego stanie się silnikiem domyślnym. 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.

Rozpocznij 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. Zobacz Migrowanie istniejącego pakietu.
  • Dla nowych lub istniejących bundli ustaw w konfiguracji pakietu wartość engine: direct albo ustaw zmienną środowiskową DATABRICKS_BUNDLE_ENGINE na direct. Zobacz Bezpośrednie wdrażanie nowego pakietu.

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

    Note

    Plan może zgłaszać zmiany zasobów nawet wtedy, gdy konfiguracja lokalna jest zgodna z wdrożonym zasobem. Może się tak zdarzyć, ponieważ poprzedni plik stanu programu Terraform zawiera pola metadanych wypełniane przez platformę po wdrożeniu, które nie są obecne w konfiguracji pakietu. Te różnice nie stanowią faktycznego odchylenia konfiguracji i nie zmieniają działania zadania. Silnik bezpośredni uzgadnia je przy następnym bundle deploy. Aby uzyskać szczegółowe informacje o tym, jak silnik bezpośredni oblicza różnice, zobacz Obliczanie różnic stanu zasobu.

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

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.

  • Last updated on