Freigeben über

CI/CD-Techniken mit Git und Databricks-Git-Ordnern (Repos)

  • Artikel

Lernen Sie Techniken für die Verwendung von Databricks-Git-Ordnern in CI/CD-Workflows kennen. Indem Sie Die Git-Ordner Databricks im Arbeitsbereich konfigurieren, können Sie die Quellcodeverwaltung für Projektdateien in Git-Repositorys verwenden und sie in Ihre Daten-Engineering-Pipelines integrieren.

In der folgenden Abbildung sehen Sie eine Übersicht der Techniken und des Workflows:

Übersicht über CI/CD-Techniken für Git-Ordner

Eine Übersicht über CI/CD mit Azure Databricks finden Sie unter Was ist CI/CD in Azure Databricks?.

Entwicklungsflow

Databricks-Git-Ordner weisen Ordner auf Benutzerebene auf. Ordner auf Benutzerebene werden automatisch erstellt, wenn Benutzer ein Remoterepository zum ersten Mal klonen. Sie können sich Databricks-Git-Ordner in Benutzerordnern als „lokale Auscheckvorgänge“ vorstellen, die für jeden Benutzer individuell sind und mit denen Benutzer Änderungen an ihrem Code vornehmen.

Klonen Sie in Ihrem Benutzerordner in Databricks-Git-Ordnern Ihr Remoterepository. Eine bewährte Methode besteht darin, einen neuen Featurebranch zu erstellen oder einen zuvor erstellten Branch für Ihre Arbeit auszuwählen, anstatt Änderungen direkt in den Mainbranch zu committen und zu pushen. Sie können in diesem Branch Änderungen vornehmen, committen und pushen. Wenn Sie bereit sind, Ihren Code zusammenzuführen, können Sie dies auf der Benutzeroberfläche für Git-Ordner tun.

Anforderungen

Für diesen Workflow müssen Sie Ihre Git-Integration bereits eingerichtet haben.

Hinweis

Databricks empfiehlt, dass jede*r Entwickler*in in seinem eigenen Featurebranch arbeitet. Informationen zum Beheben von Mergekonflikten finden Sie unter Auflösen von Mergekonflikten.

Zusammenarbeiten in Git-Ordnern

Im folgenden Workflow wird ein Branch namens feature-b verwendet, der auf dem Mainbranch basiert.

  1. Klonen Sie Ihr vorhandenes Git-Repository in Ihren Databricks-Arbeitsbereich.
  2. Verwenden Sie die Benutzeroberfläche für Git-Ordner, um aus dem Mainbranch einen Featurebranch zu erstellen. In diesem Beispiel wird der Einfachheit halber ein einzelner Featurebranch feature-b verwendet. Sie können mehrere Featurebranches erstellen und verwenden, um Ihre Arbeit zu erledigen.
  3. Nehmen Sie Ihre Änderungen an Azure Databricks-Notebooks und anderen Dateien im Repository vor.
  4. Committen und pushen Sie Ihre Änderungen auf Ihren Git-Anbieter.
  5. Mitwirkende können nun das Git-Repository in ihren eigenen Benutzerordner klonen.
    1. Bei der Arbeit an einem neuen Branch nimmt ein Kollege Änderungen an den Notebooks und anderen Dateien im Git-Ordner vor.
    2. Der Mitwirkende oder die Mitwirkende committet und pusht seine Änderungen auf den Git-Anbieter.
  6. Um Änderungen aus anderen Branches zusammenzuführen oder ein Rebase für den Branch feature-b in Databricks auszuführen, verwenden Sie auf der Benutzeroberfläche für Git-Ordner einen der folgenden Workflows:
  7. Wenn Sie Ihre Arbeit mit dem Git-Remoterepository und dem Branch main zusammenzuführen möchten, verwenden Sie die Benutzeroberfläche für Git-Ordner, um die Änderungen von feature-b zusammenzuführen. Wenn Es Ihnen lieber ist, können Sie stattdessen Änderungen direkt mit dem Git-Repository zusammenführen, das Ihren Git-Ordner unterstützt.

Workflow für Produktionsauftrag

Databricks-Git-Ordner bieten zwei Optionen zum Ausführen Ihrer Produktionsaufträge:

  • Option 1: Bereitstellen eines Git-Remoteverweises in der Auftragsdefinition. Führen Sie beispielsweise ein bestimmtes Notebook in der main-Verzweigung eines Git-Repositorys aus.
  • Option 2: Richten Sie ein Git-Repository für die Produktion ein, und rufen Sie Repos-APIs auf, um es programmgesteuert zu aktualisieren. Ausführen von Aufträgen für den Databricks-Git-Ordner, der dieses Remoterepository klont. Der Repos-API-Aufruf sollte die erste Aufgabe im Auftrag sein.

Option 1: Ausführen von Aufträgen mithilfe von Notebooks in einem Remoterepository

