CI/CD untuk Aplikasi Databricks dengan GitHub Actions

Halaman ini menjelaskan cara mengotomatiskan penyebaran aplikasi Databricks dari GitHub menggunakan GitHub Actions dan Declarative Automation Bundles. Ini mencakup federasi identitas beban kerja, YAML alur kerja, dan pemeriksaan kesehatan yang mengonfirmasi bahwa aplikasi melayani kode terbaru setelah setiap penyebaran.

Untuk panduan GitHub Actions generik untuk pekerjaan dan alur Azure Databricks, lihat GitHub Actions. Untuk menyiapkan federasi identitas workload, lihat Aktifkan federasi identitas workload untuk GitHub Actions.

Requirements

Langkah 1. Konfigurasikan federasi identitas beban kerja

Federasi identitas beban kerja memungkinkan runner GitHub Actions mengautentikasi dengan Azure Databricks menggunakan token OIDC berumur pendek alih-alih menyimpan kredensial di repositori Anda.

Ikuti langkah-langkah di Aktifkan federasi identitas beban kerja untuk GitHub Actions guna membuat kebijakan federasi GitHub Actions pada perwakilan layanan Anda. Perhatikan ID aplikasi perwakilan layanan (UUID) dan URL ruang kerja Anda. Anda memerlukan keduanya sebagai variabel dalam alur kerja.

Kemudian berikan prinsipal layanan CAN MANAGE izin pada aplikasi tersebut, atau izin ruang kerja untuk membuat aplikasi jika aplikasi tersebut belum ada. Lihat Mengonfigurasi izin untuk aplikasi Databricks.

Langkah 2. Konfigurasikan repositori GitHub

Di repositori GitHub Anda, buat lingkungan penyebaran untuk menyimpan variabel koneksi ruang kerja. Menggunakan lingkungan juga memungkinkan Anda memerlukan persetujuan manual sebelum penyebaran dijalankan.

  1. DiLingkungan>, buat lingkungan bernama prod (atau nama apa pun referensi alur kerja Anda).
  2. Untuk variabel Lingkungan, tambahkan yang berikut ini:
Variabel Value
DATABRICKS_HOST URL ruang kerja Anda, misalnya https://my-workspace.cloud.databricks.com
DATABRICKS_CLIENT_ID ID aplikasi prinsipal layanan dari Langkah 1

Kedua nilai tersebut bukan kredensial. Kebijakan federasi pada service principal menentukan siapa yang dapat melakukan autentikasi sebagai service principal tersebut, sehingga ID klien saja tidak otomatis memberikan akses. Anda tidak memerlukan rahasia klien.

Langkah 3. Mengonfigurasi bundel Anda untuk penyebaran produksi

Di databricks.yml, deklarasikan ruang host kerja eksplisit dan root_path pada target Anda prod . Ini memastikan bundel disebarkan ke lokasi yang sama pada setiap proses. Validasi mode produksi memerlukan kedua kolom kecuali run_as disetel ke service principal. Lihat Mode penyebaran Bundel Otomatisasi Deklaratif.

targets:
  prod:
    mode: production
    workspace:
      host: https://my-workspace.cloud.databricks.com
      root_path: /Workspace/Users/<service-principal-or-owner>/.bundle/${bundle.name}/${bundle.target}
    resources:
      apps:
        my_app:
          name: my-app
          source_code_path: ./app

Ganti <service-principal-or-owner> dengan pengguna ruang kerja yang memiliki artefak bundel, yang biasanya berupa ID aplikasi prinsipal layanan.

Ganti ./app dengan jalur ke kode sumber aplikasi Anda relatif terhadap databricks.yml. Bidang source_code_path diperlukan saat kode aplikasi berada di repositori yang sama dengan bundel. Jika kode aplikasi Anda berada di repositori terpisah, gunakan git_source sebagai gantinya. Lihat aplikasi.

Langkah 4. Menambahkan alur kerja penyebaran

Tambahkan .github/workflows/deploy.yml ke repositori Anda:

name: Deploy to Databricks Apps

on:
  workflow_dispatch:
  # Uncomment to deploy on every push to main once the workflow is validated.
  # push:
  #   branches: [main]

