Configurez Databricks Serverless Private Git
Databricks Git privé serverless est en aperçu public. Les coûts de compute et de réseau s'appliquent lorsque des ressources de compute serverless se connectent à des ressources externes. Consultez Comprendre les coûts de mise en réseau de Databricks pour plus de détails sur la facturation.
Databricks Serverless Private Git vous permet de connecter un Workspace Databricks à un serveur Git privé à l'aide du compute serverless et de PrivateLink. Un serveur Git est privé si les utilisateurs d'Internet ne peuvent pas y accéder.
Le diagramme suivant illustre l'architecture globale du système :

Pourquoi utiliser le Git privé Serverless ?
Comparé au proxy de serveur Git, Git privé Serverless offre les avantages suivants :
- Serverless Private Git acquiert du compute serverless uniquement lorsqu'il reçoit une requête Git, et il peut être inactif lorsqu'il n'est pas utilisé. En revanche, le proxy Git exige que le cluster proxy soit actif lorsque l'utilisateur soumet une requête Git.
- Git privé Serverless utilise PrivateLink pour se connecter en toute sécurité à l'instance Git privée.
Configurer Serverless Git privé
- Suivez les étapes pour configurer un service de Endpoint Virtual Private Cloud (VPC) pour votre serveur Git privé. Cet Endpoint Virtual Private Cloud (VPC) vous permet de créer une connexion AWS PrivateLink de Serverless aux backends de votre réseau derrière un équilibreur de charge réseau (NLB).
- Un administrateur doit créer un Endpoint Virtual Private Cloud (VPC) d'interface AWS dans le NCC Databricks pour chaque serveur Git.
- Créez une configuration de la connectivité réseau (NCC) pour configurer l'accès sortant vers un équilibreur de charge réseau.
- Vous ne pouvez configurer qu'un seul NCC par workspace pour le Git privé. Si le Workspace se connecte à plusieurs serveurs Git privés, ils doivent tous utiliser le même NCC.
- Pour les limites de la NCC, telles que les limites régionales et les limites d'attachement de workspace, consultez Qu'est-ce qu'une configuration de connectivité réseau (NCC) ?.

- Ajouter une règle d'endpoint privé.

- Attendez au moins dix minutes après avoir configuré les règles d'Endpoint privé NCC, puis activez la préversion Git privé Serverless dans les paramètres de votre Workspace.
- Effectuer une opération Git dans le workspace. Un indicateur d'interface utilisateur confirme que Git Privé Serverless est actif. L'indicateur peut prendre quelques secondes à apparaître pendant que le compute serverless start.
Après l'avoir configuré, Serverless Private Git prévaut sur les autres formes de connectivité Git privée que vous avez déjà provisionnées, telles que le proxy Git classique et le Git privé d'entreprise. Si vous avez un cluster proxy Git en cours d'exécution, mettez-le en pause après avoir configuré Git privé Serverless.
Configurations supplémentaires
Personnalisez les opérations Git à l'aide d'un fichier de configuration.
- Créez un fichier de configuration à
/Workspace/.git_settings/config.jsonconformément à la spécification ci-dessous. - Accordez à tous les utilisateurs Git les autorisations de lecture pour le fichier de configuration et tous les fichiers de certificat CA auxquels il fait référence.
- Veuillez valider la connectivité au référentiel Git distant en effectuant une opération Git, telle que le clonage d'un dossier Git.
- Le système peut prendre jusqu'à une minute pour appliquer les modifications du fichier de configuration.
Structure du fichier de configuration de niveau supérieur
{
"default": { ... }, // Optional global settings
"remotes": [ ... ] // Optional list of per-remote settings
}
default section (facultatif)
Les paramètres par default globaux s'appliquent à toutes les Opérations Git à moins qu'un dépôt distant spécifique ne les remplace.
Champ | Type | Obligatoire | Valeur par défaut | Description |
|---|---|---|---|---|
| booléen | Non | vrai | Faut-il vérifier les certificats SSL ? |
| chaîne | Non | « » (vide) | Chemin Workspace vers un certificat CA personnalisé. |
| chaîne | Non | « » (vide) | Proxy HTTP pour acheminer le trafic Git. |
| entier | Non | Non spécifié | Port HTTP personnalisé du serveur Git. |
remotes section (facultatif)
Une liste d'objets définissant les paramètres pour des serveurs Git distants individuels. Ces paramètres remplacent le bloc default par télécommande.
Champ | Type | Obligatoire | Valeur par défaut | Description |
|---|---|---|---|---|
urlPrefix | chaîne | Oui | — | Préfixe pour les URL distantes Git. |
sslVerify | booléen | Non | vrai | Faut-il vérifier les certificats SSL ? |
caCertPath | chaîne | Non | « » (vide) | Chemin du Workspace vers un chemin de certificat CA personnalisé pour cette télécommande. |
httpProxy | chaîne | Non | « » (vide) | Proxy HTTP pour acheminer le trafic Git. |
customHttpPort | entier | Non | Non spécifié | Port HTTP personnalisé du serveur Git. |
Exemple de configuration sans configuration spécifique à distance
{
"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
}
]
}
Notes
- La section
defaultdoit être au moins partiellement présente. - La section
remotesest facultative. S'il est inclus, chaque entrée doit inclure un champurlPrefix. - Les champs non spécifiés utilisent leurs valeurs default.
- Les champs inconnus sont ignorés.
Autres recommandations de sécurité
Si le contrôle de sortie Serverless est activé, vérifiez que la politique réseau dans la console de compte appliquée au Workspace spécifique inclut le nom de domaine complet (FQDN) du serveur Git dans la destination internet autorisée.

Limitations
- Les logs de proxy Serverless ne sont pas disponibles.
- Serverless Private Git est disponible uniquement dans les régions serverless. Pour une liste des régions prises en charge, voir clouds et régions Databricks.
- Vous ne pouvez pas créer de service d'Endpoint VPC pour desservir des Workspace dans plusieurs régions. Actuellement, le NCC AWS est un objet régional et ne prend pas en charge les Endpoint VPC multirégionaux. Pour connecter un autre Workspace d'une autre région au serveur Git, configurez un autre équilibreur de charge réseau et un service de Virtual Private Cloud (VPC) Endpoint dans la nouvelle région.