Vereinfachen Sie den Auftragsdefinitionsprozess, und behalten Sie eine maßgebliche Quelle bei, indem Sie einen Azure Databricks-Auftrag mithilfe von Notebooks in einem Git-Remoterepository ausführen. Dieser Git-Verweis kann ein Git-Commit, -Tag oder -Branch sein und wird von Ihnen in der Auftragsdefinition bereitgestellt.

Dadurch wird sichergestellt, dass Sie unbeabsichtigte Änderungen an Ihrem Produktionsauftrag verhindern können, z. B. wenn ein Benutzer lokale Änderungen in einem Produktionsrepository vornimmt oder Branches umstellt. Außerdem wird der Schritt „Continuous Deployment“ automatisiert, da Sie keinen separaten Produktions-Git-Ordner in Databricks erstellen, nicht die Berechtigungen dafür verwalten und es nicht auf dem neuesten Stand halten müssen.

Weitere Informationen finden Sie unter Verwenden von versionskontrolliertem Quellcode in einem Azure Databricks-Auftrag.

Option 2: Einrichten eines Produktions-Git-Ordners und der Git-Automatisierung

Mit dieser Option richten Sie einen Produktions-Git-Ordner und die Automatisierung ein, um den Git-Ordner beim Merge zu aktualisieren.

Schritt 1: Einrichten von Ordnern der obersten Ebene

Der Administrator erstellt Ordner der obersten Ebene, die nicht für Benutzer gedacht sind. Der häufigste Anwendungsfall für diese Ordner der obersten Ebene ist das Erstellen von Entwicklungs-, Staging- und Produktionsordnern, die Databricks-Git-Ordner für die entsprechenden Versionen oder Branches für Entwicklung, Staging und Produktion enthalten. Wenn Ihr Unternehmen z. B. den main-Branch für die Produktion verwendet, muss der Git-Ordner für die Produktion den main-Branch darin ausgecheckt haben.

Berechtigungen für diese Ordner der obersten Ebene sind in der Regel für alle Benutzer ohne Administratorrechte innerhalb des Arbeitsbereichs schreibgeschützt. Für solche Ordner auf oberster Ebene empfehlen wir Ihnen, Dienstprinzipalen nur die Berechtigungen KANN BEARBEITEN und KANN VERWALTEN zu erteilen, um zu vermeiden, dass Arbeitsbereichsbenutzer versehentlich Änderungen an Ihrem Code vornehmen.

Git-Ordner der obersten Ebene

Schritt 2: Einrichten automatisierter Updates für Databricks-Git-Ordner mit der Git-Ordner-API

Damit ein Git-Ordner in Databricks immer die neueste Version hat, können Sie die Git-Automatisierung so einrichten, dass die Repos-API aufgerufen wird. Richten Sie in Ihrem Git-Anbieter Automatisierung ein, die nach jeder erfolgreichen Zusammenführung eines Pull Requests in den Mainbranch den Repos-API-Endpunkt im entsprechenden Git-Ordner aufruft, um diesen Ordner auf die neueste Version zu aktualisieren.

Auf GitHub kann dies beispielsweise mit GitHub Actions erreicht werden. Weitere Informationen finden Sie in der Repository-API.

Um eine Databricks-REST-API aus einer Databricks-Notebookzelle aufzurufen, installieren Sie zuerst das Databricks SDK mit %pip install databricks-sdk --upgrade (für die neuesten Databricks-REST-APIs) und importieren dann ApiClient aus databricks.sdk.core.

Hinweis

Wenn %pip install databricks-sdk --upgrade den Fehler „Das Paket konnte nicht gefunden werden“ zurückgibt, wurde das Paket databricks-sdk zuvor nicht installiert. Führen Sie den Befehl ohne das Flag --upgrade erneut aus: %pip install databricks-sdk.

Sie können Databricks SDK-APIs auch aus einem Notebook ausführen, um die Dienstprinzipale für Ihren Arbeitsbereich abzurufen. Hier ist ein Beispiel mit Python und dem Databricks SDK für Python.

Sie können auch Tools wie curl, Postman oder Terraform verwenden. Die Benutzeroberfläche von Azure Databricks kann nicht verwendet werden.

Weitere Informationen zu Dienstprinzipalen in Azure Databricks finden Sie unter Verwalten von Dienstprinzipalen. Informationen zu Dienstprinzipalen und CI/CD finden Sie unter Dienstprinzipale für CI/CD. Weitere Informationen zur Verwendung des Databricks SDK aus einem Notebook finden Sie unter Verwenden des Databricks SDK für Python aus einem Databricks-Notebook.

Verwenden eines Dienstprinzipals mit Databricks-Git-Ordnern

So führen Sie die oben genannten Workflows mit Dienstprinzipalen aus

  1. Erstellen Sie mithilfe von Azure Databricks einen Dienstprinzipal.
  2. Fügen Sie die Git-Anmeldeinformationen hinzu. Verwenden Sie das persönliche Zugriffstoken des Git-Anbieters für den Dienstprinzipal.

