Configurar Gitprivado sem servidor Databricks

nota

Databricks Serverless Private Git está em versão prévia pública. Custos de computação e rede se aplicam quando um recurso compute serverless se conecta a um recurso externo. Consulte a seção "Entenda os custos de rede serverless Databricks para obter detalhes sobre o faturamento.

Databricks Private Git sem servidor permite conectar um workspace Databricks a um servidor Git privado usando compute serverless e PrivateLink. Um servidor Git é privado se os usuários da internet não puderem acessá-lo.

O diagrama a seguir ilustra a arquitetura geral do sistema:

Por que usar Git privado sem servidor?

Em comparação com o proxy de servidorGit, Git privado 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 Private Git sem servidor usa o PrivateLink para se conectar com segurança à instância privada Git .

Configure Gitprivado sem servidor.

1. Siga os passos para configurar um serviço de endpoint VPC para seu servidor Git privado. Este endpoint VPC permite criar uma conexão AWS PrivateLink de instâncias sem servidor para servidores back-end em sua rede, atrás de um Network Load Balancer (NLB).
2. Um administrador deve criar um endpoint de interface VPC da AWS 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.
   • Você pode configurar apenas um NCC por workspace para Git privado. Se o workspace se conectar a vários servidores Git privados, todos eles deverão usar o mesmo NCC.
   • Para limitações do NCC, como limites regionais e limites de conexão workspace , consulte Configurar um firewall para acesso compute serverless.

4. Adicionar uma regra de endpoint privado.

5. Aguarde pelo menos dez minutos após configurar as regras endpoint privado do NCC e, em seguida, ative a pré-visualização Git privado sem servidor nas configurações do seu workspace .
6. Execute uma operação Git no workspace. Um indicador na interface do usuário confirma que o Private Git sem servidor está ativo. O indicador pode demorar alguns segundos para aparecer enquanto compute serverless é iniciado.

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 as operações do Git usando um arquivo de configuração.

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 Git permissões de visualização para o arquivo de configuração e quaisquer arquivos de certificado CA aos quais ele faça referência.
3. Valide a conectividade com o repositório Git remoto executando uma operação Git , como clonar uma pasta Git .
4. O sistema pode levar até um minuto para aplicar as alterações no arquivo de configuração.

Estrutura do arquivo de configuração de nível superior

JSON

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

Seçãodefault (opcional)

As configurações padrão globais se aplicam a todas as operações Git a menos que um repositório remoto específico as substitua.

campo	Tipo	Obrigatório	Valor padrão	Descrição
sslVerify	boolean	Não	True	Se o senhor deve verificar os certificados SSL.
caCertPath	string	Não	" " (vazio)	caminho do espaço de trabalho para um certificado CA personalizado.
httpProxy	string	Não	" " (vazio)	Proxy HTTP para rotear o tráfego do Git.
customHttpPort	inteiro	Não	Não especificado	Porta HTTP personalizada do servidor Git.

Seçãoremotes (opcional)

Uma lista de objetos que definem as configurações de servidores Git remotos individuais. Essas configurações substituem o bloco default para cada dispositivo remoto individualmente.

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 específica para o servidor remoto.

JSON

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

Exemplo de configuração completa

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

Notas

• A seção default deve estar pelo menos parcialmente presente.
• A seção remotes é opcional. Se incluído, cada entrada deve incluir um campo urlPrefix .
• Os campos não especificados usarão seus valores 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 nome de domínio totalmente qualificado (FQDN) do servidor Git nos destinos de internet permitidos.

Limitações

• logs do proxy sem servidor não estão disponíveis.
• Git privado sem servidor está disponível apenas em regiões serverless . Para obter uma lista das regiões suportadas, consulte clouds e regiõesDatabricks.
• Não é possível criar um serviço endpoint VPC para disponibilizar o espaço de trabalho em várias regiões. Atualmente, o AWS NCC é um objeto regional e não oferece suporte a endpoints VPC multirregionais. Para conectar outro workspace de uma região diferente ao servidor Git , configure outro serviço endpoint NLB e VPC na nova região.