Erste Schritte mit Azure Databricks Serverless Private Git

Hinweis

Azure Databricks Serverless Private Git befindet sich in der öffentlichen Vorschau. Es gibt eine Gebühr für Rechen- und Netzwerkkosten, die von serverlosen Computeressourcen entstehen, die eine Verbindung mit externen Ressourcen herstellen. Weitere Informationen zur Abrechnung finden Sie unter "Grundlegendes zu Serverlosen Netzwerkkosten für Databricks".

Was ist Serverless Private Git?

Mit Azure Databricks Serverless Private Git können Sie einen Databricks-Arbeitsbereich mit einem privaten Git-Server verbinden, indem Sie serverlose Compute- und Azure Private Link verwenden. Ein Git-Server ist privat, wenn er nicht über das Internet zugegriffen werden kann.

Das folgende Diagramm veranschaulicht die allgemeine Systemarchitektur:

Warum serverless Private Git verwenden?

Im Vergleich zum Git-Proxy bietet Serverless Private Git die folgenden Vorteile:

• Serverless Private Git erwirbt serverlose Berechnung nur, wenn sie eine Git-Anforderung empfängt, und sie kann inaktiv sein, wenn sie nicht verwendet wird. Im Gegensatz dazu erfordert der Git-Proxy, dass der Proxycluster aktiv ist, wenn der Benutzer eine Git-Anforderung sendet.

• Serverless Private Git verwendet Azure Private Link, um sicher eine Verbindung mit der privaten Git-Instanz herzustellen.

Anforderungen

• Arbeitsbereiche müssen für Serverless aktiviert sein.
• Der private Git-Server muss sich im gleichen Azure VNet wie der Standard-Lastenausgleich befinden.
• Privater Git Server muss über ein signiertes Zertifikat/einen gültigen HTTPS-FQDN verfügen.
• Das VNet ist für den Standard Load Balancer (SLB) konfiguriert, der für den Privaten Link-Dienst verwendet wird.

Einrichten von Serverless Private Git

1. Führen Sie die Schritte zum Einrichten des privaten Links für Ihren privaten Git-Server aus. Auf diese Weise können Sie eine Azure Private Link-Verbindung von Serverless zu Back-Ends in Ihrem Netzwerk hinter einer SLB erstellen.
2. Erstellen Sie eine Netzwerkkonnektivitätskonfiguration (Network Connectivity Configuration, NCC), um den Ausgang zu einem Standard-Load-Balancer zu konfigurieren. Überlegungen zu diesem Schritt:
   • Nur ein NCC kann für einen Arbeitsbereich für private Git konfiguriert werden. Wenn der Arbeitsbereich eine Verbindung mit mehreren privaten Git-Servern herstellen muss, stellen Sie sicher, dass sie mit demselben NCC verbunden werden können.
   • Einschränkungen wie die Anzahl der in einer Region unterstützten NCCs und die Anzahl der Arbeitsbereiche, die an eine NCC angefügt werden können, sind unter "Anforderungen" dokumentiert.

3. Rufen Sie ein Konto-API-Token mithilfe eines Dienstprinzipals mit kontobezogenem Zugriff ab.

curl
--location 'https://accounts.azuredatabricks.net/oidc/accounts/{accountid}/v1/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=SP_CLIENT_ID_HERE' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=2ff814a6-3304-4ab8-85cb-cd0e6f879c1d/.default' \
--data-urlencode 'client_secret=SP_CLIENT_SECRET_HERE'

Response

{"access_token":"...","scope":"all-apis","token_type":"Bearer","expires_in":3600}

• Alternative Methode zum Abrufen des Konto-API-Tokens:

  • Zugriffstoken für Authentifizierung: Um die REST-API des Databricks-Kontos aufzurufen, müssen Sie die Authentifizierung ausführen und ein Zugriffstoken abrufen.
  • Verwenden Sie ein Microsoft Entra ID-Zugriffstoken.

