CI/CD instellen voor uw Databricks Apps-agent

Met een CI/CD-pijplijn wordt elke wijziging in uw agent uitgevoerd via codebeoordeling en een geautomatiseerde implementatie, dus productie-implementaties zijn niet afhankelijk van een laptop van een ontwikkelaar. Zodra de pijplijn is geconfigureerd, wordt uw agent bij elke merge naar uw main branch uitgerold en opnieuw gestart in Databricks Apps.

Op deze pagina worden de agentspecifieke onderdelen behandeld. CI/CD voor Databricks-apps met GitHub Actions beschrijft de basisconfiguratie van de workflow: workload-identiteitsfederatie, de GitHub-omgeving en het deploy-YAML-bestand. Vul eerst die pagina in en ga vervolgens terug naar de toevoegingen die van toepassing zijn op agent-apps.

Requirements

Stap 1. De starterswerkstroom gebruiken

Verschillende agent-sjablonen in databricks/app-templates bevatten een kant-en-klare .github/workflows/deploy.yml, zodat u de workflow niet vanaf nul hoeft te schrijven.

  1. Kies een agentsjabloon uit databricks/app-sjablonen, zoals agent-langgraph of agent-openai-agents-sdk.
  2. Controleer in uw gekloonde sjabloondirectory of .github/workflows/deploy.yml bestaat.
  3. Stel de workflow in:
    • Indien deploy.yml aanwezig: Open deze, controleer of de stap verwijst naar de databricks bundle run resourcesleutel van databricks.ymluw bundel en volg de vereisten in de opmerking van de header van het bestand.
    • Als deploy.yml niet bestaat: Kopieer het uit een sjabloon dat wel bestaat, of uit Stap 4. Voeg de implementatieworkflow toe. Werk vervolgens de stap databricks bundle run <key> bij zodat deze overeenkomt met de resourcesleutel van uw bundel.

Stap 2. De MLflow-experiment-id vooraf doorvoeren

Agentsjablonen blijven MLFLOW_EXPERIMENT_ID leeg in databricks.yml. Het quickstart script vult het lokaal in bij de eerste installatie, maar een nieuwe CI-runner doet dat niet. Als experiment_id leeg is, mislukt databricks bundle deploy met een Terraform-typefout (For input string: "").

U kunt dit probleem oplossen door de ingevulde waarde door te voeren:

  1. Voer uv run quickstart --profile <your-profile> lokaal uit op de computer waarop u de agent hebt gemaakt.
  2. Controleer of de experimentresource in databricks.yml (de vermelding met name: 'experiment' onder resources.apps.<key>.resources) nu een numerieke experiment_idwaarde heeft.
  3. Voer de wijziging door.

Het experiment heeft een werkruimtebereik, dus dezelfde id is geldig voor elke CI-implementatie die gericht is op die werkruimte. Als u in meerdere werkruimten implementeert, declareert u een experiment per doel in databricks.yml (één per targets.<env> blok) of gebruikt u een bundelvariabele.

Postgres-machtigingen verlenen voor Lakebase-geheugensjablonen

De geavanceerde agentsjablonen (agent-langgraph-advanced, agent-openai-advanced) declareren een Postgres-resource voor automatisch schalen van Lakebase rechtstreeks in databricks.yml. Met Databricks CLI v0.295.0 en hoger databricks bundle deploy richt u de resource naast de app in.

De DAB-resource postgres verleent het service-principal-werkruimteniveau van de app toegang tot het Lakebase-project, maar Lakebase behoudt een afzonderlijke Postgres-rollaag voor databasetoegang (schema's, tabellen en reeksen). De service-principal heeft een Postgres-rol met de juiste bevoegdheden nodig voordat de agent de geheugentabellen kan lezen of schrijven. Zie de verificatiearchitectuur voor het model met twee lagen.

Het verlenen van deze Postgres-bevoegdheden is een eenmalige installatie. Voer deze lokaal uit tussen de eerste bundle deploy en bundle run. CI wordt daarna opnieuw uitgerold via het standaardpad deploy en daarna run, omdat de Postgres-rol van de service-principal gedurende de levensduur van de app behouden blijft.

  1. Implementeer de bundel om de Lakebase-resource in te richten:

    databricks bundle deploy --target prod

  2. Verleen de service-principal de machtigingen op Postgres-niveau die deze nodig heeft:

    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>

    Geef voor de LangGraph-sjabloon --memory-type langgraph op. Het script accepteert --project <project> --branch <branch> ook voor automatisch schalen van Lakebase of --instance-name <name> voor ingerichte Lakebase.

  3. Start de app:

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

Stap 3. Voer een smoketest uit op de geïmplementeerde agent

databricks bundle run retourneert zodra de runner de agent aangeeft om te starten, maar het agentproces kan nog steeds mislukken tijdens het opstarten. Na de gezondheidscontrole van stap 5. Wacht tot de app de status 'gezond' heeft, voeg je de volgende smoke-teststap toe aan deploy.yml, die een canary-aanvraag naar /invocations stuurt:

- 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."

Note

Databricks-apps accepteren alleen OAuth-tokens voor aanroepen. Het OAuth-token van de werkruimte gebruiken vanuit databricks auth token; Databricks-apps weigeren elk ander tokentype.

Aanvullende informatiebronnen

  • Last updated on