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

CI/CD para Databricks Apps com GitHub Actions

Esta página explica como automatizar a implantação de um aplicativo Databricks a partir do GitHub usando o GitHub Actions e os Declarative Automation Bundles. Abrange a federação de identidades de carga de trabalho, o YAML do fluxo de trabalho e uma verificação de integridade que confirma se o aplicativo está fornecendo o código mais recente após cada implantação.

Para obter orientações gerais sobre GitHub Actions para trabalhos e pipelines Databricks , consulte GitHub Actions. Para configurar a federação de identidades de cargas de trabalho, consulte Ativar a federação de identidades de cargas de trabalho para o GitHub Actions.

Requisitos​

o passo 1. Configurar federação de identidade de carga de trabalho​

A federação de identidade de carga de trabalho permite que o executor GitHub Actions se autentique com Databricks usando tokens OIDC de curta duração, em vez de armazenar credenciais em seu repositório.

Siga os passos descritos em Ativar a federação de identidade de carga de trabalho para o GitHub Actions para criar uma política de federação do GitHub Actions em sua entidade de serviço do Databricks. Anote o ID do aplicativo entidade de serviço (UUID) Databricks e a URL do seu workspace . Você precisa de ambas como variáveis no fluxo de trabalho.

Em seguida, conceda à entidade de serviço Databricks CAN MANAGE permissão no aplicativo ou permissão workspace para criar aplicativos se o aplicativo ainda não existir. Consulte Configurar permissões para um aplicativo Databricks.

o passo 2. Configure o repositório GitHub​

Em seu repositório GitHub , crie um ambiente de implantação para armazenar as variáveis de conexão workspace . Utilizar um ambiente também permite exigir aprovação manual antes da execução das implementações.

  1. Em Configurações > Ambientes , crie um ambiente chamado prod (ou qualquer nome que seu fluxo de trabalho utilize como referência).
  2. Para variável de ambiente , adicione o seguinte:

Variável

Valor

DATABRICKS_HOST

O URL do seu workspace , por exemplo. https://my-workspace.cloud.databricks.com

DATABRICKS_CLIENT_ID

O ID do aplicativo entidade de serviço Databricks da etapa 1

Nenhum dos valores constitui uma credencial. A política de federação na entidade de serviço do Databricks controla quem pode se autenticar como ela, portanto, o ID do cliente por si só não concede acesso. Você não precisa de um segredo do cliente.

o passo 3. Configure seu pacote para implantações de produção​

Em databricks.yml, declare um workspace explícito host e root_path em seu alvo prod . Isso garante que o pacote seja implantado no mesmo local em todas as execuções. A validação em modo de produção requer ambos os campos, a menos que run_as esteja definido como uma entidade de serviço. Consulte os modos de implantação dos Declarative Automation Bundles.

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
          source_code_path: ./app

Substitua <service-principal-or-owner> pelo usuário workspace que possui os artefatos do pacote, normalmente o ID do aplicativo de entidade de serviço Databricks .

Substitua ./app pelo caminho para o código-fonte do seu aplicativo relativo a databricks.yml. O campo source_code_path é obrigatório quando o código do aplicativo reside no mesmo repositório que o pacote. Se o código do seu aplicativo estiver em um repositório separado, use git_source em vez disso. Veja o aplicativo.

o passo 4. Adicione o fluxo de trabalho implantado​

Adicione .github/workflows/deploy.yml ao seu repositório:

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

Substitua my_app no último passo pela key de recurso que seu databricks.yml usa em resources.apps.

O executor precisa da permissão id-token: write para solicitar tokens OIDC. A ação databricks/setup-cli lê DATABRICKS_AUTH_TYPE=github-oidc e lida com a autenticação automaticamente.

atenção

databricks bundle deploy O código-fonte é carregado e o recurso é atualizado, mas o processo do aplicativo não é reiniciado. Se você pular o passo final databricks bundle run , o implantado passa no CI enquanto o aplicativo continua servindo o código anterior. Sempre execute o recurso bundle após implantado.

o passo 5. Aguarde até que o aplicativo esteja saudável​

Databricks recomenda adicionar uma etapa de verificação de status após a implantação. databricks bundle run sai assim que sinaliza o início do aplicativo, mas o aplicativo pode ainda não estar em execução. Ainda pode falhar durante startup devido a problemas como dependências ausentes, uma variável de ambiente ausente ou um conflito de portas. Adicionar um polling o passo garante que uma startup com falha também falhe no fluxo de trabalho:

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

Defina APP_NAME para o valor que seu databricks.yml declara em resources.apps.<key>.name, não a key de recurso do pacote.

Gerenciando um aplicativo existente​

Os nomes dos aplicativos são exclusivos em todo o workspace. O bundle deploy o passo falha com An app with the same name already exists quando outro pacote (ou um aplicativo criado manualmente) já possui um aplicativo com esse nome. Vincule seu pacote ao aplicativo existente em vez de recriá-lo.

Execute este comando localmente uma vez para anexar o pacote ao aplicativo existente:

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

Em seguida, reexecução do fluxo de trabalho. Implantações subsequentes reutilizam a vinculação.

Se o aplicativo existente tiver configuração do lado do servidor (como budget_policy_id) que não está em seu databricks.yml, copie-o para o arquivo de pacote antes de reimplantar. As incompatibilidades aparecem como um erro de "resultado inconsistente" Terraform durante a implantação do pacote.

Escolhendo um gatilho​

comece com workflow_dispatch para que a primeira implantação seja manual. Assim que algumas execuções forem bem-sucedidas, adicione push: branches: [main] a ser implantado em cada merge.

Para uma camada adicional de segurança, configure o ambiente prod com os revisores necessários em Configurações > Ambientes > prod > Regras de proteção de implantação . Cada execução de fluxo de trabalho aguarda um aprovador antes do início do trabalho implantado.

Próximos passos​

Nesta página