permissions:
  id-token: write # required for OIDC federation
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: prod
    env:
      DATABRICKS_AUTH_TYPE: github-oidc
      DATABRICKS_HOST: ${{ vars.DATABRICKS_HOST }}
      DATABRICKS_CLIENT_ID: ${{ vars.DATABRICKS_CLIENT_ID }}
    steps:
      - uses: actions/checkout@v4

      - name: Install Databricks CLI
        uses: databricks/setup-cli@main

      - name: Validate bundle
        run: databricks bundle validate --target prod

      - name: Deploy bundle
        run: databricks bundle deploy --target prod

      - name: Start or restart app
        run: databricks bundle run my_app --target prod

Ganti my_app di langkah terakhir dengan kunci sumber daya yang Anda databricks.yml gunakan di bawah resources.apps.

Runner memerlukan izin id-token: write untuk meminta token OIDC. Tindakan databricks/setup-cli membaca DATABRICKS_AUTH_TYPE=github-oidc dan menangani autentikasi secara otomatis.

Warning

databricks bundle deploy mengunggah kode sumber dan memperbarui sumber daya, tetapi tidak memulai ulang proses aplikasi. Jika Anda melewati langkah terakhir databricks bundle run, proses deploy berhasil di CI sementara aplikasi tetap menjalankan kode versi sebelumnya. Selalu jalankan sumber daya bundel setelah menyebarkan.

Langkah 5. Tunggu hingga aplikasi sehat

Databricks merekomendasikan penambahan langkah untuk memeriksa status secara berkala setelah penyebaran. databricks bundle run keluar segera setelah memberi sinyal aplikasi untuk memulai, tetapi aplikasi mungkin belum berjalan. Ini masih dapat gagal selama startup karena masalah seperti dependensi yang hilang, variabel lingkungan yang hilang, atau konflik port. Menambahkan langkah polling memastikan startup yang gagal juga gagal dalam alur kerja:

- name: Wait for app to be running
  env:
    APP_NAME: my-app
  run: |
    for i in $(seq 1 20); do
      STATE=$(databricks apps get "$APP_NAME" --output json | jq -r '.app_status.state')
      echo "Attempt $i/20: state=$STATE"
      if [ "$STATE" = "RUNNING" ]; then
        exit 0
      fi
      sleep 15
    done
    echo "App did not reach RUNNING state within 5 minutes" >&2
    exit 1

Atur APP_NAME ke nilai yang Anda databricks.yml deklarasikan di bawah resources.apps.<key>.name, bukan kunci sumber daya bundel.

Menangani aplikasi yang sudah ada

Nama aplikasi harus unik di seluruh ruang kerja. Langkah bundle deploy gagal dengan An app with the same name already exists ketika bundel lain (atau aplikasi yang dibuat secara manual) sudah memiliki aplikasi dengan nama itu. Tautkan paket Anda ke aplikasi yang sudah ada alih-alih membuat ulang aplikasi tersebut.

Jalankan ini sekali secara lokal untuk melampirkan bundel ke aplikasi yang ada:

databricks bundle deployment bind my_app <existing-app-name> --target prod --auto-approve

Kemudian jalankan kembali alur kerja. Penerapan berikutnya menggunakan kembali kaitan tersebut.

Jika aplikasi yang ada memiliki konfigurasi sisi server (seperti budget_policy_id) yang tidak terdapat dalam databricks.yml Anda, salin konfigurasi tersebut ke file bundel sebelum men-deploy ulang. Ketidakcocokan muncul sebagai kesalahan Terraform "hasil yang tidak konsisten" selama langkah penyebaran bundel.

Memilih pemicu

Mulailah dengan workflow_dispatch sehingga penyebaran pertama adalah manual. Setelah beberapa eksekusi berhasil, tambahkan push: branches: [main] untuk menyebarkan pada setiap penggabungan.

Untuk lapisan pengamanan tambahan, konfigurasikan lingkungan prod dengan peninjau wajib di Settings>Environments>prod>Deployment protection rules. Setiap eksekusi alur kerja menunggu pemberi persetujuan sebelum pekerjaan penyebaran dimulai.

Langkah berikutnya

  • Last updated on