Ler em inglês

Partilhar via


Técnicas de CI/CD com pastas Git e Databricks Git (Repos)

Aprenda técnicas para usar pastas Databricks Git em fluxos de trabalho de CI/CD. Ao configurar pastas Databricks Git no espaço de trabalho, você pode usar o controle de origem para arquivos de projeto em repositórios Git e pode integrá-los em seus pipelines de engenharia de dados.

A figura a seguir mostra uma visão geral das técnicas e do fluxo de trabalho.

Visão geral das técnicas de CI/CD para pastas Git.

Para obter uma visão geral do CI/CD com o Azure Databricks, consulte O que é CI/CD no Azure Databricks?.

Fluxo de desenvolvimento

As pastas Databricks Git têm pastas de nível de usuário. As pastas de nível de usuário são criadas automaticamente quando os usuários clonam pela primeira vez um repositório remoto. Você pode pensar nas pastas do Databricks Git nas pastas do usuário como "checkouts locais" que são individuais para cada usuário e where os usuários fazem alterações em seu código.

Na sua pasta de usuário nas pastas Git do Databricks, clone seu repositório remoto. Uma prática recomendada é criar uma nova ramificação de recurso ou select uma ramificação criada anteriormente para seu trabalho, em vez de confirmar e enviar diretamente as alterações para a ramificação principal. Você pode fazer alterações, confirmar e enviar alterações por push nessa ramificação. Quando estiver pronto para mesclar seu código, você poderá fazê-lo na interface do usuário de pastas do Git.

Requisitos

Esse fluxo de trabalho requer que já tenhas set a tua integração com o Git.

Nota

A Databricks recomenda que cada desenvolvedor trabalhe em sua própria ramificação de recursos. Para obter informações sobre como resolver conflitos de mesclagem, consulte Resolver conflitos de mesclagem.

Colaborar em pastas Git

O fluxo de trabalho a seguir usa uma ramificação chamada feature-b baseada na ramificação principal.

  1. Clone seu repositório Git existente em seu espaço de trabalho Databricks.
  2. Use a interface do usuário de pastas do Git para criar uma ramificação de recurso a partir da ramificação principal. Este exemplo usa uma única ramificação feature-b de recurso para simplificar. Você pode criar e usar várias ramificações de recursos para fazer seu trabalho.
  3. Faça suas modificações em blocos de anotações do Azure Databricks e outros arquivos no repositório.
  4. Confirme e envie suas alterações para seu provedor Git.
  5. Os colaboradores agora podem clonar o repositório Git em sua própria pasta de usuário.
    1. Trabalhando em uma nova ramificação, um colega de trabalho faz alterações nos blocos de anotações e outros arquivos na pasta Git.
    2. O colaborador confirma e envia suas alterações para o provedor Git.
  6. Para mesclar alterações de outras ramificações ou rebasear a ramificação feature-b no Databricks, na interface do usuário das pastas Git use um dos seguintes fluxos de trabalho:
  7. Quando estiver pronto para mesclar seu trabalho com o repositório Git remoto e main ramificação, use a interface do usuário de pastas Git para mesclar as alterações do recurso-b. Se preferir, você pode mesclar as alterações diretamente no repositório Git que apoia sua pasta Git.

Fluxo de trabalho de trabalho de produção

As pastas Databricks Git fornecem duas opções para executar seus trabalhos de produção:

  • Opção 1: Forneça uma referência Git remota na definição de trabalho. Por exemplo, execute um bloco de anotações específico na main ramificação de um repositório Git.
  • Opção 2: Set configurar um repositório Git de produção e chamar APIs de repositório para update gerir programaticamente. Execute trabalhos na pasta Databricks Git que clona esse repositório remoto. A chamada à API do Repos deve ser a primeira tarefa no trabalho.

Opção 1: Executar trabalhos usando blocos de anotações em um repositório remoto

Simplifique o processo de definição de trabalho e mantenha uma única fonte de verdade executando um trabalho do Azure Databricks usando blocos de anotações localizados em um repositório Git remoto. Essa referência do Git pode ser uma confirmação, tag ou ramificação do Git e é fornecida por você na definição do trabalho.

Isso ajuda a evitar alterações não intencionais em seu trabalho de produção, como quando um usuário faz edições locais em um repositório de produção ou alterna ramificações. Ele também automatiza a etapa do CD, pois você não precisa criar uma pasta Git de produção separada no Databricks, gerenciar permissões para ela e mantê-la atualizada.

Consulte Usar o Git com trabalhos.

Opção 2: Set uma pasta Git de produção e automação Git

Nesta opção, você set uma pasta Git de produção e automação para update a pasta Git na mesclagem.

Etapa 1: Set para pastas de nível superior

