Vai al contenuto principale

​
Perché collegare Devin a sistemi self-hosted?

Se la tua organizzazione utilizza sistemi self-hosted di gestione del codice sorgente (come GitLab) o repository di artifact (come Artifactory), puoi comunque sfruttare appieno Devin SaaS. Esponendo in modo sicuro questi servizi all’infrastruttura di Devin, il tuo team mantiene il controllo dei propri sistemi consentendo al tempo stesso a Devin di collaborare in modo efficace con il tuo flusso di lavoro di sviluppo.

​
Panoramica

Il tuo team può creare un Network Load Balancer (NLB), configurare la allowlist con gli IP statici di Devin e pubblicare un record DNS per il bilanciatore. Questo approccio:
  • Limita l’accesso a una superficie ridotta e controllata - Solo gli IP noti di Devin possono connettersi
  • Richiede al massimo poche ore di lavoro di engineering per essere configurato
  • Mantiene la tua infrastruttura esistente - Non è necessario migrare a soluzioni ospitate nel cloud
  • Offre una gestione centralizzata - Con la possibilità di utilizzare un singolo bilanciatore di carico per più servizi

​
Prerequisiti

Prima di configurare l’integrazione, assicurati di disporre di:
  • GitLab self-hosted (o un altro sistema SCM) accessibile all’interno della tua rete
  • Repository di artifact self-hosted (opzionale), ad esempio Artifactory o Nexus
  • Accesso come amministratore di rete per configurare firewall, load balancer e DNS
  • Indirizzi IP statici di Devin - disponibili qui
Questa integrazione è disponibile per i clienti con piano Enterprise. Contatta [email protected] se hai bisogno di assistenza.

​
Opzioni di configurazione

Hai due approcci principali per rendere accessibili i tuoi servizi self-hosted a Devin: Mantieni la tua infrastruttura self-hosted esistente e aggiungi semplicemente gli IP statici di Devin alla whitelist a livello di firewall. Per la gestione del codice sorgente (SCM, Source Code Management):
  1. Configura il firewall in modo da consentire connessioni in ingresso dagli IP di Devin (elencati qui)
  2. Assicurati che la tua istanza GitLab (o un altro SCM) sia accessibile via HTTPS
  3. Fornisci l’URL a Devin durante la configurazione dell’integrazione
Per i repository di artifact:
  1. Aggiungi gli IP di Devin alla allowlist di Artifactory/Nexus
  2. Assicurati che il repository di artifact sia accessibile via HTTPS
  3. Configura le credenziali appropriate per consentire a Devin di accedere agli artifact
Se utilizzi un load balancer con il tuo repository di artifact, consulta la sezione Considerazioni sul load balancer qui sotto per dettagli importanti sull’allowlisting degli IP.

​
Opzione 2: Load Balancer centralizzato

Colloca più servizi dietro un singolo Application Load Balancer (ALB) o Network Load Balancer (NLB) per applicare un filtraggio IP centralizzato. Vantaggi:
  • Punto di gestione unico per l’intero filtraggio di rete
  • Supporto per più servizi interni con domini diversi
  • Verifiche di sicurezza e conformità semplificate

​
Considerazioni sul Load Balancer

Quando devi scegliere tra Application Load Balancer (ALB) e Network Load Balancer (NLB), valuta come ognuno gestisce l’allowlisting degli IP: Application Load Balancer (ALB) - Consigliato per la maggior parte dei casi d’uso:
  • ALB opera al Layer 7 (HTTP/HTTPS) e fornisce funzionalità avanzate di routing
  • Il traffico passa attraverso NAT, quindi i tuoi servizi di backend vedono gli indirizzi IP interni dell’ALB, non gli IP sorgente di Devin
  • Per repository di artefatti dietro ALB: devi configurare l’allowlisting degli IP direttamente su Artifactory/Nexus, poiché il repository vedrà l’IP interno del load balancer
  • Usa AWS WAF per il filtraggio IP a livello di ALB (vedi l’esempio seguente)
Network Load Balancer (NLB) - Adatto per scenari che richiedono IP allowlisting:
  • NLB opera al Layer 4 (TCP) e preserva gli indirizzi IP sorgente originali
  • I tuoi servizi di backend vedono gli IP sorgente effettivi di Devin
  • Per repository di artefatti dietro NLB: l’allowlisting degli IP a livello di load balancer è sufficiente, poiché gli IP sorgente vengono mantenuti
  • Richiede la configurazione manuale del security group per ciascun indirizzo IP
