Configurer la connectivité Git privée pour les dossiers Git Databricks
Si vous hébergez un serveur Git privé (tel que GitHub Enterprise Server, Bitbucket Server ou GitLab autogéré) ou si votre serveur Git est derrière un pare-feu, vous pouvez utiliser le proxy de serveur Git pour connecter les dossiers Git Databricks à vos référentiels privés. Le proxy achemine les commandes Git de votre Databricks Workspace via une ressource de compute vers votre serveur Git privé.
Une version Serverless du proxy Git est disponible en aperçu public. Consultez Configurer Databricks Serverless Private Git.
À propos du proxy de serveur Git
Le proxy de serveur Git Databricks pour les dossiers Git vous permet de proxifier les commandes Git depuis votre workspace Databricks vers un serveur Git privé qui n'est pas accessible sur internet.
Les dossiers Git de Databricks représentent vos référentiels Git connectés sous forme de dossiers. Le contenu de ces dossiers est versionné par synchronisation avec le repository Git connecté. Par défaut, les dossiers Git peuvent uniquement se synchroniser avec des repository accessibles sur internet. Si vous hébergez un serveur Git privé ou si votre serveur Git est derrière un pare-feu, vous devez utiliser le proxy de serveur Git avec les dossiers Git. Votre serveur Git doit être accessible depuis votre plan de compute Databricks.
Quand utiliser le proxy de serveur Git
Utilisez les conseils suivants pour déterminer si vous devez configurer un proxy de serveur Git :
- Vous avez besoin d'un proxy de serveur Git si votre serveur Git est privé, on-premise ou derrière un pare-feu, comme GitHub Enterprise Server, Bitbucket Server, GitLab auto-géré ou Azure DevOps Server.
- Vous n'avez pas besoin de proxy de serveur Git si votre repository se trouve sur des services hébergés dans le cloud accessibles depuis l'internet public, tels que GitHub.com, GitLab.com, Bitbucket Cloud ou Azure DevOps Services.
Une fois activé, tout le trafic des dossiers Git de votre Workspace passe par le cluster proxy, y compris les repository publics.
Comment le proxy de serveur Git fonctionne
Proxy de serveur Git pour les dossiers Git Databricks, qui transfère les commandes Git du plan de contrôle Databricks vers un cluster proxy exécuté dans le plan de calcul de votre Workspace. Le cluster proxy est configuré pour exécuter un service proxy qui reçoit les commandes Git du plan de contrôle Databricks et les transmet à votre serveur Git. Le proxy n'affecte pas l'architecture de sécurité de votre plan de contrôle Databricks.
Ce qui suit illustre l'architecture globale du système :
Databricks fournit un notebook d’activation pour configurer votre instance de serveur Git afin de proxifier les commandes pour les dossiers Git Databricks. Obtenez le notebook d’activation sur GitHub. Le proxy de serveur Git Databricks est conçu pour fonctionner avec la version de Databricks Runtime incluse dans le notebook de configuration. Ne mettez pas à jour la version de Databricks Runtime du cluster proxy.
Configurer le proxy de serveur Git
Pour activer la connectivité Git privée pour les dossiers Git Databricks, préparez votre instance de serveur Git, exécutez le Notebook d'activation pour créer le proxy et validez votre configuration.
Pour configurer le proxy de serveur Git :
- Préparez votre instance de serveur Git avec des adresses IP statiques et le transport HTTPS.
- Exécutez le notebook d'activation pour créer le cluster proxy.
- Validez votre configuration en clonant un repository.
- Configurez les identifiants Git pour les utilisateurs.
Prérequis
Avant d'activer le proxy, vérifiez les points suivants :
-
Votre Workspace dispose de la fonctionnalité de dossiers Git Databricks activée. Consultez Activer ou désactiver les dossiers Git Databricks.
-
Votre instance de serveur Git est accessible depuis le plan de calcul de votre Workspace Databricks Virtual Private Cloud (VPC), et dispose à la fois de HTTPS et de jetons d'accès personnels (PAT) activés.
Le proxy de serveur Git pour Databricks fonctionne dans toutes les régions prises en charge par votre Virtual Private Cloud (VPC).
Étape 1 : Préparez votre instance de serveur Git
Pour créer une ressource compute et effectuer cette tâche, vous devez être un administrateur Workspace avec des droits d'accès.
Configurez votre serveur Git pour accepter les connexions du cluster proxy et activer le transport HTTPS.
Votre serveur Git d’entreprise dispose généralement d’une liste d’autorisation d’adresses IP à partir desquelles l’accès est autorisé. Pour permettre au nœud driver du cluster proxy d’accéder à votre serveur Git, associez une adresse IP sortante statique pour le trafic provenant de votre cluster proxy et ajoutez-la à la liste d’autorisation de votre serveur Git.
- Associez une adresse IP sortante statique pour le trafic provenant de votre cluster proxy en acheminant le trafic via une passerelle NAT.
- Ajoutez l'adresse IP de l'étape précédente à la liste d'autorisation de votre serveur Git.
Ensuite, configurez votre instance de serveur Git pour autoriser le transport HTTPS :
- GitHub Enterprise : consultez Quelle URL distante dois-je utiliser dans l’aide de GitHub Enterprise.
- Bitbucket Server : sur la page d'administration du serveur Bitbucket, cliquez sur Paramètres du serveur et sélectionnez HTTP(S) activé .
Étape 2 : Exécutez le notebook d'activation
Pour activer le proxy :
-
Connectez-vous à votre Workspace Databricks en tant qu'administrateur de Workspace avec les droits d'accès pour créer un cluster.
-
Importez ce Notebook qui choisit le plus petit type d'instance disponible auprès de votre fournisseur de cloud pour exécuter le proxy Git :
-
Cliquez sur Tout exécuter pour exécuter le Notebook, qui effectue les tâches suivantes :
- Crée une ressource de compute à nœud unique nommée « Proxy Git Databricks » qui ne se termine pas automatiquement. Ce service de proxy traite et transmet les commandes Git de votre workspace Databricks à votre serveur Git privé.
- Active un indicateur de fonctionnalité qui contrôle si les requêtes Git dans les dossiers Git de Databricks sont transmises par proxy via l'instance de compute.
Par bonne pratique, créez un Job pour exécuter la ressource de compute proxy Git à échéance régulière. Cela permet de maintenir le service de proxy Git disponible pour vos utilisateurs.
L'exécution d'une ressource de compute supplémentaire de longue durée entraîne des Databricks Units (DBU) supplémentaires. Afin de minimiser les coûts, le notebook configure le proxy pour utiliser une ressource de compute à nœud unique avec un type de nœud économique. Modifiez les options de compute en fonction de vos besoins. Pour des informations sur les tarifs, consultez le calculateur de tarifs Databricks.
Étape 3 : valider la configuration de votre serveur Git
Pour valider la configuration de votre serveur Git, clonez un repository hébergé sur votre serveur Git privé via le cluster proxy. Un clonage réussi confirme que le proxy de serveur Git fonctionne pour votre Workspace.
Étape 4 : Créer des Git repository compatibles avec un proxy
Une fois que les utilisateurs ont configuré leurs identifiants Git, aucune autre étape n'est requise pour créer ou synchroniser des repository. Pour configurer les identifiants et accéder aux repositories par programmation, consultez Connecter votre fournisseur Git à Databricks.
Supprimer les autorisations globales CAN ATTACH TO
Le proxy de serveur Git ne requiert aucune autorisation CAN ATTACH TO pour aucun utilisateur. Pour empêcher les utilisateurs d'exécuter des charges de travail arbitraires sur le cluster proxy, restreignez les autorisations de liste de contrôle d'accès (ACL) du cluster sur le serveur proxy :
-
Cliquez sur Compute dans la barre latérale, puis choisissez l'entrée compute pour le proxy de serveur Git que vous exécutez.
-
Cliquer sur le menu kebab
et cliquer sur Autorisations . -
Dans la boîte de dialogue, supprimez l'entrée Peut se lier à pour Tous les utilisateurs de Workspace .
Dépannage
Cette section couvre les problèmes courants et la façon de les diagnostiquer.
Liste de contrôle pour les problèmes courants
Avant de start à diagnostiquer une erreur, confirmez les éléments suivants :
- Votre cluster proxy s'exécute avec ce notebook de débogage du serveur proxy Git.
- Vous êtes un administrateur du Workspace.
Exécutez le reste du notebook de débogage et capturez les résultats. Si vous ne pouvez pas résoudre le problème ou ne voyez aucun échec signalé, l'assistance Databricks peut examiner les résultats. Exportez et envoyez le notebook de débogage sous forme d'archive DBC si cela est demandé.
Modifiez votre configuration de proxy Git.
Si votre service proxy Git ne fonctionne pas avec la configuration par default, définissez des variables d'environnement pour prendre en charge votre infrastructure réseau.
Utilisez les variables d'environnement suivantes pour mettre à jour la configuration de votre service proxy Git :
Variable d'environnement | Format | Description |
|---|---|---|
|
| Définissez cette valeur sur |
| Chemin d'accès au fichier (string) | Définissez ceci sur le chemin d’accès à un fichier de certificat CA utilisé pour la vérification SSL. Exemple : |
|
| Définissez cette valeur sur l'URL HTTPS de votre proxy de pare-feu réseau pour le trafic HTTP. |
| Numéro de port (entier) | Définissez ce paramètre sur le numéro de port attribué au port HTTP de votre serveur Git. |
Pour définir ces variables d’environnement :
- Accédez à l'onglet Compute dans votre workspace Databricks.
- Sélectionnez la configuration compute de votre service proxy Git.
- En bas du volet **Configuration**, développez **Avancé** et sélectionnez l'onglet **Spark**.
- Ajoutez des variables d'environnement au champ Variables d'environnement .
Inspecter les logs sur le cluster proxy
Le fichier à l'emplacement /databricks/git-proxy/git-proxy.log sur le cluster proxy contient des Logs qui sont utiles à des fins de debugging.
Le fichier Logs doit start par Data-plane proxy server binding to ('', 8000)…. Dans le cas contraire, le serveur proxy n’a pas start correctement. Redémarrez le cluster, ou supprimez-le et exécutez à nouveau le Notebook d’activation.
Si le fichier de log commence par cette ligne, examinez les instructions de log qui suivent pour chaque requête Git initiée par des opérations Git dans les dossiers Git Databricks.
Par exemple :
do_GET: https://server-address/path/to/repo/info/refs?service=git-upload-pack 10.139.0.25 - - [09/Jun/2021 06:53:02] /
"GET /server-address/path/to/repo/info/refs?service=git-upload-pack HTTP/1.1" 200`
Les logs d’erreur écrits dans ce fichier peuvent vous être utiles, ainsi qu’au support Databricks, pour déboguer les problèmes.
Erreurs de certificat SSL
Vous pourriez voir l'erreur suivante :
https://git.consult-prodigy.com/Prodigy/databricks_test: Secure connection to https://git.consult-prodigy.com/Prodigy/databricks_test could not be established because of SSL problems
Cela signifie souvent que vous utilisez un repository qui nécessite des certificats SSL spéciaux. Vérifiez le fichier /databricks/git-proxy/git-proxy.log sur le cluster proxy. Si la validation du certificat a échoué, ajoutez l'autorité de certification à la chaîne de certificats système :
- Extrayez le certificat racine à l’aide de votre navigateur ou d’une autre méthode, et upload-le sur Databricks File System.
- Modifiez le cluster Git folders Git Proxy pour définir la variable d'environnement
GIT_PROXY_CA_CERT_PATHafin qu'elle pointe vers le fichier de certificat racine. Voir Variables d'environnement.
Une fois ces étapes terminées, redémarrez le cluster.
Questions fréquemment posées
Vous trouverez ci-dessous les questions fréquentes concernant la configuration et l'utilisation du proxy de serveur Git.
Comment vérifier si le proxy Git est en cours d'exécution ?
Importez et exécutez le Notebook de débogage du proxy Git. Les résultats indiquent s'il y a des problèmes avec le service proxy Git.
Les Workspace peuvent-ils partager des clusters proxy ?
Chaque Databricks Workspace nécessite son propre cluster proxy. Vous ne pouvez pas partager un cluster proxy entre plusieurs Workspace, et chaque Workspace ne peut avoir qu'un seul cluster de serveur proxy Git.
Puis-je router seulement une partie du trafic Git via le proxy ?
Tout le trafic lié aux dossiers Databricks Git passe par le cluster proxy, même pour les repositories Git publics. Votre Workspace Databricks ne fait pas la distinction entre les repository proxys et non proxys.
Quels fournisseurs Git sont pris en charge ?
Les dossiers Git Databricks prennent en charge GitHub Enterprise, Bitbucket Server, Azure DevOps Server et GitLab auto-géré. D'autres fournisseurs de serveurs Git d'entreprise devraient également fonctionner s'ils sont conformes aux spécifications Git courantes.
La signature de commit GNU Privacy Guard (GPG) est-elle prise en charge ?
Non.
Le transport SSH est-il pris en charge ?
N°. Seul HTTPS est pris en charge.
Puis-je utiliser un port HTTPS non-default ?
Le Notebook d'activation suppose que votre serveur Git utilise le port HTTPS par default 443. Définissez la variable d’environnement GIT_PROXY_CUSTOM_HTTP_PORT pour utiliser un port différent.
Les utilisateurs doivent-ils modifier les URL Git pour le proxy ?
Non. Les utilisateurs saisissent l’URL de repository Git normale, telle que https://git.company.com/org/repo-name.git. Tout le trafic Git pour les dossiers Git Databricks est acheminé de manière transparente via le proxy.
Comment l'authentification fonctionne-t-elle avec le proxy ?
Le proxy utilise l’identifiant Git de l’utilisateur pour s’authentifier auprès du serveur Git. L’accès est restreint par les permissions spécifiées dans cet identifiant.