O administrador cria pastas de nível superior que não são de usuário. O caso de uso mais comum para essas pastas de nível superior é criar pastas de desenvolvimento, preparo e produção que contenham pastas Databricks Git para as versões ou ramificações apropriadas para desenvolvimento, preparação e produção. Por exemplo, se sua empresa usa a main ramificação para produção, a pasta Git "produção" deve ter o main check-out da ramificação nela.

Normalmente, as permissões nessas pastas de nível superior são somente leitura para todos os usuários não administradores dentro do espaço de trabalho. Para essas pastas de nível superior, recomendamos que você forneça apenas entidades de serviço com permissões CAN EDIT e CAN MANAGE para evitar edições acidentais no código de produção por usuários do espaço de trabalho.

Pastas Git de nível superior.

Etapa 2: Set atualizações automatizadas para pastas Git Databricks com a API de pastas Git

Para manter uma pasta Git no Databricks na versão mais recente, você pode set a automação do Git para chamar a API Repos. Em seu provedor Git, set automação que, após cada mesclagem bem-sucedida de um PR na ramificação principal, chama o ponto de extremidade da API Repos na pasta Git apropriada para update-lo à versão mais recente.

Por exemplo, no GitHub, isso pode ser alcançado com as Ações do GitHub. Para obter mais informações, consulte a API do Repos.

Para chamar qualquer API REST do Databricks de dentro de uma célula de notebook Databricks, primeiro instale o SDK do Databricks com %pip install databricks-sdk --upgrade (para as APIs REST do Databricks mais recentes) e, em seguida, importe ApiClient do databricks.sdk.core.

Nota

Se %pip install databricks-sdk --upgrade retornar um erro que "O pacote não pôde ser encontrado", então o databricks-sdk pacote não foi instalado anteriormente. Execute novamente o comando sem o --upgrade sinalizador: %pip install databricks-sdk.

Você também pode executar APIs do SDK do Databricks a partir de um bloco de anotações para recuperar as entidades de serviço para seu espaço de trabalho. Aqui está um exemplo usando Python e o Databricks SDK for Python.

Você também pode usar ferramentas como curl ou Terraform. Não é possível usar a interface do usuário do Azure Databricks.

Para saber mais sobre entidades de serviço no Azure Databricks, consulte Gerenciar entidades de serviço. Para obter informações sobre entidades de serviço e CI/CD, consulte Entidades de serviço para CI/CD. Para obter mais detalhes sobre como usar o SDK do Databricks de um bloco de anotações, leia Usar o SDK do Databricks para Python de dentro de um bloco de anotações do Databricks.

Usar uma entidade de serviço com pastas Databricks Git

Para executar os fluxos de trabalho acima mencionados com entidades de serviço:

  1. Crie uma entidade de serviço com o Azure Databricks.
  2. Adicione o git credentials: Use o PAT do seu provedor Git para o principal de serviço.

Para set entidades de serviço e, em seguida, adicione o provedor Git credentials:

  1. Crie uma entidade de serviço. Consulte Executar trabalhos com entidades de serviço.
  2. Crie um token de ID do Microsoft Entra para uma entidade de serviço.
  3. Depois de criar uma entidade de serviço, adicione-a ao seu espaço de trabalho do Azure Databricks com a API de Entidades de Serviço.
  4. Adicione seu provedor Git credentials ao seu espaço de trabalho com seu token de ID do Microsoft Entra e a API do Git Credentials.

Integração Terraform

Você também pode gerenciar pastas Databricks Git em uma configuração totalmente automatizada usando Terraform e databricks_repo:

resource "databricks_repo" "this" {
  url = "https://github.com/user/demo.git"
}

Para usar o Terraform para adicionar o credentials do Git a um principal de serviço, adicione a seguinte configuração:

  provider "databricks" {
    # Configuration options
  }

  provider "databricks" {
    alias = "sp"
    host = "https://....cloud.databricks.com"
    token = databricks_obo_token.this.token_value
  }

  resource "databricks_service_principal" "sp" {
    display_name = "service_principal_name_here"
  }

  resource "databricks_obo_token" "this" {
    application_id   = databricks_service_principal.sp.application_id
    comment          = "PAT on behalf of ${databricks_service_principal.sp.display_name}"
    lifetime_seconds = 3600
  }

  resource "databricks_git_credential" "sp" {
    provider = databricks.sp
    depends_on = [databricks_obo_token.this]
    git_username          = "myuser"
    git_provider          = "azureDevOpsServices"
    personal_access_token = "sometoken"
  }

Configurar um pipeline de CI/CD automatizado com pastas Git Databricks

Aqui está uma automação simples que pode ser executada como uma ação do GitHub.

