Konfiguruj zmienne środowiskowe dla zadań bezserwerowych

Zmienne środowiskowe zapewniają kodowi aplikacji konfigurację zależną od wdrożenia w bezserwerowych zadaniach Lakeflow Jobs. Zdefiniuj wpisy zmiennych środowiskowych o nazwie na zadaniu, a następnie wybierz wpis dla każdego zadania, które go wymaga.

Te zmienne środowiskowe dotyczą tylko zadań serverless. Środowisko obliczeniowe bezserwerowe nie obsługuje skryptów inicjalizacyjnych. Jeśli Twoje zadanie działa w klasycznym środowisku obliczeniowym, zobacz Ustawianie i używanie zmiennych środowiskowych za pomocą skryptów inicjalizacyjnych.

Jak działają zmienne środowiskowe

Wpisy zmiennych środowiskowych są definiowane na poziomie zadania. Każdy wpis ma unikalny klucz i zawiera zmienne wewnętrzne, ścieżki do .env plików lub oba te elementy. Wpis działa ze wszystkimi typami zadań bez serwera. Klucz wejściowy może zawierać tylko litery, cyfry, myślniki i podkreślenia. Każda nazwa zmiennej w linii musi zaczynać się od litery lub podkreślenia i może zawierać tylko litery, cyfry i podkreślenia.

Każde zadanie wybiera pojedynczą zmienną środowiskową z elementem environment_variables_key i otrzymuje tylko zmienne tego wpisu. Wpisy nigdy nie są łączone, a jeden wpis nie może dziedziczyć po innym. Zadanie, które pomija zadanie environment_variables_key , nie otrzymuje zmiennych środowiskowych.

Zmienne środowiskowe są dostępne tylko dla kodu aplikacji uruchamianego w procesie zadania. Nie są dostępne dla logiki wykonawczej Sparka.

Requirements

• Administrator przestrzeni roboczej włączył zmienne środowiskowe w Lakeflow Jobs na stronie „Previews”. Zobacz Zarządzanie wersjami zapoznawczami usługi Azure Databricks.
• Zadania działające w środowisku bezserwerowym w wersji 5 lub nowszej.
• W przypadku plików .env tożsamość Uruchom jako zadania musi mieć uprawnienia do odczytu każdego pliku.
• W przypadku odwołań do wpisów tajnych tożsamość ustawiona w opcji Run as musi mieć co najmniej READ uprawnienie do każdego wskazanego zakresu wpisów tajnych. Zobacz Secret ACLs.

Limitations

Funkcje zdefiniowane przez użytkownika (UDF) nie mogą odczytywać zmiennych środowiskowych, ponieważ UDF działają w logice wykonawczej Spark, a nie w procesie zadania.

Obsługiwane są tylko sekrety Azure Databricks na poziomie przestrzeni roboczej. Wsparcie dla sekretów Unity Catalog wkrótce pojawi się.

Obowiązują następujące ograniczenia:

Użyj plików .env

Możesz ładować zmienne środowiskowe z plików workspace (/Workspace/...) lub plików z woluminów katalogu Unity (/Volumes/...). Dodaj ścieżki plików do listy Files elementu w interfejsie użytkownika lub do tablicy spec.files w interfejsie API Jobs. Pliki są odczytywane na początku zadania, a nie podczas tworzenia lub aktualizacji zadania.

W przypadku zadań bezserwerowych usługa Azure Databricks używa własnego formatu plików .env. Obowiązują następujące reguły:

• Zdefiniuj jedną zmienną w każdym wierszu jako KEY=VALUE, bez wiodących białych znaków ani spacji przed =.
• Nazwy zmiennych muszą zaczynać się od litery ASCII lub podkreślenia. Pozostałe znaki mogą być literami ASCII, cyframi lub podkreśleniami.
• Wszystko po pierwszym = to wartość, łącznie ze spacjami i dodatkowymi znakami =. Dozwolone są wartości puste. Wartości mogą zawierać tekst Unicode. Zapisz plik przy użyciu kodowania UTF-8.
• Puste i tylko białe linie są ignorowane. Aby dodać komentarz, wpisz # jako pierwszy znak w linijce.

