Pular para o conteúdo principal

Por que conectar o Devin a sistemas auto-hospedados?

Se a sua organização usa sistemas de gerenciamento de código-fonte auto-hospedados (como o GitLab) ou repositórios de artefatos (como o Artifactory), você ainda pode tirar total proveito do Devin SaaS. Ao expor esses serviços com segurança à infraestrutura do Devin, sua equipe mantém o controle dos seus sistemas enquanto permite que o Devin colabore de forma eficaz com o seu fluxo de desenvolvimento.

Visão geral

Sua equipe pode criar um Network Load Balancer (NLB), colocar os IPs estáticos do Devin em uma allowlist e publicar um registro DNS para ele. Essa abordagem:
  • Limita o acesso a uma superfície pequena e controlada – Apenas os IPs conhecidos do Devin podem se conectar
  • Exige menos de algumas horas de esforço de engenharia para configurar
  • Mantém sua infraestrutura atual – Não é necessário migrar para soluções em nuvem
  • Fornece gerenciamento centralizado – Balanceador de carga único opcional para vários serviços

Pré-requisitos

Antes de configurar a integração, certifique-se de que você tenha:
  • GitLab auto-hospedado (ou outro sistema de SCM) acessível na sua rede
  • Repositório de artefatos auto-hospedado (opcional), como Artifactory ou Nexus
  • Acesso de administração de rede para configurar firewalls, balanceadores de carga e DNS
  • Endereços IP estáticos do Devin – disponíveis aqui
Essa integração está disponível para clientes do plano Enterprise. Entre em contato com [email protected] se precisar de assistência.

Opções de configuração

Você tem duas abordagens principais para tornar seus serviços self-hosted acessíveis ao Devin: Mantenha sua infraestrutura auto-hospedada existente e simplesmente inclua os IPs estáticos do Devin na lista de permissões no nível do firewall. Para Gerenciamento de Código-Fonte (SCM):
  1. Configure seu firewall para permitir conexões de entrada a partir dos IPs do Devin (listados aqui)
  2. Certifique-se de que sua instância do GitLab (ou outro SCM) esteja acessível via HTTPS
  3. Forneça a URL ao Devin durante a configuração da integração
Para Repositórios de Artefatos:
  1. Adicione os IPs do Devin à allowlist do seu Artifactory/Nexus
  2. Certifique-se de que o repositório de artefatos esteja acessível via HTTPS
  3. Configure as credenciais apropriadas para o Devin acessar os artefatos
Se estiver usando um load balancer com seu repositório de artefatos, consulte a seção Load Balancer Considerations abaixo para detalhes importantes sobre a lista de permissões de IPs.

Opção 2: Load Balancer centralizado

Coloque vários serviços atrás de um único Application Load Balancer (ALB) ou Network Load Balancer (NLB) para filtragem centralizada de IPs. Benefícios:
  • Único ponto de gerenciamento para toda a filtragem de rede
  • Suporte a vários serviços internos com domínios diferentes
  • Auditorias de segurança e conformidade simplificadas

Considerações sobre o Load Balancer

Ao escolher entre Application Load Balancer (ALB) e Network Load Balancer (NLB), considere como cada um lida com allowlisting de IP: Application Load Balancer (ALB) - Recomendado para a maioria dos casos de uso:
  • O ALB opera na camada 7 (HTTP/HTTPS) e oferece recursos avançados de roteamento
  • O tráfego passa por NAT, então seus serviços de backend veem os endereços IP internos do ALB, e não os IPs de origem do Devin
  • Para repositórios de artefatos por trás de um ALB: você deve configurar o allowlisting de IP diretamente no Artifactory/Nexus, já que o IP interno do load balancer será visto pelo repositório
  • Use o AWS WAF para filtragem de IP no nível do ALB (veja o exemplo abaixo)
Network Load Balancer (NLB) - Adequado para cenários de allowlisting de IP:
  • O NLB opera na camada 4 (TCP) e preserva os endereços IP de origem
  • Seus serviços de backend veem os IPs de origem reais do Devin
  • Para repositórios de artefatos por trás de um NLB: o allowlisting de IP no nível do load balancer é suficiente, já que os IPs de origem são mantidos
  • Requer configuração manual de grupos de segurança (security groups) para cada endereço IP
Embora o ALB geralmente seja preferido por sua flexibilidade e facilidade de gerenciamento, o NLB funciona bem quando você precisa de allowlisting de IP no nível do load balancer, sem configuração adicional nos serviços de backend.

Exemplo de implementação na AWS

Aqui estão exemplos de configurações da AWS para as duas abordagens de balanceador de carga:

Application Load Balancer com WAF (Mais fácil)