Requisitos

  • Você criou uma pasta Git em um espaço de trabalho Databricks que está rastreando a ramificação base que está sendo mesclada.
  • Você tem um pacote Python que cria os artefatos para colocar em um local DBFS. O seu código deve:
    • Update o repositório associado à sua ramificação preferida (como development) para conter as versões mais recentes dos seus blocos de notas.
    • Crie quaisquer artefatos e copie-os para o caminho da biblioteca.
    • Substitua as últimas versões dos artefatos de compilação para evitar havingupdate manualmente as versões de artefatos em seu trabalho.

Criar um fluxo de trabalho automatizado de CI/CD

  1. Set segredos para que o seu código possa acessar o espaço de trabalho Databricks. Adicione os seguintes segredos ao repositório Github:

    • DEPLOYMENT_TARGET_URL: Set isso para o URL do seu espaço de trabalho. Não inclua a /?o substring.
    • DEPLOYMENT_TARGET_TOKEN: Set isto para um Token de Acesso Pessoal do Databricks (PAT). Você pode generate um token de acesso pessoal do Databricks seguindo as instruções em autenticação de token de acesso pessoal do Azure Databricks.
  2. Navegue até a guia Ações do repositório Git e clique no botão Novo fluxo de trabalho . Na parte superior da página, selectSet crie um fluxo de trabalho você mesmo e cole este script:

    O link da interface do usuário de ações do GitHub

    # This is a basic automation workflow to help you get started with GitHub Actions.
    
    name: CI
    
    # Controls when the workflow will run
    on:
      # Triggers the workflow on push for main and dev branch
      push:
        paths-ignore:
          - .github
        branches:
          # Set your base branch name here
          - your-base-branch-name
    
    # A workflow run is made up of one or more jobs that can run sequentially or in parallel
    jobs:
      # This workflow contains a single job called "deploy"
      deploy:
        # The type of runner that the job will run on
        runs-on: ubuntu-latest
        environment: development
        env:
          DATABRICKS_HOST: ${{ secrets.DEPLOYMENT_TARGET_URL }}
          DATABRICKS_TOKEN:  ${{ secrets.DEPLOYMENT_TARGET_TOKEN }}
          REPO_PATH: /Workspace/Users/someone@example.com/workspace-builder
          DBFS_LIB_PATH: dbfs:/path/to/libraries/
          LATEST_WHEEL_NAME: latest_wheel_name.whl
    
        # Steps represent a sequence of tasks that will be executed as part of the job
        steps:
        # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
        - uses: actions/checkout@v3
    
        - name: Setup Python
          uses: actions/setup-python@v3
          with:
          # Version range or exact version of a Python version to use, using SemVer's version range syntax.
            python-version: 3.8
    
        # Download the Databricks CLI. See https://github.com/databricks/setup-cli
        - uses: databricks/setup-cli@main
    
        - name: Install mods
          run: |
            pip install pytest setuptools wheel
    
        - name: Extract branch name
          shell: bash
          run: echo "##[set-output name=branch;]$(echo ${GITHUB_REF#refs/heads/})"
          id: extract_branch
    
        - name: Update Databricks Git folder
          run: |
            databricks repos update ${{env.REPO_PATH}} --branch "${{ steps.extract_branch.outputs.branch }}"
    
        - name: Build Wheel and send to Databricks DBFS workspace location
          run: |
            cd $GITHUB_WORKSPACE
            python setup.py bdist_wheel
            dbfs cp --overwrite ./dist/* ${{env.DBFS_LIB_PATH}}
            # there is only one wheel file; this line copies it with the original version number in file name and overwrites if that version of wheel exists; it does not affect the other files in the path
            dbfs cp --overwrite ./dist/* ${{env.DBFS_LIB_PATH}}${{env.LATEST_WHEEL_NAME}} # this line copies the wheel file and overwrites the latest version with it
    
  3. Update a seguinte variável de ambiente values com a sua:

    • DBFS_LIB_PATH: O caminho no DBFS para as bibliotecas (rodas) que você usará nesta automação, que começa com dbfs:. Por exemplo,dbfs:/mnt/myproject/libraries.
    • REPO_PATH: O caminho no seu espaço de trabalho Databricks para a pasta Git where notebooks será atualizado.
    • LATEST_WHEEL_NAME: O nome do último arquivo de roda Python compilado (.whl). Isso é usado para evitar a atualização manual de versões de roda em seus trabalhos do Databricks. Por exemplo, your_wheel-latest-py3-none-any.whl.
  4. Select Submeter alterações... para submeter o script como um fluxo de trabalho do GitHub Actions. Depois que a solicitação pull para este fluxo de trabalho for mesclada, vá para a guia Ações do repositório Git e confirme se as ações foram bem-sucedidas.