BEARER_TOKEN = `az account get-access-token --resource
2ff814a6-3304-4ab8-85cb-cd0e6f879c1d --query "accessToken" -o tsv

4. Fügen Sie eine private Endpunktregel hinzu, um DNS-Logik über die API zu definieren.

Geben Sie im Beispiel Folgendes an:

• Konto-ID
• NCC-ID
• OAuth-Kontotoken
• Private Link Service-Ressourcen-ID
• Git Servers FQDN in der Liste des domain_name

curl --location 'https://accounts.azuredatabricks.net/api/2.0/accounts/{accountid}/network-connectivity-configs/{nccid}/private-endpoint-rules' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer BEARER_TOKEN' \
--data '{
"resource_id": "/subscriptions/3f262328b/resourceGroups/rg/providers/Microsoft.Network/privateLinkServices/example",
"domain_names": [
"git-server.contoso.com"
]
}
'

Antwort

{"rule_id":"843ba2e5-bbbb-bbbb-bbbb-7f0d55555215","network_connectivity_config_id":"5a9bdc5f-c43d-41cd-9a6d-1b653e20c7d2","resource_id":"/subscriptions/3f262328b/resourceGroups/rg/providers/Microsoft.Network/privateLinkServices/example","endpoint_name":"databricks-5a9bdc5f-c43d-41cd-9a6d-1b653e20c7d2-pe-99cbbac3","connection_state":"PENDING","creation_time":1740000647980,"updated_time":1740000647949,"domain_names":["git-server.contoso.com"]}

5. Warten Sie einige Minuten, nachdem Sie die Regeln für private NCC-Endpunkte eingerichtet haben. Die private Endpunktregel sollte im NCC ohne angegebene Unterressource angezeigt werden, und der Status sollte auf "ausstehend" stehen.
6. Der in Schritt 1 konfigurierte Private Link-Dienst sollte auch über eine ausstehende private Endpunktverbindung zur Genehmigung verfügen. Diese Verbindung genehmigen.

7. Kehren Sie innerhalb der Kontokonsole zur NCC zurück, und überprüfen Sie, ob sie eingerichtet wurde.
8. Wechseln Sie zum Arbeitsbereich, und probieren Sie einen Git-Vorgang aus. Sie sollten einen UI-Indikator für Serverless Private Git sehen. Diese Seite kann einige Sekunden lang geladen werden, während die serverlose Rechenleistung für den Git-Proxy bereitgestellt wird.

Nachdem Sie es konfiguriert haben, hat Serverless Private Git Vorrang vor anderen Formen privater Git-Konnektivität, die Sie bereits bereitgestellt haben, z. B. klassischen Git-Proxy. Wenn ein klassischer Git-Proxy-Cluster ausgeführt wird, beenden Sie ihn nach dem Einrichten von Serverless Private Git.

Zusätzliche Konfigurationen

Passen Sie Ihre Git-Vorgänge mithilfe der config.json Datei an.

1. Erstellen Sie eine Konfigurationsdatei gemäß der folgenden Spezifikation bei /Workspace/.git_settings/config.json.
2. Erteilen Sie allen Git-Benutzern die Berechtigung "Ansicht" für die Konfigurationsdatei und alle Zertifizierungsstellendateien, auf die darauf verwiesen wird.
3. Interagieren Sie mit Git, um die Konnektivität mit der Git-Remote zu überprüfen, z. B. das Klonen eines Git-Ordners für ein Remote-Repository auf dem Server.
4. Änderungen an der Konfigurationsdatei können bis zu 1 Minute dauern, bis sie angewendet werden.

Top-Level Konfigurationsdateistruktur

{
"default": { ... }, // Optional global settings
"remotes": \[ ... \] // Optional list of per-remote settings
}

Abschnitt "default" (Optional)

Globale Standardwerte werden auf alle Git-Vorgänge angewendet, es sei denn, sie werden von einer bestimmten Remote außer Kraft gesetzt.

Feld	Typ	Erforderlich	Standardwert	Description
sslVerify	boolean	Nein	Wahr	Gibt an, ob SSL-Zertifikate überprüft werden sollen.
caCertPath	Schnur	Nein	"" (leer)	Pfad zum Speicherort eines benutzerdefinierten CA-Zertifikats.
httpProxy (Englisch)	Schnur	Nein	"" (leer)	HTTP-Proxy zum Weiterleiten des Git-Verkehrs.
customHttpPort	Integer	Nein	Nicht angegeben.	Benutzerdefinierter HTTP-Port des Git-Servers.

Abschnitt "remotes" (Optional)

Eine Liste der Objekte, die Einstellungen für einzelne Remote-Git-Server definieren. Diese Einstellungen überschreiben den "Standardblock" pro Remote.These settings override the 'default' block on a per remote.

Feld	Typ	Erforderlich	Standardwert	Description
urlPrefix	Schnur	Yes	—	Präfix, das mit Git-Remote-URLs übereinstimmt.
sslVerify	boolean	Nein	Wahr	Gibt an, ob SSL-Zertifikate überprüft werden sollen.
caCertPath	Schnur	Nein	"" (leer)	Arbeitsbereichspfad zu einem benutzerdefinierten Zertifizierungsstellenzertifikatpfad für diese Remoteverbindung.
httpProxy (Englisch)	Schnur	Nein	"" (leer)	HTTP-Proxy zum Weiterleiten des Git-Verkehrs.
customHttpPort	Integer	Nein	Nicht angegeben.	Benutzerdefinierter HTTP-Port des Git-Servers.

Beispielkonfiguration ohne fernbezogene Konfiguration

"default": {
"sslVerify": false
}
}

Vollständiges Konfigurationsbeispiel

{
"default": {
"sslVerify": true,
"caCertPath": "/Workspace/my_ca_cert.pem",
"httpProxy": "https://git-proxy-server.company.com",
"customHttpPort": "8080",
},
"remotes": \[
{
"urlPrefix": "https://my-private-git.company.com/",
"caCertPath": "/Workspace/my_ca_cert_2.pem"
},
{
"urlPrefix": "https://another-git-server.com/project.git",
"sslVerify": false
}
\]
}

Hinweise

• Der default Abschnitt muss vorhanden sein, auch wenn er nur teilweise vorhanden ist.
• Die remotes Liste ist optional und kann vollständig weggelassen werden.
• Jeder Eintrag für einen Fernzugriff muss mindestens den urlPrefix enthalten.
• Wenn Sie keinen Wert für ein Feld angeben, wird der Standardwert verwendet.
• Unbekannte Felder werden ignoriert.

Einschränkungen

• Das Serverless-Proxy-Log ist derzeit nicht verfügbar.
• Nur in Azure Serverless-Regionen verfügbar.