CI/CD pro Databricks Apps pomocí GitHub Actions

Tato stránka vysvětluje, jak automatizovat nasazení aplikace Databricks z GitHub pomocí GitHub Actions a Delarativní automatizační sady. Zahrnuje federaci identit úloh, YAML pracovního postupu a kontrolu stavu, která potvrzuje, že aplikace po každém nasazení obsluhuje nejnovější kód.

Obecné pokyny ke GitHub Actions pro úlohy a kanály Azure Databricks najdete v tématu GitHub Actions. Nastavení federace identit úloh najdete v článku Povolení federace identit úloh pro GitHub Actions.

Requirements

Krok 1. Nakonfigurujte federaci identit zatížení

Federace identity úloh umožňuje runneru GitHub Actions ověřovat se vůči Azure Databricks pomocí krátkodobého tokenu OIDC namísto ukládání přihlašovacích údajů do repozitáře.

Postupujte podle kroků v Povolení federace identity úloh pro GitHub Actions a vytvořte v objektu služby zásady federace pro GitHub Actions. Poznamenejte si ID aplikace instančního objektu (UUID) a adresu URL vašeho pracovního prostoru. V pracovním postupu potřebujete obě jako proměnné.

Potom udělte instančnímu objektu služby CAN MANAGE oprávnění k aplikaci, nebo pokud aplikace ještě neexistuje, oprávnění v pracovním prostoru k vytváření aplikací. Viz Konfigurace oprávnění pro aplikaci Databricks.

krok 2. Konfigurace úložiště GitHub

Ve svém úložišti GitHub vytvořte prostředí pro nasazení k uložení proměnných připojení k pracovnímu prostoru. Použití prostředí také umožňuje vyžadovat ruční schválení před spuštěním nasazení.

  1. V prostředích nastavení> vytvořte prostředí s názvem prod (nebo libovolným názvem, na který odkazuje váš pracovní postup).
  2. Pro proměnné prostředí přidejte následující:
Variable Value
DATABRICKS_HOST Adresa URL vašeho pracovního prostoru, například https://my-workspace.cloud.databricks.com
DATABRICKS_CLIENT_ID ID aplikace pro instanční objekt služby z kroku 1

Ani jedna z hodnot není přihlašovací údaj. Zásada federace pro instanční objekt určuje, kdo se jako něj může ověřovat, takže samotné ID klienta přístup neposkytuje. Tajný klíč klienta nepotřebujete.

Krok 3. Konfigurace sady pro produkční nasazení

V databricks.ymldeklarujte explicitní pracovní prostor host a root_path ve vašem prod cíli. Tím se zajistí, že se sada nasadí do stejného umístění při každém spuštění. Ověřování v produkčním režimu vyžaduje obě pole, pokud run_as není nastaven na instanční objekt služby. Viz způsoby nasazení deklarativních balíčků automatizace.

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

Nahraďte <service-principal-or-owner> uživatelem pracovního prostoru, který vlastní artefakty balíčku, obvykle ID aplikace instančního objektu služby.

Nahraďte ./app cestou ke zdrojovému kódu aplikace relativně k databricks.yml. Pole source_code_path se vyžaduje, když kód aplikace žije ve stejném úložišti jako sada. Pokud kód aplikace žije v samostatném úložišti, použijte git_source místo toho. Viz aplikace.

Krok 4. Přidat pracovní postup nasazení

Přidejte .github/workflows/deploy.yml do úložiště:

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

Nahraďte v posledním kroku my_app klíčem prostředku, který vaše databricks.yml používá pod resources.apps.

Runner potřebuje oprávnění id-token: write k vyžádání si tokenu OIDC. Akce databricks/setup-cli čte DATABRICKS_AUTH_TYPE=github-oidc a zpracovává ověřování automaticky.

Výstraha

databricks bundle deploy nahraje zdrojový kód a aktualizuje prostředky, ale nerestartuje proces aplikace. Pokud přeskočíte poslední krok databricks bundle run, nasazení v CI úspěšně projde, zatímco aplikace bude nadále běžet na předchozím kódu. Po nasazení vždy spusťte zdroj balíčku.

Krok 5. Počkejte, až bude aplikace v pořádku.

Databricks doporučuje přidat krok dotazování stavu po nasazení. databricks bundle run ukončí, jakmile aplikaci signalizuje, že se spustí, ale aplikace možná ještě neběží. Během spouštění může stále selhat kvůli problémům, jako jsou chybějící závislosti, chybějící proměnná prostředí nebo konflikt portů. Přidání kroku dotazování zajišťuje, že pracovní postup selže i při neúspěšném spuštění:

- 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

Nastavte APP_NAME na hodnotu, kterou vaše databricks.yml deklaruje pod resources.apps.<key>.name, nikoli na klíč prostředku svazku.

Zpracování existující aplikace

Názvy aplikací jsou v rámci pracovního prostoru jedinečné. Krok bundle deploy selže s chybou An app with the same name already exists, pokud jiný balíček (nebo ručně vytvořená aplikace) již vlastní aplikaci s tímto názvem. Vytvořte vazbu vaší sady k existující aplikaci a nemusíte ji znovu vytvořit.

Spuštěním tohoto příkazu místně připojte sadu ke stávající aplikaci:

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

Pak znovu spusťte pracovní postup. Následná nasazení znovu používají vazbu.

Pokud má existující aplikace konfiguraci na straně serveru (například budget_policy_id), která není ve vaší aplikaci, zkopírujte databricks.ymlji do souboru sady před opětovným nasazením. Nesoulady se během kroku nasazení balíčku projeví jako chyba Terraformu „nekonzistentní výsledek“.

Výběr spouštěče

Začněte tak workflow_dispatch , aby první nasazení bylo ruční. Jakmile několik spuštění proběhne úspěšně, přidejte push: branches: [main], aby se nasazovalo při každém sloučení.

Pro další bezpečnostní pojistku nakonfigurujte prostředí prod s požadovanými schvalovateli v Nastavení>Prostředí>prod>Pravidla ochrany nasazení. Každý pracovní postup čeká na schvalovatele před spuštěním úlohy nasazení.

Další kroky

  • Last updated on