Tryby wdrażania pakietów deklaratywnej automatyzacji

Na tej stronie opisano składnię trybów wdrażania pakietów deklaratywnej automatyzacji. Pakiety umożliwiają programowe zarządzanie przepływami pracy usługi Azure Databricks. Zobacz Co to są pakiety deklaratywnej automatyzacji?

W przepływach pracy CI/CD deweloperzy zazwyczaj kodują, testują, wdrażają i uruchamiają 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 deklaratywne automatyzacji udostępniają opcjonalną kolekcję zachowań domyślnych odpowiadających każdemu z tych trybów.

Tryby wdrażania są opcjonalne. Pakiety można wdrażać bez ustawiania mode ani konfigurowania presets. Tryby wdrażania są wygodą stosowania grupy często używanych ustawień jednocześnie.

Tryb programowania

Aby wdrożyć pakiet w trybie deweloperskim, dodaj mapowanie mode ustawione na wartość development do zamierzonego celu. Zobacz mapowanie celów konfiguracji pakietu. Na przykład ten element docelowy o nazwie dev jest traktowany jako cel programistyczny.

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:

• Dodaje na początku wszystkich zasobów, które nie są wdrażane jako pliki lub notesy, prefiks [dev ${workspace.current_user.short_name}] i taguje każde wdrożone zadanie oraz potok tagiem usługi Azure Databricks dev.
• Oznacza wszystkie powiązane wdrożone potoki deklaratywne platformy Spark w usłudze Lakeflow jako development: true.
• Umożliwia użycie polecenia --cluster-id <cluster-id> w powiązanych wywołaniach do polecenia bundle deploy, co zastępuje wszystkie istniejące definicje klastra, które są już określone w powiązanym pliku konfiguracji pakietu. Zamiast używać --cluster-id <cluster-id> w powiązanych wywołaniach polecenia bundle deploy, można ustawić mapowanie cluster_id tutaj lub jako mapowanie podrzędne mapowania bundle na identyfikator klastra, który ma być użyty.
• Zatrzymuje wszystkie harmonogramy i wyzwalacze dotyczące wdrożonych zasobów, takich jak zadania lub monitorowanie jakości. Usuń harmonogramy i wyzwalacze dla pojedynczego zadania, ustawiając wartość schedule.pause_status na UNPAUSED.
• Umożliwia równoczesne uruchamianie wszystkich wdrożonych zadań dla szybszych iteracji. Wyłącz współbieżne uruchomienia dla pojedynczego zadania, ustawiając max_concurrent_runs na 1.
• Wyłącza blokadę wdrożenia w celu szybszej iteracji. Ta blokada zapobiega konfliktom wdrożeniowym, które są mało prawdopodobne w trybie developerskim. Włącz ponownie blokadę, ustawiając wartość bundle.deployment.lock.enabledtrue.

Tryb produkcyjny

Aby wdrożyć pakiet w trybie produkcyjnym, dodaj mode mapowanie ustawione na production wartość, do docelowego celu. Zobacz mapowanie elementów docelowych konfiguracji pakietu. Na przykład, ten obiekt docelowy o nazwie prod jest traktowany jako cel 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 wdrożone potoki deklaratywne Lakeflow Spark 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 celu jest opcjonalne i można to zrobić za pomocą dodatkowej właściwości git w następujący sposób:

  git:
    branch: main
  

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

• Firma Databricks zaleca używanie zasad serwisowych do wdrożeń produkcyjnych. Możesz to wymusić, ustawiając wartość run_as na główny obiekt usługi. Zobacz Podmioty usługi i Określanie tożsamości uruchomienia dla przepływu pracy pakietów automatyzacji deklaratywnej. Jeśli nie używasz jednostek usługi, proszę zwrócić uwagę na następujące dodatkowe zachowania:

  • Sprawdza, czy mapowania artifact_path, file_path, root_path, lub state_path nie są zastępowane dla określonego użytkownika.
  • Weryfikuje, czy mapowania run_as i permissions zostały określone, aby wyjaśnić, które tożsamości mają konkretne uprawnienia do wdrożeń.

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

Niestandardowe ustawienia wstępne

Pakiety deklaratywne automatyzacji obsługują konfigurowalne ustawienia wstępne dla obiektów docelowych, co pozwala dostosować zachowania obiektów docelowych. Aby uzyskać dostępne ustawienia wstępne, zobacz dokumentację konfiguracji.

Uwaga

Jeśli nie określono wyjątku dla ustawienia wstępnego, to w przypadku, gdy zarówno mode, jak i presets są ustawione, ustawienia wstępne zastępują domyślne zachowanie trybu, a ustawienia poszczególnych zasobów zastępują ustawienia wstępne. Przykład:

• max_concurrent_runs Jeśli parametr dla zadania wynosi 10, ale jobs_max_concurrent_runs ustawienie wstępne ma wartość 20, maksymalna liczba współbieżnych przebiegów zadania wynosi 10.
• Jeśli harmonogram jest ustawiony na UNPAUSED, ale ustawienie wstępne trigger_pause_status jest ustawione na PAUSED, harmonogram będzie 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