Na przykład execution.env plik może zawierać:

# Application configuration
APP_ENV=production
REGION=us-west-2
GREETING=こんにちは
OPTIONAL_VALUE=

Ten format nie interpretuje cudzysłowów, sekwencji specjalnych, komentarzy wbudowanych ani odwołań do zmiennych, takich jak ${OTHER_VARIABLE}. Te postacie pozostają częścią wartości. Na przykład APP_ENV="production" obejmuje cudzysłowy w wartości. Prefiks export jest nieprawidłowy.

Sekretne odwołania używają osobnej składni i są rozwiązywane po połączeniu pliku i zmiennych wbudowanych. Zobacz Korzystanie z wpisów tajnych.

Jeśli zmienna ma wiele definicji:

• W pliku pierwszeństwo ma ostatnia definicja.
• Między plikami, plik podany później nadpisuje wartości z plików podanych wcześniej.
• Zmienne inline nadpisują wartości z plików.

Na przykład, jeśli plik definiuje LOG_LEVEL=DEBUG i wpis również definiuje zmienną LOG_LEVEL=INFOw linii , zadanie otrzymuje LOG_LEVEL=INFO.

Jeśli plik zawiera nieprawidłową linię lub przekracza limit rozmiaru pliku lub linii, zadanie zostaje nieudane.

Używanie tajemnic

Zmienne środowiskowe dla zadań bezserwerowych obsługują sekrety Azure Databricks na poziomie przestrzeni roboczej, które są zorganizowane w zakresy wpisów tajnych. Użyj odwołania do sekretu, aby przekazać poświadczenia lub tokeny do kodu aplikacji bez przechowywania wartości sekretu w konfiguracji zadania lub pliku .env. Aby utworzyć zakres wpisów tajnych i dodać wpis tajny, zobacz Zarządzanie wpisami tajnymi.

Ustaw wartość zmiennej środowiskowej na sekretne odwołanie w następującym formacie:

{{secrets/<scope-name>/<secret-name>}}

Zastąp <scope-name> nazwą sekretnego zakresu i <secret-name> kluczem sekretu w tym zakresie. Odniesienie musi być całą wartością. Odwołania osadzone w większym ciągu, takie jak Bearer {{secrets/production/service-token}}, pozostają tekstem dosłownym.

W interfejsie wpisz referencję jako wartość w sekcji Zmienne. W API Jobs użyj go jako wartości w spec.variables:

{
  "SERVICE_TOKEN": "{{secrets/production/service-token}}"
}

Aby odwołać się do tego samego sekretu w pliku .env , dodaj następującą linię bez cudzysłowu czy spacji wokół odniesienia:

SERVICE_TOKEN={{secrets/production/service-token}}

Azure Databricks rozwiązuje odwołania do wpisów tajnych, gdy zadanie się rozpoczyna, używając tożsamości Run as zadania. Zadanie otrzymuje ustaloną wartość sekretu w swoim środowisku procesowym. Kod aplikacji odczytuje go w os.environ["SERVICE_TOKEN"] Pythonie lub sys.env("SERVICE_TOKEN") Scali.

Azure Databricks próbuje maskować wartości wpisów tajnych w danych wyjściowych notesu, ale maskowanie odbywa się w miarę możliwości. Sekrety, które Twoja aplikacja drukuje lub zapisuje do logów, mogą pojawiać się w tekście jawnym w logach obliczeniowych, nawet gdy wynik z notatnika wyświetla [REDACTED]. Unikaj drukowania wartości sekretów lub zapisywania ich do logów. Zobacz Redakcję tajną.

Te same zasady pierwszeństwa dotyczą odwołań do wpisów tajnych. Obliczane są tylko uzyskane wartości. Ustawienia zadań zachowują odwołania do sekretów, a nie rozwinięte wartości wpisów tajnych.

