Introduzione ad Azure Databricks Serverless Private Git

Annotazioni

Azure Databricks Serverless Private Git è disponibile in anteprima pubblica. I costi di calcolo e rete si applicano quando le risorse di calcolo serverless si connettono a risorse esterne. Per informazioni dettagliate sulla fatturazione, vedere Informazioni sui costi di rete serverless di Databricks .

Azure Databricks Serverless Private Git consente di connettere un'area di lavoro di Databricks a un server Git privato usando il calcolo serverless e il collegamento privato di Azure. Un server Git è privato se non è possibile accedervi da Internet.

Il diagramma seguente illustra l'architettura complessiva del sistema:

Perché usare Git privato serverless?

Rispetto al proxy Git, Git privato serverless offre i vantaggi seguenti:

• Git privato serverless acquisisce il calcolo serverless solo quando riceve una richiesta Git e può essere inattivo quando non è in uso. Al contrario, il proxy Git richiede che il cluster proxy sia attivo quando l'utente invia una richiesta Git.

• Serverless Git privato usa Azure Private Link per collegarsi in modo sicuro all'istanza Git privata.

Requisiti

• Le aree di lavoro devono essere abilitate per Serverless.
• Il server Git privato deve trovarsi nella stessa rete virtuale di Azure di Load Balancer Standard.
• Il server Git privato deve avere un certificato o un nome di dominio completo HTTPS valido.
• La rete virtuale è configurata per il Load Balancer Standard (SLB) usato per il servizio Private Link.

Configurare Serverless Private Git

1. Seguire la procedura per configurare il collegamento privato per il server Git privato. In questo modo, è possibile creare una connessione Azure Private Link da "Serverless" ai backend nella rete dietro un bilanciatore del carico software.
2. Creare una configurazione di connettività di rete (NCC) per configurare l'uscita in un servizio di bilanciamento del carico standard. Considerazioni per questo passaggio:
   • È possibile configurare un solo NCC per un'area di lavoro per Git privato. Se l'area di lavoro deve connettersi a più server Git privati, verificare che sia possibile connettersi usando lo stesso NCC.
   • Le limitazioni, ad esempio il numero di controller di rete supportate in un'area e il numero di aree di lavoro che possono essere collegate a un NCC, sono documentate in Requisiti.

3. Ottenere un token API dell'account utilizzando un servizio principale con accesso a livello di account.

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}

• Modo alternativo per ottenere il token API dell'account:

  • Token di accesso per l'autenticazione: per chiamare l'API REST dell'account Databricks, è necessario eseguire l'autenticazione e ottenere un token di accesso.
  • Usare un token di accesso microsoft Entra ID.

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

4. Aggiungere una regola per l'endpoint privato per definire la logica relativa al DNS tramite l'API.

Nell'esempio specificare quanto segue:

• ID dell'account
• NCC ID
• Token OAuth dell'account
• ID della risorsa del servizio di collegamento privato
• FQDN di Git Server nell'elenco di 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"
]
}
'

Risposta

{"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. Attendere alcuni minuti dopo aver configurato le regole dell'endpoint privato NCC. La regola dell'endpoint privato appare nel NCC senza una sottorisorsa specificata e ha uno stato di attesa.
6. Il servizio Private Link configurato nel passaggio 1 include anche una connessione endpoint privata in sospeso pronta per l'approvazione. Approvare questa connessione.

7. Tornare al NCC all'interno della console dell'account e verificare che sia stato configurato.
8. Passare all'area di lavoro e provare un'operazione Git. Dovrebbe essere visualizzato un indicatore UI per il Git privato serverless. Questa pagina può impiegare alcuni secondi per caricarsi mentre il calcolo serverless per il proxy Git si sta avviando.

Dopo averlo configurato, Serverless Private Git ha la precedenza su altre forme di connettività Git privata già fornite, come il proxy Git classico. Se hai in esecuzione un cluster proxy Git classico, spegnilo dopo aver configurato il Git serverless privato.

Configurazioni aggiuntive

Personalizzare le operazioni Git usando il file config.json.

1. Creare un file di configurazione in /Workspace/.git_settings/config.json, seguendo la specifica seguente.
2. Concedere a tutti gli utenti Git le autorizzazioni Di visualizzazione al file di configurazione e a tutti i file di certificato CA a cui fa riferimento.
3. Interagire con Git per convalidare la connettività al repository git remoto, ad esempio clonando una cartella Git per un repository remoto nel server.
4. L'applicazione delle modifiche apportate al file di configurazione può richiedere fino a 1 minuto.

Struttura di file di configurazione di primo livello

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

default sezione (facoltativo)

Le impostazioni predefinite globali vengono applicate a tutte le operazioni Git, a meno che non siano sostituite da un remoto specifico.

Campo	TIPO	Obbligatorio	Valore predefinito	Description
sslVerify	boolean	NO	true	Indica se verificare i certificati SSL.
caCertPath	corda	NO	"" (vuoto)	Percorso nel workspace per un certificato CA personalizzato.
httpProxy	corda	NO	"" (vuoto)	Proxy HTTP da utilizzare per instradare il traffico Git.
customHttpPort (porta HTTP personalizzata)	numero intero	NO	Non specificato	Porta HTTP personalizzata del server Git.

remotes sezione (facoltativo)

Elenco di oggetti che definiscono le impostazioni per singoli server Git remoti. Queste impostazioni sostituiscono il default blocco su base remota.

Campo	TIPO	Obbligatorio	Valore predefinito	Description
urlPrefix	corda	Yes	—	Prefisso per corrispondere agli URL remoti Git.
sslVerify	boolean	NO	true	Indica se verificare i certificati SSL.
caCertPath	corda	NO	"" (vuoto)	Percorso dell'area di lavoro per il percorso di un certificato CA personalizzato per questo ambiente remoto.
httpProxy	corda	NO	"" (vuoto)	Proxy HTTP da utilizzare per instradare il traffico Git.
customHttpPort (porta HTTP personalizzata)	numero intero	NO	Non specificato	Porta HTTP personalizzata del server Git.

Configurazione di esempio senza configurazione specifica remota

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

Esempio di configurazione completa

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

Note

• La default sezione deve essere presente, anche se solo parzialmente.
• L'elenco remotes è facoltativo e può essere omesso interamente.
• Ogni voce remota deve contenere almeno il urlPrefix.
• Se non si specifica un valore per un campo, viene usato il valore predefinito.
• I campi sconosciuti vengono ignorati.

Limitazioni

• Il log del proxy serverless non è disponibile attualmente.
• Disponibile solo nelle aree serverless di Azure.