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

Aprenda técnicas para usar Databricks Git pastas em CI/CD fluxo de trabalho. Ao configurar as pastas Databricks Git no workspace, o senhor pode usar o controle de origem para os arquivos do projeto nos repositórios Git e integrá-los ao seu pipeline 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 da CI/CD com a Databricks, consulte O que é CI/CD na Databricks?

fluxo de desenvolvimento

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

Em sua pasta de usuário nas pastas Git da Databricks, clone o repositório remoto. Uma prática recomendada é criar uma nova ramificação de recurso ou selecionar uma ramificação criada anteriormente para o seu trabalho, em vez de fazer o commit diretamente e enviar as alterações para a ramificação principal. O senhor pode fazer alterações, commit, e enviar alterações para essa ramificação. Quando estiver pronto para merge seu código, o senhor pode fazer isso na interface do usuário das pastas do Git.

Requisitos

Este fluxo de trabalho requer que você já tenha configurado sua integração com o Git.

Observação

Databricks recomenda que cada desenvolvedor trabalhe em sua própria ramificação de recurso. 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 que se baseia na ramificação principal.

Clone seu repositório Git existente para seu workspace do Databricks.
Use a UI de pastas do Git para criar uma ramificação de recurso a partir da ramificação principal. Este exemplo usa um único ramo de recurso feature-b para simplificar. O senhor pode criar e usar várias ramificações de recurso para fazer seu trabalho.
Faça suas modificações no Databricks Notebook e em outros arquivos no repositório.
Confirme e envie suas alterações para seu provedor Git.
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 no Notebook e em outros arquivos na pasta Git.
2. O contribuidor confirma e envia suas alterações para o provedor Git.
Para merge alterações de outras ramificações ou fazer o rebase da ramificação recurso-b no Databricks, na UI das pastas do Git, use um dos seguintes fluxos de trabalho:
- Mesclar ramificações. Se não houver conflito, o merge é enviado para os repositórios remotos do Git usando git push.
- Rebase em outro branch.
Quando estiver pronto para fazer o merge do seu trabalho no repositório Git remoto e na ramificação main, use a UI de pastas do Git para fazer o merge das alterações do recurso-b. Se preferir, em vez disso, o senhor pode fazer merge alterações diretamente no repositório Git, fazendo o backup da pasta Git.

Produção Job fluxo de trabalho

As pastas Git da Databricks oferecem duas opções para executar seu trabalho de produção:

Opção 1: Fornecer uma referência remota do Git na definição do site Job. Por exemplo, executar um Notebook específico no ramo main de um repositório Git.
Opção 2: configurar um repositório Git de produção e chamar as APIs Repos para atualizá-lo programaticamente. execução Job contra a pasta Git do Databricks que clona esse repositório remoto. A chamada da API Repos deve ser a primeira tarefa no site Job.

Opção 1: executar o Job usando o Notebook em um repositório remoto

Simplifique o processo de definição Job e mantenha uma única fonte de verdade executando um Job do Databricks usando Notebook localizado em um repositório Git remoto. Essa referência do Git pode ser um commit, tags ou branch do Git e é fornecida por você na definição Job .

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

Consulte Use Git with Job.

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

Nessa opção, o senhor configura uma pasta Git de produção e uma automação para atualizar a pasta Git no merge.

passo 1: configurar pastas de nível superior

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

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

o passo 2: Configurar atualizações automatizadas para as pastas Git da Databricks com a API de pastas Git

Para manter uma pasta Git no Databricks com a versão mais recente, o senhor pode configurar a automação do Git para chamar a API Repos. Em seu provedor Git, configure a automação que, após cada merge bem-sucedido de um PR na ramificação principal, chama o endpoint da API Repos na pasta Git apropriada para atualizá-la para a versão mais recente.

Por exemplo, no GitHub isso pode ser feito com o GitHub Actions.

Para chamar qualquer API REST do Databricks de dentro de uma célula Notebook do 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 de databricks.sdk.core.

Observação

