Introducción a Git privado sin servidor de Azure Databricks

Nota:

Git privado sin servidor de Azure Databricks está en versión preliminar pública. Hay un cargo por los costos de computación y red incurridos por recursos de computación sin servidor que se conectan a recursos externos. Para más información sobre la facturación, consulte Descripción de los costos de red sin servidor de Databricks.

¿Qué es Git privado sin servidor?

Git privado de Azure Databricks sin servidor le permite conectar un área de trabajo de Databricks a un servidor Git privado mediante computación sin servidor y Azure Private Link. Un servidor Git es privado si no se puede acceder desde Internet.

En el diagrama siguiente se muestra la arquitectura general del sistema:

¿Por qué usar Git privado sin servidor?

En comparación con el proxy de Git, Git privado sin servidor ofrece las siguientes ventajas:

• Git privado sin servidor adquiere capacidad de cómputo sin servidor solo cuando recibe una solicitud de Git y puede estar inactivo cuando no se utiliza. Por el contrario, el proxy de Git requiere que el clúster de proxy esté activo cuando el usuario envía una solicitud de Git.

• Git privado sin servidor usa Azure Private Link para conectarse de forma segura a la instancia privada de Git.

Requisitos

• Las áreas de trabajo deben estar habilitadas para Serverless.
• El servidor Git privado debe estar en la misma red virtual de Azure que standard Load Balancer.
• El servidor Git privado debe tener un certificado firmado o un FQDN HTTPS válido.
• La red virtual está configurada para el Standard Load Balancer (SLB) utilizado para el servicio "Private Link".

Configuración de Git privado sin servidor

1. Siga los pasos para configurar Private Link para el servidor git privado. Esto le permite crear una conexión de Azure Private Link desde sin servidor a los backends en su red, detrás de un SLB.
2. Cree una configuración de conectividad de red (NCC) para configurar la salida a un equilibrador de carga estándar. Consideraciones para este paso:
   • Solo se puede configurar un NCC para un área de trabajo para Git privado. Si el área de trabajo necesita conectarse a varios servidores Git privados, compruebe que se pueden conectar con el mismo NCC.
   • Las limitaciones como el número de NCC admitidos en una región y el número de áreas de trabajo que se pueden adjuntar a un NCC se documentan en Requisitos.

3. Obtenga un token de API de cuenta mediante un principal de servicio con acceso a nivel de cuenta.

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}

• Forma alternativa de obtener el token de API de cuenta:

  • Token de acceso para la autenticación: para llamar a la API REST de la cuenta de Databricks, debe realizar la autenticación y obtener un token de acceso.
  • Use un token de acceso de Microsoft Entra ID.

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

4. Agregue una regla de punto de conexión privado para definir la lógica DNS a través de la API.

En el ejemplo, especifique lo siguiente:

• Id. de cuenta
• ID de NCC
• Token de cuenta OAuth
• Identificador de recurso del servicio Private Link
• FQDN de Git Server en la lista 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"
]
}
'

Respuesta

{"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. Espere unos minutos después de configurar las reglas de punto de conexión privado de NCC. La regla de punto de conexión privado debe aparecer en el NCC sin un subrecurso especificado y el estado debe estar pendiente.
6. El servicio Private Link configurado en el paso 1 también debe tener una conexión de punto de conexión privado pendiente lista para su aprobación. Apruebe esta conexión.

7. Regresa al NCC dentro de la consola de la cuenta y verifica que se haya establecido.
8. Vaya al área de trabajo y pruebe una operación de Git. Debería ver un indicador de interfaz de usuario para Git privado sin servidor. Esta página puede cargar durante unos segundos mientras se inicia la computación sin servidor para el proxy de Git.

Después de configurarlo, Serverless Private Git tiene prioridad sobre otras formas de conectividad privada de Git que ya haya implementado, como el proxy clásico de Git. Finalice el clúster de proxy de Git clásico que esté en ejecución después de configurar Git Privado Sin Servidor.

Configuraciones adicionales

Personalice las operaciones de Git mediante el archivo config.json.

1. Cree un archivo de configuración en /Workspace/.git_settings/config.json, siguiendo la especificación siguiente.
2. Conceda a todos los usuarios de Git permisos de visualización al archivo de configuración y a todos los archivos de certificados de entidad de certificación a los que hace referencia.
3. Interactúe con Git para validar la conectividad con el remoto de Git, como clonar una carpeta git para un repositorio remoto en el servidor.
4. Los cambios en el archivo de configuración pueden tardar hasta 1 minuto en aplicarse.

Estructura de archivos de configuración de Top-Level

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

Sección 'default' (opcional)

Los valores predeterminados globales se aplican a todas las operaciones de Git, a menos que sean anulados por un remoto específico.

Campo	Tipo	Obligatorio	Valor predeterminado	Description
sslVerify	boolean	No	true	Indica si se deben comprobar los certificados SSL.
caCertPath	cuerda / cadena	No	"" (vacío)	Ruta de acceso en el área de trabajo a un certificado de autoridad certificadora personalizado.
httpProxy (en inglés)	cuerda / cadena	No	"" (vacío)	Proxy HTTP para enrutar el tráfico de Git.
customHttpPort	entero	No	Sin especificar	Puerto HTTP personalizado del servidor Git.

Sección "remotes" (opcional)

Lista de objetos que definen la configuración de servidores Git remotos individuales. Esta configuración sustituye al bloque "predeterminado" para cada conexión remota.

Campo	Tipo	Obligatorio	Valor predeterminado	Description
urlPrefix	cuerda / cadena	Sí	—	Prefijo para que coincida con las direcciones URL remotas de Git.
sslVerify	boolean	No	true	Indica si se deben comprobar los certificados SSL.
caCertPath	cuerda / cadena	No	"" (vacío)	Ruta de acceso a un certificado de entidad de certificación personalizada para este remoto.
httpProxy (en inglés)	cuerda / cadena	No	"" (vacío)	Proxy HTTP para enrutar el tráfico de Git.
customHttpPort	entero	No	Sin especificar	Puerto HTTP personalizado del servidor Git.

Configuración de ejemplo sin configuración específica remota

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

Ejemplo de configuración 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
}
\]
}

Notas

• La default sección debe estar presente, aunque solo sea parcialmente.
• La remotes lista es opcional y se puede omitir por completo.
• Cada entrada remota debe contener al menos el urlPrefix.
• Si no especifica un valor para un campo, usa el valor predeterminado.
• Se omiten los campos desconocidos.

Limitaciones

• El registro de proxy sin servidor no está disponible actualmente.
• Disponible solo en regiones sin servidor de Azure.