Pular para o conteúdo principal
Última atualização em

Configure o CI/CD para seu agente do Databricks Apps

Um pipeline de CI/CD executa cada alteração no seu agente por meio de revisão de código e uma implantação automatizada, para que as implantações em produção não dependam do laptop de um único desenvolvedor. Depois que o pipeline for configurado, cada merge para sua branch principal implanta e reinicia seu agente no Databricks Apps.

Esta página aborda as partes específicas do agente. CI/CD para Databricks Apps com GitHub Actions documenta a configuração do fluxo de trabalho principal: federação de identidade de carga de trabalho, o ambiente GitHub e o YAML de implantação. Conclua essa página primeiro e, em seguida, retorne aqui para as adições que se aplicam a aplicativos de agente.

Requisitos​

O passo 1. Use o fluxo de trabalho inicial​

Vários padrões de agente em databricks/app-templates incluem um .github/workflows/deploy.yml pronto para uso, para que você não precise escrever o fluxo de trabalho do zero.

  1. Selecione um padrão de agente em databricks/app-templates, como agent-langgraph ou agent-openai-agents-sdk.
  2. No seu diretório de padrão clonado, verifique se .github/workflows/deploy.yml existe.
  3. Configurar o fluxo de trabalho:
    • Se deploy.yml existir : Abra-o, confirme se o passo databricks bundle run faz referência à key de recurso do seu pacote de databricks.yml, e siga os pré-requisitos no comentário do cabeçalho do arquivo.
    • Se deploy.yml não existir : Copie-o de um padrão que exista, ou de o Passo 4. Adicionar o fluxo de trabalho de implantação. Em seguida, atualize o databricks bundle run <key> passo para corresponder à key de recurso do seu pacote.

O passo 2. Preencher a ID do experimento do MLflow​

Padrões de agente deixam MLFLOW_EXPERIMENT_ID vazio em databricks.yml. O script quickstart o preenche localmente na primeira configuração, mas um novo runner de CI não. Se experiment_id estiver vazio, databricks bundle deploy falha com um erro de tipo do Terraform (For input string: "").

Para corrigir, faça o commit do valor preenchido:

  1. Execute uv run quickstart --profile <your-profile> localmente na máquina onde você criou o agente.
  2. Verifique se o recurso de experimento em databricks.yml (a entrada com name: 'experiment' em resources.apps.<key>.resources) agora tem um experiment_id numérico.
  3. Faça o commit da alteração.

O experimento tem escopo de workspace, então o mesmo ID é válido para cada implantação de CI direcionada a esse workspace. Se você tiver implantado em vários workspaces, declare um experimento por destino em databricks.yml (um por bloco de targets.<env>) ou use uma variável de pacote.

Conceder permissões do Postgres para padrões de memória do Lakebase​

Os padrões de agente avançados (agent-langgraph-advanced, agent-openai-advanced) declaram um recurso de autoscale do Lakebase Postgres diretamente em databricks.yml. Com a CLI do Databricks v0.295.0 e posterior, databricks bundle deploy provisiona o recurso juntamente com o aplicativo.

O recurso DAB postgres concede à entidade de serviço do Databricks do aplicativo acesso em nível de workspace ao projeto Lakebase, mas o Lakebase mantém uma camada separada de função do Postgres para acesso ao banco de dados (esquemas, tabelas e sequências). A entidade de serviço do Databricks precisa de uma função Postgres com os privilégios corretos antes que o agente possa ler ou gravar em suas tabelas de memória. Consulte Arquitetura de autenticação para o modelo de duas camadas.

Conceder estes privilégios no nível do Postgres é uma configuração única . Faça a execução localmente entre o primeiro bundle deploy e bundle run. O CI é reimplantado após esse fluxo pelo caminho padrão deploy, depois run, porque a função Postgres da entidade de serviço do Databricks persiste durante todo o ciclo de vida do aplicativo.

  1. Implante o pacote para provisionamento do recurso Lakebase:

    Bash
    databricks bundle deploy --target prod

  2. Conceda à entidade de serviço do Databricks os privilégios no nível do Postgres de que ela precisa:

    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>

    Para o padrão LangGraph, passe --memory-type langgraph. O script também aceita --project <project> --branch <branch> para autoscale do Lakebase ou --instance-name <name> para provisionamento de Lakebase.

  3. Comece o aplicativo:

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

O passo 3: Realizar um smoke test no agente implantado.​

databricks bundle run retorna assim que o executor sinaliza para o agente começar, mas o processo do agente ainda pode falhar durante a inicialização. Após a verificação de integridade de Passo 5. Aguarde até que o aplicativo esteja íntegro, adicione o passo de teste de fumaça a deploy.yml que posta uma solicitação canary para /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."
nota

Os Databricks Apps somente aceitam tokens OAuth para invocação. Use o tokens OAuth do workspace de databricks auth token; os Databricks Apps rejeitam qualquer outro tipo de tokens.

Recursos adicionais​

Nesta página