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.
Para obter uma visão geral do CI/CD com o Azure Databricks, consulte O que é CI/CD no Azure Databricks?.
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.
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.
O fluxo de trabalho a seguir usa uma ramificação chamada feature-b
baseada na ramificação principal.
- Clone seu repositório Git existente em seu espaço de trabalho Databricks.
- 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. - Faça suas modificações em blocos de anotações do Azure Databricks e 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.
- Trabalhando em uma nova ramificação, um colega de trabalho faz alterações nos blocos de anotações e outros arquivos na pasta Git.
- O colaborador confirma e envia suas alterações para o provedor Git.
- 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:
-
Mesclar ramificações. Se não houver conflito, a mesclagem será enviada por push para o repositório Git remoto usando
git push
o . - Rebaseie em outro ramo.
-
Mesclar ramificações. Se não houver conflito, a mesclagem será enviada por push para o repositório Git remoto usando
- 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.
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.
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.
Nesta opção, você set uma pasta Git de produção e automação para update a pasta Git na mesclagem.
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.
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.
Para executar os fluxos de trabalho acima mencionados com entidades de serviço:
- Crie uma entidade de serviço com o Azure Databricks.
- 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:
- Crie uma entidade de serviço. Consulte Executar trabalhos com entidades de serviço.
- Crie um token de ID do Microsoft Entra para uma entidade de serviço.
- 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.
- 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.
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"
}
Aqui está uma automação simples que pode ser executada como uma ação do GitHub.
- 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.
-
Update o repositório associado à sua ramificação preferida (como
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.
-
DEPLOYMENT_TARGET_URL: Set isso para o URL do seu espaço de trabalho. Não inclua a
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:
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
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
.
-
DBFS_LIB_PATH: O caminho no DBFS para as bibliotecas (rodas) que você usará nesta automação, que começa com
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.