CI/CD dla aplikacji Databricks za pomocą GitHub Actions

Na tej stronie wyjaśniono, jak zautomatyzować wdrażanie aplikacji usługi Databricks z GitHub przy użyciu GitHub Actions i Declarative Automation Bundles. Obejmuje federację tożsamości obciążeń, plik workflow YAML oraz kontrolę stanu, która potwierdza, że aplikacja udostępnia najnowszą wersję kodu po każdym wdrożeniu.

Aby uzyskać ogólne wskazówki GitHub Actions dotyczące zadań i potoków Azure Databricks, zobacz GitHub Actions. Informacje o konfiguracji federacji tożsamości obciążeń znajdziesz w artykule Włącz federację tożsamości obciążeń dla GitHub Actions.

Requirements

Krok 1. Konfigurowanie federacji tożsamości obciążeń

Federacja tożsamości obciążeń umożliwia runnerowi GitHub Actions uwierzytelnianie się w usłudze Azure Databricks przy użyciu krótkotrwałego tokenu OIDC zamiast przechowywania poświadczeń w repozytorium.

Wykonaj kroki opisane w Włączanie federacji tożsamości obciążeń dla GitHub Actions, aby utworzyć zasady federacji GitHub Actions w jednostce usługi. Zanotuj identyfikator aplikacji jednostki usługi (UUID) oraz adres URL obszaru roboczego. Oba te elementy są potrzebne jako zmienne w przepływie pracy.

Następnie przyznaj nazwie głównej usługi CAN MANAGE uprawnienie do aplikacji lub, jeśli aplikacja jeszcze nie istnieje, uprawnienie w obszarze roboczym do tworzenia aplikacji. Zobacz Konfigurowanie uprawnień dla aplikacji usługi Databricks.

Krok 2. Konfigurowanie repozytorium GitHub

W repozytorium GitHub utwórz środowisko wdrożeniowe do przechowywania zmiennych połączenia z obszarem roboczym. Użycie środowiska pozwala także wymagać ręcznego zatwierdzenia przed rozpoczęciem wdrażania.

  1. W obszarze Ustawienia>Środowiska utwórz środowisko o nazwie prod (lub dowolnej nazwie, do której odwołuje się przepływ pracy).
  2. W obszarze Zmienne środowiskowe dodaj następujące elementy:
Zmienna Value
DATABRICKS_HOST Adres URL obszaru roboczego, na przykład https://my-workspace.cloud.databricks.com
DATABRICKS_CLIENT_ID Identyfikator aplikacji jednostki usługi z kroku 1

Żadna wartość nie jest poświadczeniami. Zasady federacji dotyczące jednostki usługi kontrolują, kto może uwierzytelniać się jako ona, więc sam identyfikator klienta nie zapewnia dostępu. Nie potrzebujesz klucza tajnego klienta.

Krok 3. Konfigurowanie pakietu dla wdrożeń produkcyjnych

W pliku databricks.yml jawnie zadeklaruj obszar roboczy host i root_path w obiekcie docelowym prod. Dzięki temu pakiet zostanie wdrożony w tej samej lokalizacji na każdym uruchomieniu. Walidacja w trybie produkcyjnym wymaga obu pól, chyba że run_as jest ustawione na nazwę główną usługi. Zobacz Deklaratywne tryby wdrażania pakietów automatyzacji.

targets:
  prod:
    mode: production
    workspace:
      host: https://my-workspace.cloud.databricks.com
      root_path: /Workspace/Users/<service-principal-or-owner>/.bundle/${bundle.name}/${bundle.target}
    resources:
      apps:
        my_app:
          name: my-app
          source_code_path: ./app

Zastąp element <service-principal-or-owner> użytkownikiem obszaru roboczego, który jest właścicielem artefaktów pakietu, zazwyczaj identyfikatorem aplikacji jednostki usługi.

Zastąp ./app ścieżką do kodu źródłowego Twojej aplikacji względną do databricks.yml. Pole source_code_path jest wymagane, gdy kod aplikacji znajduje się w tym samym repozytorium co pakiet. Jeśli kod aplikacji znajduje się w oddzielnym repozytorium, użyj git_source zamiast tego. Zobacz aplikację.

Krok 4. Dodaj przepływ pracy wdrożenia

Dodaj .github/workflows/deploy.yml do repozytorium:

name: Deploy to Databricks Apps

on:
  workflow_dispatch:
  # Uncomment to deploy on every push to main once the workflow is validated.
  # push:
  #   branches: [main]