So richten Sie Dienstprinzipale ein und fügen dann Git-Anbieteranmeldeinformationen hinzu:

  1. Erstellen eines Dienstprinzipals Weitere Informationen finden Sie unter Ausführen von Aufträgen mit Dienstprinzipalen.
  2. Erstellen Sie ein Microsoft Entra ID-Token für einen Dienstprinzipal.
  3. Nachdem Sie einen Dienstprinzipal erstellt haben, fügen Sie ihn Ihrem Azure Databricks-Arbeitsbereich mit der Dienstprinzipal-API hinzu.
  4. Fügen Sie Ihre Git-Anbieter-Anmeldeinformationen Ihrem Arbeitsbereich mit Ihrem Microsoft Entra ID-Token und der Git-Anmeldeinformationen-API hinzu.

Terraform-Integration

Sie können Databricks-Git-Ordner auch in einem vollständig automatisierten Setup mit Terraform und databricks_repo verwalten:

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

Um Terraform zum Hinzufügen von Git-Anmeldeinformationen zu einem Dienstprinzipal zu verwenden, fügen Sie die folgende Konfiguration hinzu:

  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"
  }

Konfigurieren einer automatisierten CI/CD-Pipeline mit Databricks-Git-Ordnern

Hier ist eine einfache Automatisierung, die als GitHub-Aktion ausgeführt werden kann.

Anforderungen

  1. Sie haben einen Git-Ordner in einem Databricks-Arbeitsbereich zur Nachverfolgung des zusammengeführten Basisbranch erstellt.
  2. Sie verfügen über ein Python-Paket, das die Artefakte erstellt, die an einem DBFS-Speicherort platziert werden sollen. Ihr Code muss:
    • Aktualisieren Sie das Repository, das Ihrer bevorzugten Verzweigung (z. B. development) zugeordnet ist, um die neuesten Versionen Ihrer Notebooks zu enthalten.
    • Erstellen Sie alle Artefakte, und kopieren Sie sie in den Bibliothekspfad.
    • Ersetzen Sie die letzten Versionen von Buildartefakten, um zu vermeiden, dass Sie Artefaktversionen in Ihrem Auftrag manuell aktualisieren müssen.

Schritte

Hinweis

Schritt 1 muss von einem Administrator des Git-Repositorys ausgeführt werden.

  1. Richten Sie geheime Schlüssel ein, damit Ihr Code auf den Databricks-Arbeitsbereich zugreifen kann. Fügen Sie dem Github-Repository die folgenden geheimen Schlüssel hinzu:

  2. Navigieren Sie zur Registerkarte Aktionen Ihres Git-Repositorys und klicken Sie auf die Schaltfläche Neuer Workflow. Wählen Sie oben auf der Seite Workflow selbst einrichten aus und fügen Sie dieses Skript ein:

    Der Link „Workflow selbst einrichten“ in der Benutzeroberfläche von 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:
      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
      env:
        DBFS_LIB_PATH: dbfs:/path/to/libraries/
        REPO_PATH: /Repos/path/here
        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@v2

      - name: Setup Python
        uses: actions/setup-python@v2
        with:
        # Version range or exact version of a Python version to use, using SemVer's version range syntax.
          python-version: 3.8

      - name: Install mods
        run: |
          pip install databricks-cli
          pip install pytest setuptools wheel

      - name: Configure CLI
        run: |
          echo "${{ secrets.DEPLOYMENT_TARGET_URL }} ${{ secrets.DEPLOYMENT_TARGET_TOKEN }}" | databricks configure --token

      - 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 --path ${{env.REPO_PATH}} --branch "${{ steps.extract_branch.outputs.branch }}"

      - name: Build Wheel and send to Databricks workspace DBFS 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. Aktualisieren Sie die folgenden Umgebungsvariablenwerte mit Ihren eigenen:

    • DBFS_LIB_PATH: Der Pfad in DBFS zu den Bibliotheken (Wheels), die Sie in dieser Automatisierung verwenden, beginnen mit dbfs:. Beispiel: dbfs:/mnt/myproject/libraries.
    • REPO_PATH: Der Pfad in Ihrem Databricks-Arbeitsbereich zum Git-Ordner, in dem Notebooks aktualisiert werden. Beispiel: /Repos/Develop.
    • LATEST_WHEEL_NAME: Der Name der zuletzt kompilierten Python-Wheel-Datei (.whl). Dieser wird verwendet, um die manuelle Aktualisierung von Wheel-Versionen in Ihren Databricks-Aufträgen zu vermeiden. Beispiel: your_wheel-latest-py3-none-any.whl.

  4. Wählen Sie Änderungen übernehmen... aus, um das Skript als GitHub Actions-Workflow zu übernehmen. Nachdem die Pullanforderung für diesen Workflow zusammengeführt wurde, wechseln Sie zur Registerkarte Aktionen des Git-Repositorys und überprüfen Sie den erfolgreichen Abschluss der Aktionen.