Jeśli odwołany sekret nie istnieje lub tożsamość Run as nie ma prawa do jego odczytu, zadanie kończy się niepowodzeniem przed uruchomieniem kodu aplikacji. Sprawdź nazwę zakresu, tajny klucz oraz uprawnienia tajnego zakresu.

Konfiguruj zmienne środowiskowe w interfejsie użytkownika

Na zakładce Zadania w zadaniu wybierz zadanie. Użyj zmiennych środowiskowych do wyboru lub utworzenia wpisu zmiennej środowiskowej, takiej jak production.

W Configure environment variables wprowadź nazwę. Opcjonalnie można dodać pary klucz-wartość w sekcji Zmienne, ścieżki do plików .env w sekcji Pliki lub jedno i drugie. Możesz też zostawić obie sekcje puste. Kliknij Zapisz.

Konfiguruj zmienne środowiskowe za pomocą Jobs API

Użyj pola environment_variables w żądaniu POST /api/2.2/jobs/create, aby zdefiniować wpisy zmiennych środowiskowych. Ustaw environment_variables_key na każdym zadaniu, które korzysta z wpisu.

Przed uruchomieniem następującego przykładu utwórz sekret service-token w zakresie production i przyznaj dostęp do niego tożsamości zadania Run as. Zobacz Korzystanie z wpisów tajnych. Przykład definiuje oddzielne wpisy zmiennych środowiskowych dla zadania notebooka oraz zadania JAR. Każdy wpis używa spec.variables do wartości w tekście oraz spec.files do ścieżek plików. Każde zadanie wybiera swój wpis za pomocą environment_variables_key:

{
  "name": "serverless-environment-variables-example",
  "tasks": [
    {
      "task_key": "process_orders",
      "notebook_task": {
        "notebook_path": "/Workspace/Shared/process-orders"
      },
      "environment_key": "default",
      "environment_variables_key": "production"
    },
    {
      "task_key": "summarize",
      "spark_jar_task": {
        "main_class_name": "com.company.main"
      },
      "environment_key": "summary_env",
      "environment_variables_key": "summary_vars"
    }
  ],
  "environments": [
    {
      "environment_key": "default",
      "spec": {
        "environment_version": "5",
        "dependencies": []
      }
    },
    {
      "environment_key": "summary_env",
      "spec": {
        "environment_version": "5",
        "java_dependencies": ["/Volumes/company/default/prod/summarize.jar"]
      }
    }
  ],
  "environment_variables": [
    {
      "environment_variables_key": "production",
      "spec": {
        "variables": {
          "APP_ENV": "production",
          "REGION": "us-west-2",
          "SERVICE_TOKEN": "{{secrets/production/service-token}}"
        },
        "files": ["/Volumes/company/default/prod/execution.env", "/Volumes/company/default/prod/format.env"]
      }
    },
    {
      "environment_variables_key": "summary_vars",
      "spec": {
        "variables": {
          "APP_ENV": "production",
          "LOG_LEVEL": "INFO",
          "LOG_FILE": "service.log"
        },
        "files": ["/Volumes/company/default/prod/format.env"]
      }
    }
  ]
}

Możesz także skonfigurować wpisy dotyczące zmiennych środowiskowych za pomocą operacji Aktualizuj zadanie, Zastąp wszystkie ustawienia zadania oraz Prześlij jednorazowe uruchomienie.

Czytaj zmienne środowiskowe w kodzie aplikacji

Kod aplikacji odczytuje skonfigurowane zmienne ze środowiska procesowego.

Python

import os

app_environment = os.environ["APP_ENV"]
region = os.environ["REGION"]

Scala

val appEnvironment = sys.env("APP_ENV")
val region = sys.env("REGION")

Dodatkowe zasoby

• Uruchamiaj zadania Lakeflow z bezserwerową mocą obliczeniową w przepływach pracy
• Konfiguracja środowiska bezserwerowego
• Zarządzanie sekretami