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.

  1. Clone seu repositório Git existente para seu workspace do Databricks.

  2. 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.

  3. Faça suas modificações no Databricks Notebook e em 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 no Notebook e em outros arquivos na pasta Git.

    2. O contribuidor confirma e envia suas alterações para o provedor Git.

  6. 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:

  7. 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.

Pastas Git de nível superior.

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 conseguido com GitHub Actions. Para mais informações, consulte a APIrepo .

Usar uma entidade de serviço para automação com pastas Git do Databricks

O senhor pode usar o console Databricks account ou o Databricks CLI para criar uma entidade de serviço autorizada a acessar as pastas workspace's Git.

Para criar uma nova entidade de serviço, consulte gerenciar entidade de serviço. Quando o senhor tiver uma entidade de serviço no workspace seu, poderá vincular suas Git credenciais a ela para que possa acessar as pastas do workspaceseu Git como parte da sua automação.

Autorizar uma entidade de serviço a acessar as pastas do Git

Para fornecer acesso autorizado às suas pastas Git para uma entidade de serviço usando o console Databricks account :

  1. Faça login em seu site Databricks workspace. O senhor deve ter privilégios de administrador no site workspace para concluir essas etapas. Se o senhor não tiver privilégios de administrador no site workspace, solicite-os ou entre em contato com o administrador do site account.

  2. No canto superior direito de qualquer página, clique em seu nome de usuário e selecione Configurações.

  3. Selecione Identity and access (Identidade e acesso ) em workspace admin (Administração do espaço de trabalho ) no painel de navegação esquerdo e, em seguida, selecione o botão gerenciar para entidade de serviço.

    A página da entidade de serviço em workspace settings

  4. Na lista de entidades de serviço, selecione a que o senhor deseja atualizar com as credenciais do Git. O senhor também pode criar uma nova entidade de serviço selecionando Add service principal (Adicionar entidade de serviço).

    Criar ou adicionar um princípio de serviço por meio do console Databricks account

  5. Selecione a integraçãoGit tab. (Se o senhor não tiver criado a entidade de serviço ou se não tiver recebido o privilégio de gerente de entidade de serviço, essa opção ficará acinzentada). Em seguida, escolha o provedorGit para as credenciais (como GitHub), selecione Link Git accounte, em seguida, selecione Link.

    O senhor também pode usar um Git personal access tokens (PAT) se não quiser vincular suas próprias credenciais Git. Para usar um PAT, selecione Personal access tokens (Tokens de acesso pessoal ) e forneça as informações de tokens para o Git account usar ao autenticar o acesso da entidade de serviço. Para obter mais detalhes sobre a aquisição de um PAT de um provedor Git, consulte Configurar credenciais do Git & conectar um repositório remoto à Databricks.

    Vinculação de suas credenciais do Git a uma entidade de serviço da Databricks

  6. O senhor será solicitado a selecionar o usuário Git account para vincular. Escolha o usuário Git account que a entidade de serviço usará para acesso e selecione Continue. (Se não encontrar o usuário account que deseja usar, selecione Use a different account.)

  7. Na próxima caixa de diálogo, selecione Authorize Databricks (Autorizar Databricks). O senhor verá brevemente a mensagem "Linking account" e, em seguida, os detalhes atualizados da entidade de serviço.

    Tela de confirmação para credenciais Git vinculadas com sucesso

A entidade de serviço que o senhor escolheu agora aplicará as credenciais Git vinculadas ao acessar o recurso da pasta Databricks workspace Git como parte da sua automação.

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

  1. 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.

  2. 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

  3. 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.

  4. 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.