Começando com Databricks serverless Private Git
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:
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
-
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.
-
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.
-
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.
- Adicionar uma regra de endpoint privado.
-
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.
-
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.
- Crie um arquivo de configuração em
/Workspace/.git_settings/config.json
, seguindo a especificação abaixo. - 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.
- Interagir com o Git para validar a conectividade com o Git remoto, como clonar uma pasta Git para um repositório remoto no servidor.
- 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.
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.