Zum Hauptinhalt springen

Warum Devin mit selbst gehosteten Systemen verbinden?

Wenn Ihre Organisation selbst gehostete Systeme für die Verwaltung von Quellcode (wie GitLab) oder Artefakt-Repositories (wie Artifactory) verwendet, können Sie dennoch den vollen Funktionsumfang von Devin SaaS nutzen. Indem Sie diese Dienste sicher für die Infrastruktur von Devin zugänglich machen, behält Ihr Team die Kontrolle über Ihre Systeme und ermöglicht Devin gleichzeitig, effektiv in Ihrem Entwicklungs-Workflow mitzuarbeiten.

Übersicht

Ihr Team kann einen Network Load Balancer (NLB) einrichten, Devins statische IPs auf die Allowlist setzen und einen DNS-Eintrag dafür veröffentlichen. Dieser Ansatz:
  • Begrenzt den Zugriff auf eine kleine, kontrollierte Angriffsfläche – nur Devins bekannte IPs können eine Verbindung herstellen
  • Erfordert weniger als ein paar Stunden Engineering-Aufwand für die Einrichtung
  • Bewahrt Ihre bestehende Infrastruktur – keine Migration auf cloud-gehostete Lösungen erforderlich
  • Ermöglicht zentrale Verwaltung – optional ein einzelner Load Balancer für mehrere Services

Voraussetzungen

Bevor Sie die Integration einrichten, stellen Sie sicher, dass Folgendes vorhanden ist:
  • Self-hosted GitLab (oder ein anderes SCM-System), das innerhalb Ihres Netzwerks erreichbar ist
  • Self-hosted Artefakt-Repository (optional), z. B. Artifactory oder Nexus
  • Netzwerkverwaltungszugriff, um Firewalls, Load Balancer und DNS zu konfigurieren
  • Statische IP-Adressen von Devin – zu finden hier
Diese Integration ist für Enterprise-Plan-Kunden verfügbar. Kontaktieren Sie [email protected], wenn Sie Unterstützung benötigen.

Einrichtungsoptionen

Es gibt zwei Hauptansätze, um Ihre selbstgehosteten Dienste für Devin verfügbar zu machen: Behalten Sie Ihre bestehende self-hosted Infrastruktur bei und geben Sie Devins statische IPs einfach auf Firewall-Ebene frei. Für das Source Code Management:
  1. Konfigurieren Sie Ihre Firewall so, dass eingehende Verbindungen von Devins IPs (aufgeführt hier) zugelassen werden
  2. Stellen Sie sicher, dass Ihre GitLab- (oder andere SCM-) Instanz über HTTPS erreichbar ist
  3. Geben Sie Devin während der Integrationseinrichtung die URL an
Für Artefakt-Repositories:
  1. Fügen Sie Devins IPs zur Allowlist Ihres Artifactory/Nexus hinzu
  2. Stellen Sie sicher, dass das Artefakt-Repository über HTTPS erreichbar ist
  3. Konfigurieren Sie geeignete Zugangsdaten, damit Devin auf Artefakte zugreifen kann
Wenn Sie einen Load Balancer mit Ihrem Artefakt-Repository verwenden, lesen Sie den Abschnitt Überlegungen zum Load Balancer weiter unten für wichtige Details zur IP-Allowlist.

Option 2: Zentraler Load Balancer

Platzieren Sie mehrere Dienste hinter einem einzigen Application Load Balancer (ALB) oder Network Load Balancer (NLB), um zentrales IP-Filtering zu ermöglichen. Vorteile:
  • Zentraler Verwaltungspunkt für alle Netzwerkfilter
  • Unterstützung mehrerer interner Dienste mit unterschiedlichen Domains
  • Vereinfachte Sicherheitsprüfungen und Compliance

Überlegungen zum Load Balancer

Bei der Wahl zwischen Application Load Balancer (ALB) und Network Load Balancer (NLB) sollten Sie berücksichtigen, wie jede Option mit IP-Allowlisting umgeht: Application Load Balancer (ALB) – für die meisten Anwendungsfälle empfohlen:
  • ALB arbeitet auf Layer 7 (HTTP/HTTPS) und bietet erweiterte Routing-Funktionen
  • Der Traffic läuft über NAT, sodass Ihre Backend-Services die internen IP-Adressen des ALB sehen und nicht die Quell-IPs von Devin
  • Für Artefakt-Repositories hinter einem ALB: Sie müssen IP-Allowlisting direkt auf Artifactory/Nexus konfigurieren, da das Repository die interne IP des Load Balancers sieht
  • Verwenden Sie AWS WAF für IP-Filterung auf ALB-Ebene (siehe Beispiel unten)
Network Load Balancer (NLB) – geeignet für IP-Allowlisting-Szenarien:
  • NLB arbeitet auf Layer 4 (TCP) und bewahrt die ursprünglichen Quell-IP-Adressen
  • Ihre Backend-Services sehen die tatsächlichen Quell-IPs von Devin
  • Für Artefakt-Repositories hinter einem NLB: IP-Allowlisting auf Load-Balancer-Ebene ist ausreichend, da die Quell-IPs beibehalten werden
  • Erfordert die manuelle Konfiguration der Security Groups für jede IP-Adresse
