Pourquoi connecter Devin à des systèmes auto-hébergés ?
Vue d’ensemble
Votre équipe peut créer un Network Load Balancer (NLB), autoriser les adresses IP statiques de Devin et publier un enregistrement DNS pour ce dernier. Cette approche :- Limite l’accès à une surface d’exposition réduite et maîtrisée - Seules les adresses IP connues de Devin peuvent se connecter
- Ne nécessite que quelques heures tout au plus d’effort d’ingénierie pour la mise en place
- Préserve votre infrastructure existante - Pas besoin de migrer vers des solutions hébergées dans le cloud
- Fournit une gestion centralisée - Un équilibreur de charge unique et facultatif pour plusieurs services
Prérequis
- GitLab auto-hébergé (ou un autre système de gestion de code source) accessible depuis votre réseau
- Référentiel d’artefacts auto-hébergé (facultatif), comme Artifactory ou Nexus
- Accès à l’administration réseau pour configurer les pare-feu, les équilibreurs de charge et le DNS
- Adresses IP statiques de Devin – disponibles ici
Cette intégration est disponible pour les clients disposant de l’offre Enterprise. Contactez [email protected] si vous avez besoin d’assistance.
Options de configuration
Option 1 : mise en liste d’autorisation directe d’adresses IP (recommandé)
- Configurez votre pare-feu pour autoriser les connexions entrantes depuis les adresses IP de Devin (listées ici)
- Assurez-vous que votre instance GitLab (ou autre SCM) est accessible via HTTPS
- Fournissez l’URL à Devin lors de la configuration de l’intégration
- Ajoutez les adresses IP de Devin à la liste d’autorisation de votre Artifactory/Nexus
- Assurez-vous que le dépôt d’artefacts est accessible via HTTPS
- Configurez les identifiants appropriés pour que Devin puisse accéder aux artefacts
Si vous utilisez un équilibreur de charge (load balancer) avec votre dépôt d’artefacts, consultez la section Considérations relatives à l’équilibreur de charge ci-dessous pour des informations importantes sur la mise en liste d’autorisation des adresses IP.
Option 2 : Load Balancer centralisé
- Point de gestion unique pour l’ensemble du filtrage réseau
- Prise en charge de plusieurs services internes avec des domaines différents
- Audit de sécurité et mise en conformité simplifiés
Considérations liées au load balancer
- L’ALB fonctionne à la couche 7 (HTTP/HTTPS) et fournit des capacités de routage avancées
- Le trafic passe par un NAT, de sorte que vos services backend voient les adresses IP internes de l’ALB, et non les IP source de Devin
- Pour les dépôts d’artefacts derrière un ALB : vous devez configurer l’autorisation par adresses IP directement sur Artifactory/Nexus, car l’IP interne du load balancer sera celle vue par le dépôt
- Utilisez AWS WAF pour le filtrage IP au niveau de l’ALB (voir exemple ci-dessous)
- Le NLB fonctionne à la couche 4 (TCP) et préserve les adresses IP source originales
- Vos services backend voient les IP source réelles de Devin
- Pour les dépôts d’artefacts derrière un NLB : l’autorisation par adresses IP au niveau du load balancer est suffisante, puisque les IP source sont conservées
- Nécessite une configuration manuelle des groupes de sécurité pour chaque adresse IP
Exemple d’implémentation AWS
Application Load Balancer avec WAF (plus simple)
Remplacez les adresses IP par les adresses IP réelles figurant dans notre documentation sur la liste d’autorisation d’adresses IP.
Network Load Balancer (Security Groups manuels)
Configuration DNS
dns-change.json :
Étapes d’intégration
- Tester la connectivité - Vérifiez que vos services sont accessibles depuis l’extérieur de votre réseau en utilisant le nom de domaine configuré
- Contacter le support Devin - Contactez Cognition avec :
- L’URL de votre instance GitLab auto‑hébergée (par exemple,
https://gitlab.votreentreprise.com) - L’URL de votre dépôt d’artefacts (le cas échéant)
- Toute exigence particulière en matière d’authentification
- L’URL de votre instance GitLab auto‑hébergée (par exemple,
- Finaliser la configuration de l’intégration - Collaborez avec l’équipe Devin pour finaliser la connexion
- Configurer les dépôts - Ajoutez vos dépôts à Devin’s Machine
Bonnes pratiques
- Utiliser HTTPS - Exposez toujours les services en HTTPS avec des certificats SSL valides
- Créer un compte de service dédié - Configurez un compte spécifique pour Devin dans votre système GitLab/SCM
- Surveiller les journaux d’accès - Examinez régulièrement les journaux de connexion provenant des adresses IP de Devin
- Documenter votre configuration - Conservez une documentation interne de la configuration de votre équilibreur de charge et de votre DNS
- Tester le basculement - Assurez-vous que votre configuration peut gérer correctement les pannes de l’équilibreur de charge ou des services
- Audits de sécurité réguliers - Passez périodiquement en revue les services exposés et vérifiez les listes d’adresses IP autorisées
Dépannage
- Vérifiez que toutes les adresses IP de Devin figurent dans la liste d’autorisation
- Vérifiez que votre certificat SSL est valide et de confiance
- Assurez-vous que les enregistrements DNS sont correctement configurés et propagés
- Vérifiez que les règles de votre pare-feu autorisent le trafic HTTPS (port 443)
- Confirmez que les identifiants du compte de service sont corrects
- Vérifiez que le compte de service dispose des autorisations appropriées dans votre système de SCM/de gestion d’artefacts
- Recherchez d’éventuelles restrictions d’authentification par adresse IP autres que celles définies dans la liste d’autorisation
- Surveillez les métriques de votre équilibreur de charge afin d’identifier les goulets d’étranglement
- Assurez-vous que vos services auto-hébergés disposent de ressources suffisantes
- Prenez en compte la proximité géographique entre votre infrastructure et les systèmes de Devin
Support
- Créez un canal Slack Connect partagé avec notre équipe via app.devin.ai/settings/support
- Envoyez un e-mail à [email protected] avec les détails précis de votre configuration
- Partagez les fichiers de configuration pertinents (avec les données sensibles masquées) lorsque vous signalez un problème
