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 rozwoju na potrzeby weryfikacji przedprodukcyjnej, a następnie tryb produkcji dla zweryfikowanych dostarczonych elementów. Pakiety zasobów usługi Databricks udostępnia opcjonalną kolekcję domyślnych zachowań odpowiadających każdemu z tych trybów. Aby użyć tych zachowań dla określonego obiektu docelowego, ustaw mode lub skonfiguruj presets dla obiektu docelowego w mapowaniu konfiguracji targets. Aby uzyskać informacje na targetstemat programu , zobacz mapowanie elementów docelowych konfiguracji pakietu.

Tryb programowania

Aby wdrożyć pakiet w trybie deweloperskim, należy najpierw dodać mapowanie mode, ustawione na development, do docelowego miejsca. Na przykład ten element docelowy o nazwie dev jest traktowany jako docelowy programistyczne:

targets:
  dev:
    mode: development

Wdrożenie elementu docelowego w trybie programowania przez uruchomienie databricks bundle deploy -t <target-name> polecenia implementuje następujące zachowania, które można dostosować przy użyciu ustawień wstępnych:

• Poprzedza wszystkie zasoby, które nie są wdrażane jako pliki lub notesy z prefiksem [dev ${workspace.current_user.short_name}] i tagiem każdego wdrożonego zadania i potoku za pomocą dev tagu usługi Azure Databricks.
• Oznacza wszystkie powiązane wdrożone potoki Delta Live Tables jako development: true.
• 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 polecenia bundle deploy, można ustawić mapowanie compute_id tutaj lub jako mapowanie podrzędne mapowania bundle na identyfikator klastra, który ma być użyty.
• 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.enabledtrue.

Tryb produkcyjny

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

targets:
  prod:
    mode: production

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

• Sprawdza, czy wszystkie powiązane potoki Delta Live Tables 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.

Niestandardowe ustawienia wstępne

Pakiety zasobów usługi Databricks obsługują konfigurowalne ustawienia wstępne obiektów docelowych, co umożliwia dostosowanie zachowań obiektów docelowych. Dostępne ustawienia wstępne są wymienione w poniższej tabeli:

Ustawień domyślnych	opis
name_prefix	Ciąg prefiksu, który ma być poprzedzony nazwami zasobów.
pipelines_development	Określa, czy potok jest w trybie programowania. Prawidłowe wartości to true lub false.
trigger_pause_status	Stan wstrzymania, który ma być stosowany do wszystkich wyzwalaczy i harmonogramów. Prawidłowe wartości to PAUSED lub UNPAUSED.
jobs_max_concurrent_runs	Liczba maksymalnych dozwolonych współbieżnych uruchomień dla zadań.
tags	Zestaw tagów key:value, które mają zastosowanie do wszystkich zasobów, które obsługują tagi, w tym zadania i eksperymenty. Pakiety zasobów usługi Databricks nie obsługują tagów dla schema zasobu.
source_linked_deployment	Zarezerwowane na przyszłość. Określa, czy zasoby utworzone podczas wdrażania wskazują na pliki źródłowe w obszarze roboczym, zamiast na ich kopie w obszarze roboczym.

Uwaga

Jeśli ustawiono zarówno mode, jak i presets ustawienia wstępne zastępują zachowanie trybu domyślnego, a ustawienia poszczególnych zasobów zastępują ustawienia wstępne. Jeśli na przykład harmonogram jest ustawiony na UNPAUSED, ale ustawienie wstępne trigger_pause_status to PAUSED, harmonogram jest wznowiony.

W poniższym przykładzie przedstawiono niestandardową konfigurację ustawień wstępnych dla obiektu docelowego o nazwie dev:

targets:
  dev:
    presets:
      name_prefix: "testing_"      # prefix all resource names with testing_
      pipelines_development: true  # set development to true for pipelines
      trigger_pause_status: PAUSED # set pause_status to PAUSED for all triggers and schedules
      jobs_max_concurrent_runs: 10 # set max_concurrent runs to 10 for all jobs
      tags:
        department: finance