Декларативные режимы развертывания пакетов автоматизации

На этой странице описывается синтаксис для режимов развертывания декларативных пакетов автоматизации. Пакеты обеспечивают программное управление рабочими процессами Azure Databricks. См. Что такое декларативные пакеты автоматизации

В рабочих процессах CI/CD разработчики обычно кодируют, тестируют, развертывают и запускают решения на различных этапах или в режимах. Например, самый простой набор режимов включает режим разработки для предварительной проверки, а затем рабочий режим для проверенных конечных результатов. Декларативные пакеты автоматизации предоставляют необязательную коллекцию поведения по умолчанию, соответствующую каждому из этих режимов.

Режимы развертывания являются необязательными. Пакеты можно развертывать без установки mode или настройки presets. Режимы развертывания удобны для применения группы часто используемых параметров одновременно.

Режим разработки

Чтобы развернуть пакет в режиме разработки, добавьте mode сопоставление, установленное на development, к целевому объекту. См. сопоставление целевых объектов конфигурации пакета. Например, этот объект dev рассматривается как целевой объект разработки.

targets:
  dev:
    mode: development

Развертывание целевого объекта в режиме разработки, выполнив databricks bundle deploy -t <target-name> команду, реализует следующие действия, которые можно настроить с помощью предустановок:

  • Добавляет префикс [dev ${workspace.current_user.short_name}] ко всем ресурсам, которые не развертываются в виде файлов или записных книжек, и отмечает каждый развернутый процесс и конвейер тегом Azure Databricks dev.
  • Помечает все связанные развернутые декларативные конвейеры Lakeflow Spark как development: true.
  • Включает использование --cluster-id <cluster-id> в вызовах команды bundle deploy, что позволяет переопределять все существующие определения кластеров, которые уже указаны в конфигурационном файле соответствующего пакета. Вместо использования --cluster-id <cluster-id> в связанных вызовах команды bundle deploy можно задать сопоставление cluster_id здесь или в качестве дочернего сопоставления bundle с идентификатором используемого кластера.
  • Приостанавливает все расписания и триггеры на развернутых ресурсах, таких как задания или мониторы качества. Возобновите расписания и триггеры для отдельного задания, установив schedule.pause_status на UNPAUSED.
  • Включает параллельные запуски на всех развернутых заданиях для ускорения итерационного процесса. Отключите одновременные запуски для отдельного задания, установив max_concurrent_runs в 1.
  • Отключает блокировку развертывания для ускорения итерации. Эта блокировка предотвращает конфликты развертывания, которые вряд ли возникают в режиме разработки. Повторно включите блокировку, задав значение bundle.deployment.lock.enabledtrue.

Рабочий режим

Чтобы развернуть пакет в рабочем режиме, добавьте сопоставление mode, установив его на production, к целевому объекту. См. сопоставление целевых объектов конфигурации пакета. Например, объект с именем prod рассматривается как производственный целевой объект.

targets:
  prod:
    mode: production

Развертывание целевого объекта в рабочем режиме, выполнив databricks bundle deploy -t <target-name> команду, реализует следующее поведение:

  • Проверяет, помечены ли development: false все развернутые декларативные конвейеры Lakeflow Spark.

  • Проверяет, совпадает ли текущая ветвь Git с ветвью Git, указанной в задаче. Указание ветви Git в целевом объекте является необязательным и может выполняться с дополнительным git свойством следующим образом:

    git:
  branch: main

    Эту проверку можно переопределить, указав --force при развертывании.

  • Databricks рекомендует использовать учётные записи служб для рабочих развертываний. Вы можете обеспечить это, установив run_as на учетную запись службы. См. разделы "Принципы службы" и "Указание идентификационной информации для выполнения для рабочего процесса декларативных пакетов автоматизации". Если вы не используете служебные принципы, обратите внимание на следующее дополнительное поведение:

    • Проверяет, что artifact_path, file_path сопоставления или root_path, state_path сопоставления не переопределяются для конкретного пользователя.
    • Проверяет, указаны ли сопоставления run_as и permissions, для указания, какие идентификаторы имеют определенные разрешения для развертываний.

  • В отличие от предыдущего поведения при установке сопоставления mode на development, установка сопоставления mode на production не позволяет переопределять какие-либо существующие определения кластеров, указанные в связанном файле конфигурации пакета, например, с использованием параметра --compute-id <cluster-id> или сопоставления compute_id.

Пользовательские предустановки

Декларативные пакеты автоматизации поддерживают настраиваемые предустановки для целевых объектов, что позволяет настраивать поведение целевых объектов. Сведения о доступных предустановках см. в справочнике по конфигурации.

Примечание.

Если исключение не указано для предустановки, и если и mode, и presets установлены, предустановки переопределяют поведение режима по умолчанию, а настройки отдельных ресурсов переопределяют предустановки. Рассмотрим пример.

  • max_concurrent_runs Если для задания задано значение 10, но jobs_max_concurrent_runs предустановка имеет значение 20, максимальное число одновременных запусков задания равно 10.
  • Если расписание установлено на UNPAUSED, но предустановка trigger_pause_status установлена на PAUSED, расписание будет возобновлено.

В следующем примере показана настраиваемая конфигурация предустановок для целевого объекта с именем 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
  • Last updated on