Während ALB im Allgemeinen aufgrund seiner Flexibilität und einfachen Verwaltung bevorzugt wird, eignet sich NLB gut, wenn Sie IP-Allowlisting auf der Load-Balancer-Ebene benötigen, ohne zusätzliche Konfiguration an den Backend-Services.

AWS-Implementierungsbeispiel

Hier sind Beispielkonfigurationen für AWS für beide Load-Balancer-Ansätze:

Application Load Balancer mit WAF (einfachere Variante)

# Erstellen Sie ein IP-Set mit Devins statischen IPs
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

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

# Verknüpfen Sie die WAF mit Ihrem 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/...
Ersetzen Sie die IP-Adressen durch die tatsächlichen IP-Adressen aus unserer Dokumentation zum IP-Whitelisting.

Network Load Balancer (manuelle Security Groups)

# Fügen Sie Ingress-Regeln für jede Devin-IP zu Ihrer Sicherheitsgruppe hinzu
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 1.2.3.4/32

# Für jede IP-Adresse wiederholen
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 5.6.7.8/32

# Für alle Devin-IPs fortfahren...

DNS-Konfiguration

Nachdem Sie Ihren Load-Balancer eingerichtet haben, legen Sie einen DNS-Eintrag an, den Devin verwenden kann:
# Beispiel: Richten Sie gitlab.yourcompany.com auf Ihren Load Balancer aus
# Die Domain wird zur Load Balancer-IP aufgelöst, die den Traffic filtert,
# um nur Verbindungen von Devins Whitelist-IPs zuzulassen

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

Integrationsschritte

Sobald Ihre Netzwerkinfrastruktur konfiguriert ist:
  1. Konnektivität testen – Stellen Sie sicher, dass Ihre Dienste von außerhalb Ihres Netzwerks über die konfigurierte Domain erreichbar sind
  2. Devin-Support kontaktieren – Wenden Sie sich an Cognition mit:
    • Ihrer selbst gehosteten GitLab-URL (z. B. https://gitlab.yourcompany.com)
    • Der URL zu Ihrem Artifact-Repository (falls zutreffend)
    • Eventuellen speziellen Authentifizierungsanforderungen
  3. Integrationseinrichtung abschließen – Arbeiten Sie mit dem Devin-Team zusammen, um die Verbindung endgültig herzustellen
  4. Repositories konfigurieren – Fügen Sie Ihre Repositories zu Devin’s Machine hinzu
Testen Sie Ihre IP-Filterkonfiguration, bevor Sie Devin Zugriff gewähren, indem Sie versuchen, von einer IP-Adresse aus eine Verbindung herzustellen, die nicht auf der Allowlist steht. Die Verbindung sollte blockiert werden.

Best Practices

  • HTTPS verwenden - Dienste stets über HTTPS mit gültigen SSL-Zertifikaten bereitstellen
  • Eigenes Servicekonto erstellen - Ein dediziertes Konto für Devin in Ihrem GitLab-/SCM-System einrichten
  • Zugriffsprotokolle überwachen - Verbindungsprotokolle von den Devin-IP-Adressen regelmäßig prüfen
  • Setup dokumentieren - Interne Dokumentation zu Ihrer Load-Balancer- und DNS-Konfiguration pflegen
  • Failover testen - Sicherstellen, dass Ihr Setup Ausfälle von Load Balancer oder Diensten reibungslos verkraftet
  • Regelmäßige Sicherheitsaudits - Regelmäßig prüfen, welche Dienste erreichbar sind, und IP-Allowlists verifizieren

Fehlerbehebung

Devin kann keine Verbindung zu meinem selbst gehosteten System herstellen:
  • Überprüfen Sie, ob alle Devin IP addresses auf der Allowlist stehen
  • Stellen Sie sicher, dass Ihr SSL-Zertifikat gültig und vertrauenswürdig ist
  • Stellen Sie sicher, dass DNS-Einträge korrekt konfiguriert und propagiert sind
  • Überprüfen Sie, ob Ihre Firewall-Regeln HTTPS-Datenverkehr (Port 443) zulassen
Authentifizierungsfehler:
  • Stellen Sie sicher, dass die Service-Account-Anmeldedaten korrekt sind
  • Überprüfen Sie, ob der Service-Account über die erforderlichen Berechtigungen in Ihrem SCM-/Artefakt-System verfügt
  • Prüfen Sie, ob es IP-basierte Authentifizierungsbeschränkungen außerhalb der Allowlist gibt
Leistungsprobleme:
  • Überwachen Sie die Metriken Ihres Load Balancers auf mögliche Engpässe
  • Stellen Sie sicher, dass Ihre selbst gehosteten Dienste über ausreichende Ressourcen verfügen
  • Berücksichtigen Sie die geografische Nähe zwischen Ihrer Infrastruktur und den Systemen von Devin

Support

Für Unterstützung bei Self-Hosted-Integrationen:
  1. Erstellen Sie einen Slack-Connect-Channel mit unserem Team unter app.devin.ai/settings/support
  2. Senden Sie eine E-Mail an [email protected] mit den Details zu Ihrem spezifischen Setup
  3. Teilen Sie relevante Konfigurationsdateien (mit geschwärzten sensiblen Daten), wenn Sie Probleme melden