Gitaly chez Scalingo : explication de la refonte de l’hébergement des dépôts Git de vos applications

Chez Scalingo, nous avons récemment entrepris une refonte complète de la manière dont nous hébergeons les dépôts Git de vos applications.

Nous souhaitions partager avec vous les raisons de cette refonte (adieu NFS), le choix que nous avons fait (bonjour Gitaly), ainsi que la manière dont nous l’avons mise en œuvre.

Mettons les mains dans le cambouis et plongeons dans l’infrastructure interne de Scalingo !

Rappel : les différentes façons de déployer du code sur Scalingo

Notre PaaS Scalingo propose plusieurs méthodes pour déployer une application :

• Utiliser une intégration avec un gestionnaire de code source. Connectez votre application à son dépôt sur des services comme GitHub ou GitLab, et déployez automatiquement à chaque nouveau push. Cette option est actuellement utilisée par plus de 40 % de nos clients, et ce chiffre continue d’augmenter. C’est une solution fiable pour garantir que votre application Scalingo reste synchronisée avec son code source.

• Utiliser notre intégration Git. Ajoutez un remote Git spécifique à votre dépôt local et déployez votre application avec une simple commande : git push scalingo master. Cette option est utilisée par les 60 % restants de nos clients.

• Utiliser notre API. Envoyez une archive compressée de votre code source à l’API pour déclencher un déploiement. Cette option est utilisée par une part si faible de clients qu’elle est difficile à quantifier.

Avant d’aller plus loin, donnons un peu de contexte sur ce qui nous a amenés à envisager une nouvelle solution.

Pourquoi passer à Gitaly chez Scalingo ?

Accompagner la croissance de Scalingo

Avec la croissance continue de Scalingo, nous souhaitions concevoir une architecture plus résiliente aux pannes et plus simple à maintenir.

Notre stack logicielle actuelle commençait à vieillir et devenait de plus en plus difficile à maintenir.

Des corruptions de dépôts Git

Certains clients ont rencontré des corruptions de dépôts Git via notre intégration, avec des messages d’erreur tels que :

fatal: '/mnt/git-mount/my-app.mount' does not appear to be a git repository

fatal: '/mnt/git-mount/my-app.mount' does not appear to be a git repository

fatal: '/mnt/git-mount/my-app.mount' does not appear to be a git repository

fatal: '/mnt/git-mount/my-app.mount' does not appear to be a git repository

Même si ce problème restait rare, il générait des demandes de support et nécessitait des interventions manuelles.

L’infrastructure Git historique de Scalingo

Le problème provient de l’architecture Git en place. De manière simplifiée :

Le code source de toutes les applications est stocké sur un dossier partagé NFS, accessible par tous les builders.

Cette architecture peut engendrer plusieurs problèmes. Par exemple, si plusieurs déploiements sont lancés rapidement sur une même application, certaines conditions de course peuvent provoquer un démontage du volume NFS en plein milieu d’un déploiement.

Par ailleurs, NFS posait déjà d’autres problèmes chez Scalingo :

• Problèmes de performance

• Latence réseau pour l’accès aux fichiers

• Processus bloqués en état de sommeil non interruptible

• Etc

En résumé : NFS était largement utilisé aux débuts de Scalingo. Nous nous en éloignons progressivement, et l’hébergement des dépôts Git était l’un des derniers éléments encore dépendants de cette technologie.

Adieu NFS

Le moment était venu de tourner la page NFS pour l’hébergement des dépôts Git. Nous avons étudié les solutions utilisées par d’autres acteurs.

Nous avons notamment constaté que :

• GitHub a développé sa propre solution, Spokes, pour abandonner NFS

• GitLab a créé Gitaly, un projet open source dédié à la gestion des dépôts

Nous avons également exploré d’autres options :

• Moderniser notre stack actuelle et remplacer NFS par du stockage objet

• Utiliser Git Ketch (anciennement utilisé chez Google)

• Utiliser Stemma avec notre propre logique de failover

Le meilleur choix

Nous avons comparé ces solutions selon différents critères : fonctionnalités Git nécessaires (push, fetch, etc.), complexité perçue, niveau de confiance, et temps d’implémentation.

Vous pouvez consulter l’image complète ici.

Nous avons finalement retenu Gitaly :

• Conçu pour remplacer NFS, comme notre besoin \o/

• Scalabilité horizontale

• Réduction des erreurs d’écriture

• Haute disponibilité

• Projet open source sous licence compatible

Fonctionnement de Gitaly

Gitaly repose sur deux composants : Gitaly et Praefect.

Gitaly est un daemon exécuté sur les nœuds stockant les données Git. Il expose une API Git de haut niveau via gRPC. Cela simplifie également le travail des opérateurs, qui n’ont plus besoin de maîtriser les détails internes de Git.

Praefect se charge de distribuer les connexions vers les nœuds Gitaly. Il détecte les pannes et redirige vers des nœuds sains. Il assure aussi la réplication des dépôts. C’est lui qui garantit la haute disponibilité.

Gitaly chez Scalingo

Voici l’architecture que nous avons retenue :

Comme montré sur ce schéma, nous utilisons désormais Praefect et Gitaly pour le stockage des dépôts Git, ainsi qu’un nouveau composant interne : Git Repository Core.

Ce service agit comme un routeur : il reçoit les connexions SSH issues de la commande git push scalingo master et les redirige soit vers NFS, soit vers Gitaly. Cela nous permet de déployer progressivement la nouvelle architecture (canary release).

Il est également responsable du déclenchement des déploiements.

Grâce à sa position centrale, Git Repository Core permet d’intercepter et de filtrer le trafic Git. Nous prévoyons d’y ajouter des fonctionnalités de sécurité et des améliorations, comme la possibilité de personnaliser la branche principale (par exemple main au lieu de master).

En interne, ce composant facilite aussi le travail des opérateurs via des endpoints d’administration.

Tous les éléments de cette architecture sont dupliqués pour renforcer la résilience.

Conclusion

Nous sommes ravis d’annoncer que l’infrastructure Gitaly est déjà en production.

Cette nouvelle architecture améliore la disponibilité des déploiements et ouvre la voie à de nouvelles fonctionnalités.

Une petite partie de nos clients utilise déjà cette architecture, et nous continuons la migration progressivement sans incident. Notre objectif est d’atteindre 50 % des applications fin avril, puis 100 % d’ici la fin de l’été.

Nous espérons que cet article vous a plu. N’hésitez pas à contacter notre support si vous avez des questions.

Rédigé par Étienne Michon, ingénieur R&D chez Scalingo

Photo par Pankaj Patel sur Unsplash