Sebbene ALB sia generalmente preferito per la sua flessibilità e facilità di gestione, NLB funziona bene quando hai bisogno di allowlisting degli IP a livello di load balancer senza configurazioni aggiuntive sui servizi di backend.

​
Esempio di implementazione AWS

Ecco alcune configurazioni AWS di esempio per entrambi gli approcci al load balancer:

​
Application Load Balancer con WAF (più semplice)

# Crea un set di IP con gli IP statici di 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

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

# Associa il WAF al tuo 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/...
Sostituisci gli indirizzi IP con gli indirizzi IP effettivi indicati nella nostra documentazione sul whitelisting degli IP.

​
Network Load Balancer (gruppi di sicurezza configurati manualmente)

# Aggiungi regole in ingresso per ogni IP di Devin al tuo gruppo di sicurezza
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 1.2.3.4/32

# Ripeti per ogni indirizzo IP
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 5.6.7.8/32

# Continua per tutti gli IP di Devin...

​
Configurazione DNS

Dopo aver configurato il load balancer, crea un record DNS che Devin possa utilizzare: 
# Esempio: Puntare gitlab.tuaazienda.com al load balancer
# Il dominio risolverà all'IP del load balancer, che filtra il traffico
# per consentire solo le connessioni dagli IP autorizzati di Devin

# Utilizzo di AWS Route 53:
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch file://dns-change.json
Esempio del file 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
      }
    }
  }]
}

​
Passaggi di integrazione

Una volta configurata l’infrastruttura di rete:
  1. Verifica la connettività - Verifica che i tuoi servizi siano accessibili dall’esterno della tua rete utilizzando il dominio configurato
  2. Contatta il supporto Devin - Rivolgiti a Cognition indicando:
    • Il tuo URL GitLab self-hosted (ad es. https://gitlab.yourcompany.com)
    • L’URL del tuo artifact repository (se applicabile)
    • Eventuali requisiti specifici di autenticazione
  3. Completa la configurazione dell’integrazione - Collabora con il team Devin per finalizzare la connessione
  4. Configura i repository - Aggiungi i tuoi repository a Devin’s Machine
Verifica la configurazione del filtraggio IP prima di concedere l’accesso a Devin tentando di connetterti da un indirizzo IP che non è incluso nella allowlist. La connessione dovrebbe essere bloccata.

​
Best Practices

  • Usa HTTPS - Esponi sempre i servizi tramite HTTPS con certificati SSL validi
  • Crea un account di servizio dedicato - Configura un account specifico per Devin nel tuo sistema GitLab/SCM
  • Monitora i log di accesso - Verifica regolarmente i log delle connessioni dagli IP di Devin
  • Documenta la tua configurazione - Mantieni documentazione interna sul tuo load balancer e sulla configurazione DNS
  • Verifica il failover - Assicurati che la tua configurazione gestisca correttamente i guasti del load balancer o dei servizi
  • Audit di sicurezza periodici - Riesamina periodicamente quali servizi sono esposti e verifica le allowlist di IP

​
Risoluzione dei problemi

Devin non riesce a connettersi al mio sistema self-hosted:
  • Verifica che tutti gli indirizzi IP di Devin siano stati aggiunti all’allowlist
  • Controlla che il tuo certificato SSL sia valido e considerato attendibile
  • Assicurati che i record DNS siano configurati correttamente e che la propagazione sia completata
  • Verifica che le regole del firewall consentano il traffico HTTPS (porta 443)
Errori di autenticazione:
  • Conferma che le credenziali dell’account di servizio siano corrette
  • Verifica che l’account di servizio disponga delle autorizzazioni appropriate nel tuo sistema SCM/artifact
  • Controlla l’eventuale presenza di restrizioni di autenticazione basate su IP oltre all’allowlist
Problemi di prestazioni:
  • Monitora le metriche del tuo load balancer per individuare eventuali colli di bottiglia
  • Assicurati che i tuoi servizi self-hosted dispongano di risorse adeguate
  • Considera la vicinanza geografica tra la tua infrastruttura e i sistemi di Devin

​
Supporto

Per assistenza con le integrazioni self-hosted:
  1. Crea un canale Slack Connect con il nostro team su app.devin.ai/settings/support
  2. Invia un’e-mail a [email protected] con i dettagli specifici della tua configurazione
  3. Condividi i file di configurazione pertinenti (con i dati sensibili rimossi) quando segnali un problema