Tryby wdrażania pakietu zasobów usługi Databricks

W tym artykule opisano składnię trybów wdrażania pakietu zasobów usługi Databricks. Pakiety umożliwiają programowe zarządzanie przepływami pracy usługi Azure Databricks. Zobacz Co to są pakiety zasobów usługi Databricks?

W przepływach pracy ciągłej integracji/ciągłego wdrażania deweloperzy zazwyczaj kodować, testować, wdrażać i uruchamiać rozwiązania w różnych fazach lub trybach. Na przykład najprostszy zestaw trybów obejmuje tryb programowania na potrzeby weryfikacji przedprodukcyjnej, a następnie tryb produkcyjny dla zweryfikowanych elementów dostarczanych. Pakiety zasobów usługi Databricks udostępnia opcjonalną kolekcję domyślnych zachowań odpowiadających każdemu z tych trybów. Wdrożenia pakietów mogą używać tych zachowań z deklaracją trybu jednowierszowego, zamiast ręcznie określać te domyślne zachowania w pliku konfiguracji pakietu i być może zapominając o dodaniu lub skonfigurowaniu jednego z bardziej zamierzonych zachowań po drodze.

Tryb programowania

Aby wdrożyć pakiet w trybie programowania, należy najpierw dodać mode mapowanie ustawione na developmentwartość , do zamierzonego celu. Na przykład ten element docelowy o nazwie dev jest traktowany jako docelowy programistyczne:

targets:
  dev:
    mode: development

Wdrożenie elementu docelowego programowania przez uruchomienie databricks bundle deploy -t <target-name> polecenia implementuje następujące zachowania:

• Poprzedza wszystkie zasoby, które nie są wdrażane jako pliki lub notesy z prefiksem [dev ${workspace.current_user.userName}] i tagiem każdego wdrożonego zadania i potoku za pomocą dev tagu usługi Azure Databricks.
• Oznacza wszystkie powiązane potoki delty tabel na żywo jako development: true. Zobacz Używanie trybu programowania do uruchamiania aktualizacji potoku.
• Umożliwia użycie --compute-id <cluster-id> polecenia w powiązanych wywołaniach bundle deploy polecenia, które zastępuje wszystkie i wszystkie istniejące definicje klastra, które są już określone w powiązanym pliku konfiguracji pakietu. Zamiast używać --compute-id <cluster-id> w powiązanych wywołaniach bundle deploy polecenia, można ustawić compute_id mapowanie tutaj lub jako podrzędne mapowanie mapowania bundle na identyfikator klastra do użycia.
• Wstrzymuje wszystkie harmonogramy i wyzwalacze dla wdrożonych zasobów, takich jak zadania lub monitory jakości. Usuń harmonogramy i wyzwalacze dla pojedynczego zadania, ustawiając wartość schedule.pause_status na UNPAUSED.
• Włącza współbieżne przebiegi we wszystkich wdrożonych zadaniach w celu szybszej iteracji. Wyłącz współbieżne uruchomienia dla pojedynczego zadania, ustawiając wartość max_concurrent_runs .1
• Wyłącza blokadę wdrożenia w celu szybszej iteracji. Ta blokada uniemożliwia konflikty wdrażania, które są mało prawdopodobne, aby wystąpiły w trybie deweloperskim. Włącz ponownie blokadę, ustawiając wartość bundle.deployment.lock.enabled true.

Tryb produkcyjny

Aby wdrożyć pakiet w trybie produkcyjnym, należy najpierw dodać mode mapowanie ustawione na production, do zamierzonego celu. Na przykład ten obiekt docelowy o nazwie prod jest traktowany jako docelowy produkt produkcyjny:

targets:
  prod:
    mode: production

Wdrożenie docelowego środowiska produkcyjnego przez uruchomienie databricks bundle deploy -t <target-name> polecenia implementuje następujące zachowania:

• Sprawdza, czy wszystkie powiązane potoki tabel delty na żywo są oznaczone jako development: false.

• Sprawdza, czy bieżąca gałąź Git jest równa gałęzi Git określonej w elemencie docelowym. Określenie gałęzi Git w obiekcie docelowym jest opcjonalne i można wykonać z dodatkową git właściwością w następujący sposób:

  git:
    branch: main
  

  Tę walidację można zastąpić, określając --force podczas wdrażania.

• Usługa Databricks zaleca używanie jednostek usługi do wdrożeń produkcyjnych. Możesz to wymusić, ustawiając wartość run_as jednostki usługi. Zobacz Zarządzanie jednostkami usługi i Określanie tożsamości przebiegu dla przepływu pracy pakietów zasobów usługi Databricks. Jeśli nie używasz jednostek usługi, zwróć uwagę na następujące dodatkowe zachowania:

  • Sprawdza, czy artifact_pathmapowania , file_path, root_pathlub state_path nie są zastępowane przez określonego użytkownika.
  • Sprawdza, czy run_as określono mapowania i permissions w celu wyjaśnienia, które tożsamości mają określone uprawnienia do wdrożeń.

• W przeciwieństwie do poprzedniego zachowania podczas ustawiania mode mapowania na developmentwartość , ustawienie mode mapowania production na nie zezwala na zastępowanie istniejących definicji klastra określonych w powiązanym pliku konfiguracji pakietu, na przykład przy użyciu --compute-id <cluster-id> opcji lub compute_id mapowania.