Aller au contenu principal
Dernière mise à jour le

Configurer le CI/CD pour votre agent Databricks Apps

Un pipeline CI/CD exécute chaque modification de votre agent via une révision de code et un déploiement automatisé, de sorte que les déploiements en production ne dépendent pas de l'ordinateur portable d'un développeur. Une fois le pipeline configuré, chaque Merge vers votre Branch principale déploie et redémarre votre agent sur Databricks Apps.

Cette page couvre les éléments spécifiques à l'agent. CI/CD pour les Databricks Apps avec GitHub Actions décrit la configuration du workflow principal : fédération d'identités de charge de travail, l'environnement GitHub et le fichier YAML de déploiement. Terminez d'abord cette page, puis revenez ici pour les ajouts qui s'appliquent aux applications d'agent.

Exigences​

Étape 1. Utilisez le workflow de démarrage​

Plusieurs templates d'agent dans databricks/app-templates fournissent un .github/workflows/deploy.yml prêt à l'emploi, vous n'avez donc pas à écrire le workflow à partir de zéro.

  1. Choisissez un Template d'agent à partir de databricks/app-templates, tel que agent-langgraph ou agent-openai-agents-sdk.
  2. Dans votre répertoire de Template cloné, vérifiez si .github/workflows/deploy.yml existe.
  3. Configurer le workflow :
    • Si deploy.yml existe : ouvrez-le, confirmez que l'étape databricks bundle run fait référence à la clé de ressource de votre bundle à partir de databricks.yml, et suivez les prérequis figurant dans l'en-tête du fichier.
    • Si deploy.yml n’existe pas : copiez-le à partir d’un template existant, ou à partir de l’ étape 4. Ajouter le workflow de déploiement. Ensuite, mettez à jour l'étape databricks bundle run <key> afin qu'elle corresponde à la clé de ressource de votre bundle.

Étape 2. Préremplissez l'ID de l'Expérimentation MLflow.​

Les Template d'agent laissent MLFLOW_EXPERIMENT_ID vide dans databricks.yml. Le script quickstart le remplit localement lors de la première configuration, mais un nouveau runner CI ne le fait pas. Si experiment_id est vide, databricks bundle deploy échoue avec une erreur de type Terraform (For input string: "").

Pour le corriger, commit la valeur renseignée :

  1. Exécutez uv run quickstart --profile <your-profile> localement sur la machine où vous avez créé l'agent.
  2. Vérifiez que la ressource d'expérimentation dans databricks.yml (l'entrée avec name: 'experiment' sous resources.apps.<key>.resources) dispose maintenant d'un experiment_id numérique.
  3. commit la modification.

L'expérimentation est limitée au workspace, le même ID est donc valide pour chaque déploiement CI ciblant ce workspace. Si vous déployez sur plusieurs workspaces, déclarez une expérimentation par cible dans databricks.yml (une par bloc targets.<env>) ou utilisez une variable de bundle.

Accorder des autorisations Postgres pour les Template de mémoire Lakebase​

Les templates d'agent avancé (agent-langgraph-advanced, agent-openai-advanced) déclarent une ressource autoscaling Lakebase Postgres directement dans databricks.yml. Avec Databricks CLI v0.295.0 et versions ultérieures, databricks bundle deploy provisionne la ressource en même temps que l'application.

La ressource DAB postgres accorde au Service Principal Databricks de l'application un accès au niveau du Workspace au projet Lakebase, mais Lakebase conserve une couche de rôle Postgres distincte pour l'accès aux bases de données (schémas, tables et séquences). Le Service Principal Databricks a besoin d’un rôle Postgres avec les bons privilèges avant que l'agent puisse lire ou écrire ses tables de mémoire. Voir l'architecture d'authentification pour le modèle à deux couches.

L’octroi de ces privilèges de niveau Postgres est une configuration unique . Exécutez-le localement entre le premier bundle deploy et le bundle run. Le CI se redéploie après ce flux via le chemin standard deploy puis run, car le rôle Postgres du Service Principal Databricks persiste pendant toute la durée de vie de l'application.

  1. Déployez le bundle pour provisionner la ressource Lakebase :

    Bash
    databricks bundle deploy --target prod

  2. Accordez au Service Principal Databricks les privilèges de niveau Postgres dont il a besoin :

    Bash
    uv run python scripts/grant_lakebase_permissions.py \
      "$(databricks apps get <app-name> --output json | jq -r '.service_principal_client_id')" \
      --memory-type openai \
      --autoscaling-endpoint <endpoint>

    Pour le Template LangGraph, transmettez --memory-type langgraph. Le script accepte également --project <project> --branch <branch> pour l'autoscaling de Lakebase, ou --instance-name <name> pour Lakebase provisionnée.

  3. start l’application :

    Bash
    databricks bundle run <bundle-key> --target prod

Étape 3. Tester l'agent déployé par un test d'intégrité​

databricks bundle run revient dès que le runner signale à l'agent de start, mais le processus de l'agent peut toujours échouer pendant le démarrage. Après la vérification d'état de l'étape 5. Attendez que l'application soit saine, ajoutez l'étape de test de fumée suivante à deploy.yml qui publie une requête canary sur /invocations:

YAML
- name: Smoke test invocations
  env:
    APP_NAME: my-agent
  run: |
    APP_URL=$(databricks apps get "$APP_NAME" --output json | jq -r '.url')
    TOKEN=$(databricks auth token | jq -r '.access_token')
    STATUS=$(curl -sS -o /tmp/canary.json -w "%{http_code}" \
      -X POST "$APP_URL/invocations" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{"input": [{"role": "user", "content": "ping"}], "stream": false}')
    if [ "$STATUS" != "200" ]; then
      echo "Smoke test failed with status $STATUS:" >&2
      cat /tmp/canary.json >&2
      exit 1
    fi
    echo "Smoke test passed."
remarque

Databricks Apps n'accepte que les jetons OAuth pour l'invocation. Utilisez le jeton OAuth du Workspace de databricks auth token; Databricks Apps rejette tout autre type de jeton.

Ressources supplémentaires​

Sur cette page