Aller au contenu principal

Configurez Databricks Serverless Private Git

remarque

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 :

Architecture Git privée Serverless Databricks

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é

  1. 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).
  2. Un administrateur doit créer un Endpoint Virtual Private Cloud (VPC) d'interface AWS dans le NCC Databricks pour chaque serveur Git.
  3. 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) ?.

Créer une configuration de la connectivité réseau

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

Ajouter une règle d'endpoint privé

  1. 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.
  2. 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.

  1. Créez un fichier de configuration à /Workspace/.git_settings/config.json conformément à la spécification ci-dessous.
  2. 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.
  3. Veuillez valider la connectivité au référentiel Git distant en effectuant une opération Git, telle que le clonage d'un dossier Git.
  4. 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

JSON
{
"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

sslVerify

booléen

Non

vrai

Faut-il vérifier les certificats SSL ?

caCertPath

chaîne

Non

« » (vide)

Chemin Workspace vers un certificat CA personnalisé.

httpProxy

chaîne

Non

« » (vide)

Proxy HTTP pour acheminer le trafic Git.

customHttpPort

entier

Non

Non spécifié

Port HTTP personnalisé du serveur Git.

Champ

Type

Obligatoire

Valeur par défaut

Description

sslVerify

booléen

Non

vrai

Faut-il vérifier les certificats SSL ?

caCertPath

chaîne

Non

« » (vide)

Chemin Workspace vers un certificat CA personnalisé.

httpProxy

chaîne

Non

« » (vide)

Proxy HTTP pour acheminer le trafic Git.

customHttpPort

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.

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

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

Exemple de configuration complète

JSON
{
"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 default doit être au moins partiellement présente.
  • La section remotes est facultative. S'il est inclus, chaque entrée doit inclure un champ urlPrefix.
  • 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.

Vérifiez que le workspace inclut le 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.