# Criar um conjunto de IPs com os IPs estáticos do Devin
aws wafv2 create-ip-set \
  --name devin-allowed-ips \
  --scope REGIONAL \
  --ip-address-version IPV4 \
  --addresses 1.2.3.4/32 5.6.7.8/32 9.10.11.12/32 13.14.15.16/32

# Criar uma ACL web do WAF
aws wafv2 create-web-acl \
  --name devin-access-control \
  --scope REGIONAL \
  --default-action Block={} \
  --rules file://waf-rules.json

# Associar o WAF ao seu ALB
aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:region:account:regional/webacl/... \
  --resource-arn arn:aws:elasticloadbalancing:region:account:loadbalancer/app/...
Substitua os endereços IP pelos IPs corretos da nossa documentação de IPs permitidos.

Balanceador de Carga de Rede (grupos de segurança manuais)

# Adicione regras de entrada para cada IP do Devin no seu grupo de segurança
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 1.2.3.4/32

# Repita para cada endereço IP
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 5.6.7.8/32

# Continue para todos os IPs do Devin...

Configuração de DNS

Depois de configurar o balanceador de carga, crie um registro de DNS que o Devin possa usar:
# Exemplo: Aponte gitlab.suaempresa.com para o seu balanceador de carga
# O domínio será resolvido para o IP do balanceador de carga, que filtra o tráfego
# para permitir apenas conexões dos IPs na lista de permissões do Devin

# Usando o AWS Route 53:
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch file://dns-change.json
Exemplo de arquivo dns-change.json:
{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "gitlab.yourcompany.com",
      "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z215JYRZR1TBD5",
        "DNSName": "your-alb-name-123456.us-west-2.elb.amazonaws.com",
        "EvaluateTargetHealth": false
      }
    }
  }]
}

Etapas de integração

Após a configuração da infraestrutura de rede:
  1. Teste a conectividade - Verifique se seus serviços estão acessíveis de fora da sua rede usando o domínio configurado
  2. Entre em contato com o suporte da Devin - Fale com a Cognition e informe:
    • A URL do seu GitLab auto-hospedado (por exemplo, https://gitlab.yourcompany.com)
    • A URL do seu repositório de artefatos (se aplicável)
    • Quaisquer requisitos específicos de autenticação
  3. Conclua a configuração da integração - Trabalhe com a equipe da Devin para finalizar a conexão
  4. Configure os repositórios - Adicione seus repositórios à Devin’s Machine
Teste sua configuração de filtragem de IP antes de fornecer acesso à Devin, tentando se conectar a partir de um endereço IP que não esteja na lista de permissões (allowlist). A conexão deve ser bloqueada.

Melhores práticas

  • Use HTTPS - Sempre exponha os serviços via HTTPS com certificados SSL válidos
  • Crie uma conta de serviço dedicada - Configure uma conta específica para o Devin no seu sistema GitLab/SCM
  • Monitore os logs de acesso - Revise regularmente os logs de conexão a partir dos IPs do Devin
  • Documente sua configuração - Mantenha documentação interna do seu balanceador de carga e da configuração de DNS
  • Teste o failover - Garanta que sua configuração consiga lidar de forma adequada com falhas do balanceador de carga ou do serviço
  • Realize auditorias de segurança regulares - Revise periodicamente quais serviços estão expostos e verifique as listas de permissões de IP

Solução de problemas

Devin não consegue se conectar ao meu sistema autogerenciado (self-hosted):
  • Verifique se todos os endereços IP do Devin estão na lista de permissões (allowlist)
  • Confira se o seu certificado SSL é válido e confiável
  • Certifique-se de que os registros de DNS estejam configurados corretamente e já tenham se propagado
  • Verifique se as regras de firewall permitem tráfego HTTPS (porta 443)
Falhas de autenticação:
  • Confirme se as credenciais da conta de serviço (service account) estão corretas
  • Verifique se a conta de serviço tem as permissões apropriadas no seu sistema de SCM/artefatos
  • Verifique se há restrições de autenticação baseadas em IP além da allowlist
Problemas de desempenho:
  • Monitore as métricas do seu balanceador de carga para identificar gargalos
  • Certifique-se de que seus serviços autogerenciados (self-hosted) tenham recursos suficientes
  • Considere a proximidade geográfica entre a sua infraestrutura e os sistemas do Devin

Suporte

Para obter ajuda com integrações em ambiente self-hosted:
  1. Crie um canal Slack Connect com nossa equipe em app.devin.ai/settings/support
  2. Envie um e-mail para [email protected] com os detalhes específicos da sua configuração
  3. Compartilhe arquivos de configuração relevantes (com dados confidenciais ocultos) ao relatar problemas