Comece com o Azure Databricks Serverless Private Git

O Azure Databricks Serverless Private Git permite conectar um espaço de trabalho Databricks a um servidor Git privado usando computação sem servidor e o Azure Private Link. Um servidor Git é privado se não puder ser acedido a partir da internet.

O diagrama a seguir ilustra a arquitetura geral do sistema:

Por que usar o Serverless Private Git?

Em comparação com o proxy Git, o Serverless Private Git oferece as seguintes vantagens:

• O Git privado sem servidor adquire computação sem servidor somente quando recebe uma solicitação Git e pode ficar inativo quando não está em uso. Por outro lado, o proxy Git requer que o cluster de proxy esteja ativo quando o usuário envia uma solicitação Git.

• O Git Privado sem Servidor usa o Azure Private Link para se conectar com segurança à instância privada do Git.

Requerimentos

• Os espaços de trabalho devem estar habilitados para Serverless.
• O Servidor Git Privado deve estar na mesma VNet do Azure que o Balanceador de Carga Padrão.
• O Servidor Git Privado deve ter um certificado assinado/FQDN HTTPS válido.
• A rede virtual é configurada para o SLB (Standard Load Balancer) usado para o serviço Private Link.

Configurar o Git privado sem servidor

1. Siga as etapas para configurar o Private Link para seu servidor Git privado. Isso permite que crie uma ligação Azure Private Link de um ambiente Serverless para backends na sua rede, atrás de um SLB.
2. Crie uma configuração de conectividade de rede (NCC) para configurar a saída para um balanceador de carga padrão. Considerações para esta etapa:
   • Apenas um NCC pode ser configurado para um espaço de trabalho para Git privado. Se o espaço de trabalho precisar se conectar a vários servidores Git privados, verifique se eles podem ser conectados usando o mesmo NCC.
   • Limitações como o número de NCCs suportados em uma região e o número de espaços de trabalho que podem ser anexados a um NCC estão documentadas em Requisitos.

3. Obtenha um token de conta da API usando um principal de serviço com acesso ao nível de conta.

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 obter o token API da conta:

  • Token de acesso para autenticação: Para chamar a API REST da conta Databricks, deve realizar a autenticação e obter um token de acesso.
  • Use um token de acesso do Microsoft Entra ID.

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

4. Adicione uma regra de endpoint privado para definir a lógica DNS usando a API.

No exemplo, especifique o seguinte:

• ID da conta
• NCC ID
• Conta OAuth Token
• ID do recurso do serviço de ligação privada
• FQDN do Git Server na lista do 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"
]
}
'

Resposta

{"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. Aguarde alguns minutos depois de configurar as regras do endpoint privado do NCC. A regra do ponto final privado aparece no NCC sem um subrecurso especificado com o estado de pendente.
6. O serviço Private Link configurado no Step 1 também tem uma ligação pendente ao endpoint privado pronta para aprovação. Aprove esta ligação.

7. Certifique-se de revisitar o NCC através do console da conta e verificar se ele foi configurado corretamente.
8. Vá para o espaço de trabalho e tente uma operação Git. Você deve ver um indicador de interface para o Git Privado Sem Servidor. Esta página pode demorar alguns segundos a carregar enquanto a computação serverless para o proxy Git está a iniciar-se.

Depois de configurá-lo, o Git privado sem servidor tem precedência sobre outras formas de conectividade Git privada que você já provisionou, como o proxy Git clássico. Se você tiver um cluster de proxy Git clássico em execução, encerre-o depois de configurar o Git Privado sem Servidor.

Configurações adicionais

Personalize suas operações git usando o arquivo config.json.

1. Crie um arquivo de configuração em /Workspace/.git_settings/config.json, seguindo a especificação abaixo.
2. Conceda a todos os utilizadores do Git permissões de visualização para o arquivo de configuração e quaisquer arquivos de certificado CA referenciados por eles.
3. Interaja com o Git para validar a conectividade com o controle remoto do Git, como clonar uma pasta Git para um repositório remoto no servidor.
4. As alterações no arquivo de configuração podem levar até 1 minuto para serem aplicadas.

Estrutura de ficheiro de configuração de nível superior

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

default Secção (opcional)

Os padrões globais são aplicados a todas as operações do Git, a menos que sejam substituídos por um controle remoto específico.

remotes Secção (opcional)

Uma lista de objetos que definem configurações para servidores Git remotos individuais. Estas definições sobrepõem-se ao default bloco numa base remota.

Exemplo de configuração sem configuração específica para dispositivos remotos

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

Exemplo completo de configuração

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

Observações

• A default secção deve estar presente, mesmo que parcialmente.
• A remotes lista é opcional e pode ser totalmente omitida.
• Cada entrada remota deve conter pelo menos o urlPrefix.
• Se você não especificar um valor para um campo, ele usará o valor padrão.
• Os campos desconhecidos são ignorados.

Limitações

• O log de proxy sem servidor está atualmente indisponível.
• Disponível apenas em regiões sem servidor do Azure.