Pular para o conteúdo principal

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 arquivos de 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 em nível de usuário são criadas automaticamente quando os usuários clonam pela primeira vez um repositório remoto. É possível pensar nas pastas Git do Databricks nas pastas do 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 poderá fazê-lo na UI de pastas Git.

Requisitos

Esse fluxo de trabalho exige que o senhor já tenha configurado a integração com o Git.

nota

Databricks recomenda que cada desenvolvedor trabalhe em seu próprio ramo de recurso. Para obter informações sobre como resolver conflitos em merge, consulte Resolver conflitos em merge.

Colaborar em pastas do Git

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

  1. Clone o repositório Git existente para o Databricks workspace .

  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 do repositório.

  4. faça o commit e envie suas alterações para o 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 filial, um colega de trabalho faz alterações no Notebook e em outros arquivos da pasta Git.
    2. O colaborador faz o commit e envia suas alterações para o provedor Git.
  6. Para merge alterações de outras ramificações ou rebase da ramificação recurso-b em Databricks, na UI das pastas 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 alterações no merge diretamente no repositório Git que faz o backup da pasta Git.

Produção Trabalho fluxo de trabalho

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

  • Opção 1 : Fornecer uma referência Git remota na definição do trabalho. Por exemplo, executar um Notebook específico na ramificação 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 na pasta Databricks Git que clona esse repositório remoto. A chamada Repos API deve ser a primeira tarefa do trabalho.

Opção 1: execução do trabalho usando o Notebook em um repositório remoto

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

Isso ajuda a evitar alterações não intencionais no trabalho de produção, 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 a etapa de CD, 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.

Etapa 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 de 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 entidade(s) de serviço(s) com permissões CAN EDIT e CAN MANAGE para evitar edições acidentais no seu código de produção por usuários workspace.

Pastas Git de nível superior.

Etapa 2: Configure 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 Repos API endpoint 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 obter mais informações, consulte o Repos API.

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 em workspace seu, poderá vincular suas Git credenciais a ela para que ela possa acessar as pastas do workspaceseu Git como parte da 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 com o 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 uma Databricks workspace que acompanha o branch de base que está sendo mesclado.
  • O senhor tem um pacote Python que cria os artefatos para serem colocados em um local DBFS. Seu código deve:
    • Atualize o repositório associado ao ramo de sua preferência (como development) para conter as versões mais recentes do 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 trabalho.

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 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 tokens (PAT). O senhor pode gerar um Databricks PAT seguindo as instruções em Databricks autenticação de tokens de acesso pessoal.
  2. Navegue até Actions tab do seu repositório Git e clique no botão New 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

    YAML
    # 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 em 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 em seu Databricks Job. 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.