Pular para o conteúdo principal

Começando com Databricks serverless Private Git

nota

Databricks serverless Private Git está em pré-visualização pública. Há uma cobrança para compute e custos de rede incorridos com serverless compute recurso conectado a um recurso externo. Para obter mais informações sobre faturamento, consulte Entenda Databricks serverless custos de rede.

O que é o Serverless Private Git?

Databricks O serverless Private Git permite que o senhor conecte um Databricks workspace a um servidor privado Git usando serverless compute e AWS PrivateLink. Um servidor Git é privado se não puder ser acessado pela Internet.

O diagrama a seguir ilustra a arquitetura geral do sistema:

Databricks serverless arquitetura de repositórios privados

Por que usar o Git privado sem servidor?

Em comparação com o proxyGit, o Private Git sem servidor oferece as seguintes vantagens:

  • O serverless Private Git adquire o serverless compute somente quando recebe uma solicitação Git e pode ficar inativo quando não estiver em uso. Por outro lado, o proxy Git exige que o clustering do proxy esteja ativo quando o usuário envia uma solicitação Git.

  • O Git privado sem servidor usa o PrivateLink para se conectar com segurança à instância privada do git.

Configurar o serverless Private Git

  1. Siga as etapas para configurar um serviço de endpoint VPC para seu servidor Git privado. Este VPC endpoint permite que o senhor crie uma conexão AWS PrivateLink de serverless para backends em sua rede por trás de um NLB.

  2. Um administrador deve criar um endpoint VPC de interface do AWS no NCC do Databricks para cada servidor Git. Se o workspace precisar se conectar a vários servidores Git privados, o administrador deverá criar uma interface AWS VPC endpoint no Databricks NCC para cada servidor Git.

  3. Crie uma configuração de conectividade de rede (NCC) para configurar a saída para um balanceador de carga de rede. As considerações para essa etapa incluem o seguinte:

    • Apenas um NCC pode ser configurado para um workspace para Git privado. Se o workspace precisar se conectar a vários servidores Git privados, verifique se eles podem ser conectados usando o mesmo NCC.
    • As 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 aqui.

Crie uma configuração de conectividade de rede

  1. Adicionar uma regra de endpoint privado.

Adicionar uma regra de endpoint privado

  1. Aguarde pelo menos 10 minutos após configurar o endpoint de regra privada do NCC e, em seguida, no nível workspace, ative a visualização pública do Git privado sem servidor na página de visualizações.

  2. Acesse o site workspace e experimente Git operações. O senhor deverá ver um indicador de interface do usuário para o Serverless Private Git. Essa página pode levar alguns segundos para carregar.

Depois de configurado, o Git privado sem servidor tem precedência sobre outras formas de conectividade Git privada que o senhor já provisiona, como o proxy Git clássico e o Git privado empresarial. Se o senhor tiver um clustering de proxy Git em execução, pause-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 usuários do site Git permissões de visualização para o arquivo de configuração e para todos os arquivos CA cert referenciados pelo arquivo de configuração.
  3. Interagir com o Git para validar a conectividade com o Git remoto, 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 arquivo de configuração de nível superior

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

Seção `default` (opcional)

O padrão global é aplicado a todas as Git operações, a menos que seja substituído por um controle remoto específico.

campo

Tipo

Obrigatório

Valor padrão

Descrição

Verificação de SSL

boolean

Não

True

Se o senhor deve verificar os certificados SSL.

Caminho do CertPath

string

Não

" " (vazio)

caminho do espaço de trabalho para um certificado CA personalizado.

Proxy HTTP

string

Não

" " (vazio)

Proxy HTTP para rotear o tráfego do Git.

Porta HTTP personalizada

inteiro

Não

Não especificado

Porta HTTP personalizada do servidor Git.

Seção `remotes` (opcional)

Uma lista de objetos que definem configurações para servidores Git remotos individuais. Essas configurações substituem o bloco `default` em uma base por remoto.

campo

Tipo

Obrigatório

Valor padrão

Descrição

Prefixo de URL

string

Sim

Prefixo para corresponder aos URLs remotos do Git.

Verificação de SSL

boolean

Não

True

Se o senhor deve verificar os certificados SSL.

Caminho do CertPath

string

Não

" " (vazio)

caminho do espaço de trabalho para um caminho de certificado CA personalizado para esse controle remoto.

Proxy HTTP

string

Não

" " (vazio)

Proxy HTTP para rotear o tráfego do Git.

Porta HTTP personalizada

inteiro

Não

Não especificado

Porta HTTP personalizada do servidor Git.

Exemplo de configuração sem configuração remota específica


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

Exemplo de configuração 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

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

Outras recomendações de segurança

Se o gateway de saída seguro estiver ativado, verifique se a política de rede no console account aplicada ao workspace específico inclui o FQDN do servidor Git no destino de Internet permitido.

Verifique se o site workspace inclui o FQDN do servidor Git no destino de Internet permitido

Limitações

  • O proxy sem servidor log não está disponível no momento.
  • Disponível somente em AWS serverless regions. Para obter uma lista das regiões compatíveis, consulte Nuvens e regiões do Databricks.
  • O senhor não pode criar um serviço de endpoint VPC para servir o espaço de trabalho em várias regiões. Atualmente, o AWS NCC é um objeto regional e não é compatível com o endpoint VPC de várias regiões. Para conectar outro workspace de uma região diferente ao servidor Git, configure outro NLB e o serviço de endpoint VPC na nova região.