Prise en main de Git privé Serverless d'Azure Databricks

Note

Azure Databricks Serverless Private Git est disponible en préversion publique. Il existe des frais pour les coûts de calcul et de mise en réseau encourus à partir de ressources de calcul serverless qui se connectent à des ressources externes. Pour plus d’informations sur la facturation, consultez Comprendre les coûts de mise en réseau sans serveur Databricks.

Qu’est-ce que Serverless Private Git ?

Azure Databricks Serverless Private Git vous permet de connecter un espace de travail Databricks à un serveur Git privé à l’aide du calcul serverless et d’Azure Private Link. Un serveur Git est privé s’il n’est pas accessible à partir d’Internet.

Le diagramme suivant illustre l’architecture système globale :

Pourquoi utiliser Git serverless privé ?

Par rapport au proxy Git, Git privé serverless offre les avantages suivants :

• Serverless Private Git n'acquiert le calcul serverless que lorsqu’il reçoit une requête Git et reste inactif lorsqu’il n'est pas utilisé. En revanche, le proxy Git nécessite que le cluster proxy soit actif lorsque l’utilisateur envoie une demande Git.

• Git privé sans serveur utilise Azure Private Link pour se connecter en toute sécurité à l’instance Git privée.

Spécifications

• Les espaces de travail doivent être activés pour Serverless.
• Le serveur Git privé doit se trouver dans le même réseau virtuel Azure que l’équilibreur de charge standard.
• Le serveur Git privé doit avoir un certificat signé/un nom de domaine complet HTTPS valide.
• Le réseau virtuel est configuré pour l’équilibreur de charge standard (SLB) utilisé pour le service Private Link.

Configurer Git privé sans serveur

1. Suivez les étapes pour configurer Private Link pour votre serveur Git privé. Cela vous permet de créer une connexion Azure Private Link de Serverless aux back-ends de votre réseau derrière un SLB.
2. Créez une configuration de connectivité réseau (NCC) pour configurer la sortie vers un équilibreur de charge standard. Considérations relatives à cette étape :
   • Une seule NCN peut être configurée pour un espace de travail pour Git privé. Si l’espace de travail doit se connecter à plusieurs serveurs Git privés, vérifiez qu’ils peuvent être connectés à l’aide de la même CCN.
   • Les limitations telles que le nombre de NCC prises en charge dans une région et le nombre d’espaces de travail pouvant être attachés à une NCNC sont documentées au niveau des exigences.

3. Obtenez un jeton d’API de compte à l’aide d’un principal de service avec un accès au niveau du compte.

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}

• Une autre méthode pour obtenir le jeton d'API de compte :

  • Jeton d’accès pour l’authentification : pour appeler l’API REST du compte Databricks, vous devez effectuer l’authentification et obtenir un jeton d’accès.
  • Utilisez un jeton d’accès Microsoft Entra ID.

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

4. Ajoutez une règle de point de terminaison privé pour définir une logique DNS via l’API.

Dans l’exemple, spécifiez les éléments suivants :

• ID de compte
• ID DE LA NCMC
• Jeton OAuth de compte
• ID de ressource du service Private Link
• Nom de domaine complet du serveur Git dans la liste de 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"
]
}
'

Réponse

{"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. Patientez quelques minutes après avoir configuré les règles de point de terminaison privé de la CCN. La règle de point de terminaison privé doit apparaître dans le NCC sans sous-ressource spécifiée, et le statut doit être en attente.
6. Le service Private Link configuré à l’étape 1 doit également disposer d’une connexion de point de terminaison privé en attente prête pour approbation. Approuvez cette connexion.

7. Revenez à la CCN à l’intérieur de la console de compte et vérifiez qu’elle a été établie.
8. Accédez à l’espace de travail et essayez une opération Git. Vous devez voir un élément d'interface utilisateur pour Git privé sans serveur. Cette page peut se charger pendant quelques secondes, le temps que l'environnement de calcul serverless pour le proxy Git soit en cours de démarrage.

Une fois que vous l’avez configuré, Serverless Git privé prend la priorité sur d’autres formes de connectivité Git privée que vous avez déjà configurées, telles que le proxy Git classique. Si vous disposez d’un cluster proxy Git classique en cours d’exécution, arrêtez-le après avoir configuré Serverless Private Git.

Configurations supplémentaires

Personnalisez vos opérations git à l’aide du fichier config.json.

1. Créez un fichier de configuration à l’emplacement /Workspace/.git_settings/config.jsonsuivant la spécification ci-dessous.
2. Accordez à tous les utilisateurs Git les autorisations d’affichage au fichier de configuration et à tous les fichiers de certificat d’autorité de certification référencés par celui-ci.
3. Interagissez avec Git pour valider la connectivité au serveur distant Git, par exemple le clonage d’un dossier Git pour un référentiel distant sur le serveur.
4. L’application des modifications apportées au fichier de configuration peut prendre jusqu’à 1 minute.

Structure de fichier de configuration Top-Level

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

Section 'default' (Facultatif)

Les valeurs par défaut globales sont appliquées à toutes les opérations Git, sauf si elles sont remplacées par une distance spécifique.

Terrain	Type	Obligatoire	Valeur par défaut	Descriptif
sslVerify	boolean	Non	true	Indique s’il faut vérifier les certificats SSL.
caCertPath	ficelle	Non	«  » (vide)	Chemin d'accès de l'espace de travail vers un certificat d'autorité de certification personnalisé.
httpProxy	ficelle	Non	«  » (vide)	Proxy HTTP pour acheminer le trafic Git via.
customHttpPort	entier	Non	Non spécifié	Port HTTP personnalisé du serveur Git.

Section « télécommandes » (facultatif)

Liste des objets définissant des paramètres pour des serveurs Git distants individuels. Ces paramètres remplacent le bloc « par défaut » pour chaque télécommande individuellement.

Terrain	Type	Obligatoire	Valeur par défaut	Descriptif
urlPrefix	ficelle	Oui	—	Préfixe pour faire correspondre les URL de télécommande Git.
sslVerify	boolean	Non	true	Indique s’il faut vérifier les certificats SSL.
caCertPath	ficelle	Non	«  » (vide)	Chemin d’accès de l’espace de travail à un chemin d’accès de certificat d’autorité de certification personnalisé pour cette connexion distante.
httpProxy	ficelle	Non	«  » (vide)	Proxy HTTP pour acheminer le trafic Git via.
customHttpPort	entier	Non	Non spécifié	Port HTTP personnalisé du serveur Git.

Exemple de configuration : sans configuration Remote-Specific

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

Exemple de configuration complète

{
"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
}
\]
}

Remarques

• La default section doit être présente, même si seulement partiellement.
• La remotes liste est facultative et peut être omise entièrement.
• Chaque entrée distante doit contenir au moins le urlPrefix.
• Si vous ne spécifiez pas de valeur pour un champ, elle utilise la valeur par défaut.
• Les champs inconnus sont ignorés.

Limites

• Le journal proxy serverless n’est actuellement pas disponible.
• Disponible uniquement sur les régions Serverless d’Azure.