permissions:
  id-token: write # required for OIDC federation
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: prod
    env:
      DATABRICKS_AUTH_TYPE: github-oidc
      DATABRICKS_HOST: ${{ vars.DATABRICKS_HOST }}
      DATABRICKS_CLIENT_ID: ${{ vars.DATABRICKS_CLIENT_ID }}
    steps:
      - uses: actions/checkout@v4

      - name: Install Databricks CLI
        uses: databricks/setup-cli@main

      - name: Validate bundle
        run: databricks bundle validate --target prod

      - name: Deploy bundle
        run: databricks bundle deploy --target prod

      - name: Start or restart app
        run: databricks bundle run my_app --target prod

Zastąp my_app w ostatnim kroku kluczem zasobu, którego używa databricks.yml w obszarze resources.apps.

Runner potrzebuje uprawnienia id-token: write, aby zażądać tokena OIDC. Akcja databricks/setup-cli odczytuje DATABRICKS_AUTH_TYPE=github-oidc i obsługuje uwierzytelnianie automatycznie.

Ostrzeżenie

databricks bundle deploy przekazuje kod źródłowy i aktualizuje zasoby, ale nie powoduje ponownego uruchomienia procesu aplikacji. Jeśli pominiesz ostatni krok databricks bundle run, wdrożenie przejdzie pomyślnie w CI, podczas gdy aplikacja nadal będzie działać na poprzedniej wersji kodu. Zawsze uruchamiaj zasób pakietu po wdrożeniu.

Krok 5. Poczekaj, aż aplikacja będzie w dobrej kondycji

Usługa Databricks zaleca dodanie kroku sondowania stanu po wdrożeniu. databricks bundle run kończy działanie natychmiast po uruchomieniu aplikacji, ale aplikacja może jeszcze nie działać. Nadal może zakończyć się niepowodzeniem podczas uruchamiania z powodu problemów, takich jak brakujące zależności, brakująca zmienna środowiskowa lub konflikt portów. Dodanie kroku sondowania gwarantuje, że niepowodzenie uruchamiania zakończy się również niepowodzeniem przepływu pracy:

- name: Wait for app to be running
  env:
    APP_NAME: my-app
  run: |
    for i in $(seq 1 20); do
      STATE=$(databricks apps get "$APP_NAME" --output json | jq -r '.app_status.state')
      echo "Attempt $i/20: state=$STATE"
      if [ "$STATE" = "RUNNING" ]; then
        exit 0
      fi
      sleep 15
    done
    echo "App did not reach RUNNING state within 5 minutes" >&2
    exit 1

Ustaw APP_NAME na wartość, którą databricks.yml deklaruje w sekcji resources.apps.<key>.name, a nie na klucz zasobu pakietu.

Obsługa istniejącej aplikacji

Nazwy aplikacji są unikatowe w obszarze roboczym. Krok bundle deploy kończy się niepowodzeniem, An app with the same name already exists gdy inny pakiet (lub aplikacja utworzona ręcznie) jest już właścicielem aplikacji o tej nazwie. Powiąż pakiet z istniejącą aplikacją zamiast tworzyć ją ponownie.

Uruchom to raz lokalnie, aby dołączyć pakiet do istniejącej aplikacji:

databricks bundle deployment bind my_app <existing-app-name> --target prod --auto-approve

Następnie uruchom ponownie przepływ pracy. Kolejne wdrożenia ponownie wykorzystują powiązanie.

Jeśli istniejąca aplikacja ma konfigurację po stronie serwera (na przykład budget_policy_id), która nie znajduje się w pliku databricks.yml, skopiuj ją do pliku pakietu przed ponownym wdrożeniem. Niezgodność jest wyświetlana jako błąd "niespójny wynik" narzędzia Terraform podczas kroku wdrażania pakietu.

Wybieranie wyzwalacza

Zacznij od workflow_dispatch, aby pierwsze wdrożenie było ręczne. Gdy kilka uruchomień zakończy się pomyślnie, dodaj push: branches: [main], aby wdrażać przy każdym scaleniu.

Aby uzyskać dodatkową bramę bezpieczeństwa, skonfiguruj prod środowisko z wymaganymi recenzentami w obszarze Ustawienia>Środowiska>prod>Reguły ochrony wdrożenia. Każde uruchomienie przepływu pracy czeka na zatwierdzenie przed uruchomieniem zadania wdrażania.

Następne kroki

  • Last updated on