Se %pip install databricks-sdk --upgrade retornar um erro dizendo “O pacote não foi encontrado”, então o pacote databricks-sdk não foi instalado anteriormente. Reexecução do comando sem a flag --upgrade : %pip install databricks-sdk.

O senhor também pode executar as APIs do SDK da Databricks a partir de um Notebook para recuperar a entidade de serviço do seu workspace. Aqui está um exemplo usando Python e o Databricks SDK para Python.

O senhor também pode usar ferramentas como curl ou Terraform. O senhor não pode usar a interface de usuário do Databricks.

Para saber mais sobre a entidade de serviço em Databricks, consulte gerenciar entidade de serviço. Para obter informações sobre entidade de serviço e CI/CD, consulte entidade de serviço para CI/CD. Para obter mais detalhes sobre como usar o Databricks SDK de um Notebook, leia Use o Databricks SDK para Python de um Databricks Notebook .

Usar uma entidade de serviço com as pastas Git do Databricks

Para executar o fluxo de trabalho acima mencionado com a entidade de serviço:

Crie uma entidade de serviço com Databricks.
Adicione as credenciais git: seu provedor Git PAT para a entidade de serviço.

Para configurar a entidade de serviço e adicionar as credenciais do provedor Git:

Crie uma entidade de serviço do Databricks em seu workspace com a API de entidades de serviço.
Crie um access token do Databricks para uma entidade de serviço do Databricks com a API de gerenciamentotokens .
Adicione as credenciais do seu fornecedor Git ao seu espaço de trabalho com o seu access token Databricks e a API Git Credentials.

Integração do Terraform

O senhor também pode gerenciar as pastas Git do Databricks em uma configuração totalmente automatizada usando o Terraform e o databricks_repo:

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

Para usar o Terraform para adicionar credenciais do Git a uma entidade 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 automatizado de CI/CD com pastas Git da Databricks

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

Requisitos

O senhor criou uma pasta Git em um Databricks workspace que acompanha a ramificação de base que está sendo mesclada.
O senhor tem um pacote Python que cria os artefatos para serem colocados em um local DBFS. Seu código deve:
- Atualize os repositórios associados à sua ramificação preferida (como development) para que contenham as versões mais recentes do seu Notebook.
- Crie todos os artefatos e copie-os para o caminho da biblioteca.
- Substitua as últimas versões dos artefatos de compilação para evitar a necessidade de atualizar manualmente as versões dos artefatos em seu site Job.

Criar um fluxo de trabalho automatizado de CI/CD

Configure segredos para que seu código possa acessar o site Databricks workspace. Adicione os seguintes segredos ao repositório do Github:
- DEPLOYMENT_TARGET_URL: Defina isso como seu URL workspace. Não inclua a substring /?o.
- DEPLOYMENT_TARGET_TOKEN: defina isso como um Databricks Personal access token (PAT). O senhor pode gerar um Databricks PAT seguindo as instruções em Databricks personal access token authentication.

Navegue até Actions tab de seus repositórios Git e clique no botão New workflow (Novo fluxo de trabalho ). Na parte superior da página, selecione Configurar você mesmo um fluxo de trabalho e cole este script:

O link "configure um fluxo de trabalho você mesmo" na interface do usuário do GitHub Actions

# 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

Atualize os seguintes valores de variável de ambiente com os seus próprios valores:
- DBFS_LIB_PATH: O caminho no DBFS para a biblioteca (rodas) que o senhor usará nessa automação, que começa com dbfs:. Por exemplo,dbfs:/mnt/myproject/libraries.
- REPO_PATH: O caminho em seu Databricks workspace para a pasta Git onde o Notebook será atualizado.
- LATEST_WHEEL_NAME: O nome do último arquivo Python wheel compilado (.whl). Isso é usado para evitar a atualização manual das versões de roda no trabalho do Databricks. Por exemplo, your_wheel-latest-py3-none-any.whl.
Selecione confirmar alterações... para commit o script como um GitHub Actions fluxo de trabalho. Depois que o pull request para esse fluxo de trabalho for mesclado, acesse Actions tab do repositório Git e confirme se as ações foram bem-sucedidas.