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

Configure CI/CD para o seu agente do Databricks Apps.

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

Esta página aborda os detalhes específicos de cada agente. O documento CI/CD para Databricks Apps com GitHub Actions descreve a configuração principal do fluxo de trabalho: federação de identidade de carga de trabalho, o ambiente GitHub e o YAML implantado. Preencha primeiro essa página e depois volte aqui para ver as informações adicionais que se aplicam aos aplicativos de agentes.

Requisitos​

o passo 1. Use o starter fluxo de trabalho​

Vários agentes padrão em databricks/app-padrão enviam um .github/workflows/deploy.yml pronto para uso, então você não precisa escrever o fluxo de trabalho do zero.

  1. Escolha um agente padrão em databricks/app-padrão, como agent-langgraph ou agent-openai-agents-sdk.
  2. No diretório padrão clonado, verifique se .github/workflows/deploy.yml existe.
  3. Configure o fluxo de trabalho:
    • Se deploy.yml existir : Abra-o, confirme se databricks bundle run o passo referencia 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 do padrão que existe, ou do passo 4. Adicione o fluxo de trabalho implantado. Em seguida, atualize o databricks bundle run <key> o passo para corresponder key de recurso do seu pacote.

o passo 2. Preencha previamente o ID do experimento MLflow​

Agente padrão deixa MLFLOW_EXPERIMENT_ID vazio em databricks.yml. O script quickstart preenche-o localmente na primeira configuração, mas um novo executor CI não o faz. Se experiment_id estiver vazio, databricks bundle deploy falha com um erro de tipo do Terraform (For input string: "").

Para corrigir, commit o valor preenchido:

  1. execução 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' sob resources.apps.<key>.resources) agora tem um experiment_id numérico.
  3. Confirme a alteração.

O experimento tem escopo workspace , portanto, o mesmo ID é válido para todas as implantações de CI direcionadas a esse workspace. Se você implantar em vários espaços de trabalho, declare um experimento por alvo em databricks.yml (um por bloco targets.<env> ) ou use uma variável de pacote.

Conceda permissões Postgres para memória Lakebase padrão​

O agente avançado padrão (agent-langgraph-advanced, agent-openai-advanced) declara um recurso Lakebase Postgres de escalonamento automático diretamente em databricks.yml. Com o Databricks CLI v0.295.0 e posterior, databricks bundle deploy provisionamento o recurso junto com o aplicativo.

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

A concessão desses privilégios em nível de Postgres é uma configuração feita apenas uma vez . execução localmente entre os primeiros bundle deploy e bundle run. O CI reimplantia depois desse fluxo através do caminho padrão deploy e depois run , porque a função Postgres da entidade de serviço Databricks persiste durante toda a vida útil do aplicativo.

  1. implantei o bundle para provisionamento do recurso Lakebase :

    Bash
    databricks bundle deploy --target prod

  2. Conceda à entidade de serviço Databricks os privilégios de nível Postgres necessários:

    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 LangGraph padrão, passe --memory-type langgraph. O script também aceita --project <project> --branch <branch> para autoscale Lakebase ou --instance-name <name> para provisionamento Lakebase.

  3. Iniciar o aplicativo:

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

o passo 3. Teste de fumaça do agente implantado​

databricks bundle run O processo retorna assim que o executor sinaliza para o agente iniciar, mas o processo do agente ainda pode falhar durante a inicialização. Após a verificação de integridade do passo 5, aguarde até que o aplicativo esteja íntegro e adicione o seguinte teste de fumaça ao passo deploy.yml , que envia uma solicitação canary para o /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

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

Próximos passos​

Nesta página