Aller au contenu principal
Dernière mise à jour le

CI/CD pour Databricks Apps avec GitHub Actions

Cette page explique comment automatiser le déploiement d’une application Databricks à partir de GitHub à l’aide de GitHub Actions et des lots d’automatisation déclaratifs. Il couvre la fédération d'identité de charge de travail, le fichier YAML du workflow et un contrôle de santé qui confirme que l'application utilise le code le plus récent après chaque déploiement.

Pour obtenir des informations génériques sur GitHub Actions pour les jobs et les pipelines Databricks, consultez GitHub Actions. Pour la configuration de la fédération d'identité de charge de travail, consultez Activer la fédération d'identité de charge de travail pour GitHub Actions.

remarque

Pour redéployer votre application automatiquement à chaque push vers une Branch, utilisez les déploiements Git automatiques (Bêta). Consultez Activer les déploiements Git automatiques.

Exigences​

Étape 1. Configurer la fédération d'identités des charges de travail​

La fédération d'identités Workload permet au runner GitHub Actions de s'authentifier auprès de Databricks en utilisant un jeton OIDC de courte durée au lieu de stocker les informations d'identification dans votre repository.

  1. Suivez les étapes de Activer la fédération d'identité de workload pour GitHub Actions pour créer une politique de fédération GitHub Actions sur votre service principal Databricks. Enregistrez l'ID d'application du Service Principal Databricks (UUID) et votre URL de Workspace. Vous avez besoin des deux comme variables dans le workflow.
  2. Accordez au Service Principal Databricks CAN MANAGE l'autorisation sur l'application, ou l'autorisation Workspace pour créer des applications si l'application n'existe pas encore. Voir Configurer les autorisations d'une application Databricks.

Étape 2. Configurez le repository GitHub​

Dans votre repository GitHub, créez un environnement de déploiement pour stocker les variables de connexion du Workspace. L'utilisation d'un environnement vous permet également d'exiger une approbation manuelle avant l'exécution des déploiements.

  1. Dans Paramètres > Environnements , créez un environnement nommé prod (ou tout nom auquel votre workflow fait référence).
  2. Pour les variables d'environnement , ajoutez ce qui suit :

Variable

Valeur

DATABRICKS_HOST

L'URL de votre Workspace, par exemple https://my-workspace.cloud.databricks.com

DATABRICKS_CLIENT_ID

L’ID d’application du Service Principal Databricks de l’étape 1

Variable

Valeur

DATABRICKS_HOST

L'URL de votre Workspace, par exemple https://my-workspace.cloud.databricks.com

DATABRICKS_CLIENT_ID

L’ID d’application du Service Principal Databricks de l’étape 1

Aucune des valeurs n'est un identifiant. La politique de fédération sur le Service Principal Databricks contrôle qui peut s'authentifier en tant que tel, de sorte que l'ID client seul ne donne pas accès. Vous n'avez pas besoin d'un secret client.

Étape 3. Configurez votre bundle pour les déploiements de production​

Dans databricks.yml, déclarez un Workspace explicite host et root_path sur votre cible prod. Ceci garantit que le bundle se déploie au même emplacement à chaque exécution. La validation en mode production requiert les deux champs, sauf si run_as est défini sur un Service Principal. Consultez les modes de déploiement des Declarative Automation Bundles.

Utilisez git_source afin que les déploiements extraient le code directement de votre repository Git au lieu d'upload des fichiers vers le Workspace. Cela évite l'étape sync supplémentaire et maintient le code déployé synchronisé avec votre repository.

YAML
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
          git_repository:
            url: https://github.com/org/repo
          git_source:
            branch: main
            source_code_path: apps/my-app

Remplacez <service-principal-or-owner> par l'utilisateur du workspace qui possède les artefacts du bundle, généralement l'ID d'application du service principal Databricks. Remplacez l'URL git_repository par l'URL de votre repository GitHub. Si le code de votre application se trouve à la racine du repository, omettez source_code_path. Consultez l'application.

Pour les repository privés, configurez un identifiant Git sur le Service Principal Databricks de l'application avant le déploiement. Consultez les instructions CLI dans Déployer à partir d'un repository Git.

Étape 4. Ajouter le workflow de déploiement​

Ajoutez .github/workflows/deploy.yml à votre repository :

YAML
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

Remplacez my_app à la dernière étape par la clé de ressource que votre databricks.yml utilise sous resources.apps.

Le runner a besoin de l'autorisation id-token: write pour demander un jeton OIDC. L'action databricks/setup-cli lit DATABRICKS_AUTH_TYPE=github-oidc et gère l'authentification automatiquement.

attention

databricks bundle deploy upload le code source et met à jour les ressources, mais il ne redémarre pas le processus de l'application. Si vous ignorez la dernière étape databricks bundle run, le déploiement passe en CI pendant que l'application continue de servir le code précédent. Toujours exécuter la ressource du bundle après le déploiement.

Étape 5. Attendez que l'application soit saine​

Databricks recommande d'ajouter une étape d'interrogation de l'état après le déploiement. databricks bundle run se ferme dès qu'il signale à l'application de start, mais l'application pourrait ne pas encore être en cours d'exécution. Il peut toujours échouer lors du Startup en raison de problèmes tels que des dépendances manquantes, une variable d'environnement manquante ou un conflit de port. L'ajout d'une étape d'interrogation garantit qu'une Startup ayant échoué fait également échouer le workflow :

YAML
- 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

Définissez APP_NAME sur la valeur que votre databricks.yml déclare sous resources.apps.<key>.name, et non la clé de ressource du bundle.

Gérer une application existante​

Les noms d'application sont uniques dans tout le Workspace. L'étape bundle deploy échoue avec An app with the same name already exists lorsqu'un autre bundle (ou une application créée manuellement) possède déjà une application de ce nom. Liez votre bundle à l'application existante au lieu de le recréer.

Exécutez-le une fois localement pour attacher le bundle à l'application existante :

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

Ensuite, réexécutez le workflow. Les déploiements ultérieurs réutilisent la liaison.

Si l'application existante possède une configuration côté serveur (telle que budget_policy_id) qui ne se trouve pas dans votre databricks.yml, copiez-la dans le fichier du bundle avant de redéployer. Les incohérences apparaissent sous la forme d'une erreur Terraform « résultat incohérent » pendant l'étape de déploiement du bundle.

Choisir un Trigger​

start avec workflow_dispatch pour que le premier déploiement soit manuel. Une fois que quelques exécutions réussissent, ajoutez push: branches: [main] à déployer à chaque Merge.

Pour une barrière de sécurité supplémentaire, configurez l'environnement prod avec les relecteurs requis dans Paramètres > Environnements > prod > Règles de protection du déploiement . Chaque exécution de workflow attend un approbateur avant le start du job de déploiement.

Ressources supplémentaires​

Sur cette page