CI/CD voor Databricks-apps met GitHub Actions

Op deze pagina wordt uitgelegd hoe u de implementatie van een Databricks-app vanuit GitHub automatiseert met behulp van GitHub Actions en Declaratieve Automation-bundels. Het behandelt de federatie van workload-identiteiten, het workflow-YAML-bestand en een gezondheidscontrole die bevestigt dat de app na elke implementatie de nieuwste code draait.

Zie GitHub Actions voor algemene GitHub Actions richtlijnen voor Azure Databricks taken en pijplijnen. Zie Workload-identiteitsfederatie inschakelen voor GitHub Actions voor informatie over het instellen van workload-identiteitsfederatie.

Requirements

• Een service-principal in uw Azure Databricks-account dat eigenaar is van de geïmplementeerde app. Zie Service-principals toevoegen aan uw account.
• Een databricks.yml bundelconfiguratie in de hoofdmap van uw GitHub-repository die de app als resource declareert. Bekijk de app.
• De Databricks CLI is lokaal geïnstalleerd voor eenmalige installatietaken. Zie De Databricks CLI installeren of bijwerken.

Stap 1. Federatie van workload-identiteiten configureren

Met workload identity federation kan de GitHub Actions-runner zich bij Azure Databricks verifiëren met behulp van een kortstondig OIDC-token, in plaats van aanmeldingsgegevens in uw repository op te slaan.

Volg de stappen in Enable workload identity federation for GitHub Actions om een GitHub Actions-federatiebeleid op uw service-principal te maken. Noteer de toepassings-id (UUID) van de service-principal en de URL van uw werkruimte. U hebt beide als variabelen in de werkstroom nodig.

Verleen vervolgens de service-principal CAN MANAGE toegang tot de app, of machtigingen in de werkruimte om apps te maken als de app nog niet bestaat. Zie Machtigingen configureren voor een Databricks-app.

stap 2. De GitHub-opslagplaats configureren

Maak in uw GitHub-opslagplaats een implementatieomgeving om de werkruimteverbindingsvariabelen op te slaan. Met behulp van een omgeving kunt u ook handmatige goedkeuring vereisen voordat implementaties worden uitgevoerd.

1. Maak inInstellingenomgevingen> een omgeving met de naam prod (of een naam van uw werkstroomverwijzingen).
2. Voeg voor omgevingsvariabelen het volgende toe:

Geen van beide waarden is een referentie. Het federatiebeleid voor de service-principal bepaalt wie deze kan verifiëren, zodat alleen de client-id geen toegang verleent. U hebt geen clientgeheim nodig.

Stap 3. Uw bundel configureren voor productie-implementaties

Declareer in databricks.yml een expliciete werkruimte host en root_path op uw prod-doel. Dit zorgt ervoor dat de bundel op dezelfde locatie wordt geïmplementeerd tijdens elke uitvoering. Validatie in de productiemodus vereist beide velden, tenzij run_as is ingesteld als een service-principal. Zie De declaratieve Automation Bundles-implementatiemodi.

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

Vervang <service-principal-or-owner> door de gebruiker van de werkruimte die eigenaar is van de bundelartefacten, meestal de toepassings-ID van de service-principal.

Vervang ./app door het pad naar de broncode van uw app ten opzichte van databricks.yml. Het source_code_path veld is vereist wanneer app-code zich in dezelfde opslagplaats bevindt als de bundel. Als uw app-code zich in een afzonderlijke opslagplaats bevindt, gebruikt u git_source in plaats daarvan. Bekijk de app.

Stap 4. De implementatiewerkstroom toevoegen

Toevoegen .github/workflows/deploy.yml aan uw opslagplaats:

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

Vervang my_app in de laatste stap door de resourcesleutel die door uw databricks.yml wordt gebruikt onder resources.apps.

De runner heeft de id-token: write machtiging nodig om een OIDC-token aan te vragen. De databricks/setup-cli actie leest DATABRICKS_AUTH_TYPE=github-oidc en verwerkt verificatie automatisch.

Stap 5. Wacht totdat de app in orde is

Databricks raadt u aan een statuspeilingsstap toe te voegen na de implementatie. databricks bundle run wordt afgesloten zodra het de app opdracht geeft om te starten, maar de app draait mogelijk nog niet. Het kan nog steeds mislukken tijdens het opstarten vanwege problemen zoals ontbrekende afhankelijkheden, een ontbrekende omgevingsvariabele of een poortconflict. Door een pollingstap toe te voegen, zorgt u ervoor dat een mislukte opstart er ook voor zorgt dat de workflow mislukt:

- 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

Stel APP_NAME deze waarde in op de waarde die u databricks.yml declareert onder resources.apps.<key>.name, niet de bundelresourcesleutel.

Een bestaande app verwerken

App-namen zijn uniek in de werkruimte. De bundle deploy stap mislukt wanneer An app with the same name already exists een andere bundel (of een handmatig gemaakte app) al eigenaar is van een app met die naam. Bind uw bundel aan de bestaande app in plaats van deze opnieuw te maken.

Voer deze eenmaal lokaal uit om de bundel aan de bestaande app te koppelen:

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

Voer vervolgens de werkstroom opnieuw uit. Volgende implementaties gebruiken de binding opnieuw.

Als de bestaande app een configuratie aan de serverzijde heeft (zoals budget_policy_id) die zich niet in uw databricks.ymlapp bevindt, kopieert u deze naar het bundelbestand voordat u deze opnieuw implementeert. Niet-overeenkomende fouten worden weergegeven als een Terraform-fout met 'inconsistent resultaat' tijdens de implementatiestap van de bundel.

Een trigger kiezen

Begin met workflow_dispatch zodat de eerste implementatie handmatig is. Zodra enkele runs geslaagd zijn, voegt u push: branches: [main] toe om na elke samenvoeging uit te rollen.

Voor een extra beveiligingscontrole configureert u de prod omgeving met vereiste beoordelaars in Instellingen>Omgevingen>prod>Beveiligingsregels voor implementatie. Elke workflowuitvoering wacht op een goedkeurder voordat de deploymenttaak wordt gestart.

Volgende stappen 

• Workload identity federation instellen om het GitHub Actions-federatiebeleid op uw service principal te configureren.
• Declareer een app als bundelresource om uw app toe te voegen aan databricks.yml.
• Configureer app-machtigingen om te bepalen wie de geïmplementeerde app kan beheren of gebruiken.
• Lees meer over Declarative Automation Bundles voor meer informatie over de bundellevenscyclus en implementatiemodi.
• Gebruik GitHub Actions met Azure Databricks voor hulp bij taken en pijplijnen buiten apps.