Passage à GitLab :: Fricouv.eu

Passage à GitLab

Je vous avait déjà parlé de la forge logicielle que j’utilisais en 2018 (oui ça remonte un peu).

Entre temps, j’ai changé, mais j’avoue que je n’avais pas fait de billet sur ce changement et encore moins sur ces choix.
C’est suite à une question qui m’a été posé par mail que je fais ce billet (et je suis désolé sur le temps de traitement, mon blog n’est pas vraiment ma priorité, mais voilà maintenant chose faite).

Dans ce mail pour en reprendre rapidement le contexte, il m’est posé la question suivante (en simplifiant la question) :
« Pourquoi avez vous basculé sur GitLab plutôt que Gitea alors que vous le taxiez d’ềtre une usine à gaz. »

Je repose donc un petit peu de contexte pour pouvoir répondre à cette question pleinement.

Avant 2019

On va statuer sur le fait que la migration de forge que j’ai effectué c’est faite en 2019 pour ne pas complexifier la chose (comment ça je suis un poisson rouge et je ne me rappelle pas exactement ?).
Avant celà, j’étais à mes « balbuciemments » DevOps et plus généralement dans l’usage de Git et de ce que je pouvais en faire.

À ce moment là, j’utilisais Git pour stocker et versionner des configurations et des scripts essentiellement, mais je travaillais encore en mode « local » et manuel si je puis dire. Je n’avais quasi pas de traitement automatisé ou autre.

Dans ces conditions, Gitea me convenait très bien et avait juste les fonctionnalitées nécessaires que je cherchais dans une forge logicielle sans plus et avec une simplicité d’exploitation, de mise à jour et d’usage derrière qui convenait à 100% à ce que j’en faisais.

Fin 2018 début 2019, j’ai commencé à jouer avec de l’automation pour plusieurs choses (Ansible, Docker, …) et… J’ai kiffé… Du coup, j’ai commencé à regarder comment je pouvais intégrer des choses au niveau de ma forge pour justement qu’elle puisse faire ces traitements à ma place, histoire d’éviter les tâches répétitives.
Je suis tombé dans mes recherches sur ce que l’on appelle des « pipelines CI/CD », et ça a été plus ou moins la révélation, j’avais trouvé ce qui me permettrais d’automatiser un maximum de tâches à partir de ma forge.
Et c’est là ou le bas blesse… Intégrer du CI/CD avec Gitea c’est faisable je ne dis pas le contraire, mais l’intégrer facilement et surtout avec un niveau fonctionnel suffisamment élevé ça n’est pas forcément simple.

Du coup j’ai essayé, j’ai utilisé Drone pendant un moment, mais ça ne répondait pas vraiment à ce que je voulais. Gestion des variables inter-dépots, gestion des branches, intégration à d’autres outils, c’était relativement compliqué et pas super bien documenté (à l’époque du moins).
S’en est donc arrivé le moment « Qu’est-ce que je fais, est-ce que je switch pour utiliser quelque chose de plus costaud et de plus complexe ? »

2019 et le choix de GitLab

À côté de mes péripéties pour cette automatisation, j’ai un ami qui bossait avec GitLab sur des contextes assez costauds et avec des chaines de CI/CD assez violentes.
En est arrivé le moment où il m’a un peu présenté ce qu’on pouvait en faire et également le moment ou j’ai regardé… LA DOC !

Oui la doc de GitLab sur le volet CI/CD est juste très bien faite et surtout très complète (comme une grosse partie de leurs documentation ne nous le cachons pas).
Adjoint à ça, je commençais à voir des usages emmerger dans mon boulot, pour me simplifier la vie, gagner du temps et surtout je voyais la target un peu lointaine où on allait commencer à utiliser de l’automatisation de façon plus large.

J’ai tourné le truc dans tous les sens possible, et je retombais toujours sur GitLab.
Du coup, bah go on y va on prend son courage à deux mains et on migre tout.

Choix d’architecture

C’est là que tout c’est complexifié, et où j’ai fait un gros rollback entre temps.
GitLab est « déployable » de plusieurs façon. Celles qui m’intéressaient en premier temps étaient soit via Docker, soit « scratch » via les dépots pour CentOS.

Bon, niveau déploiement, je ne voulais pas trop me casser la tête alors j’ai tout déployé via Docker (La forge elle même + un runner pour les tâches de CI/CD).
Ça c’est très bien passé pendant assez longtemps on va dire. J’avais une machine qui consommait un peu de RAM (8Go quand même), mais ça tournais sans problèmes majeurs.
Puis vient le jour où j’ai fait pareil au boulot et où on a commencé à mettre des gens dessus (je parle ici de fin 2019 à peu près). Et là… Ça a été le drame !
Non seulement j’avais la forge qui explosait de façon aléatoire, mais impossible de comprendre pourquoi.

Le problème Docker

À un moment j’ai discuté avec des gens qui avait du GitLab à haut usage, et là est apparu quelque chose que je n’avais jamais identifié : Les Garbages Collector internes…
En fait, de façon récurente GitLab « passe le balai » sur ce qu’il utilise, il libère de la RAM pour le reste du système etc…
Sauf que… Les appels qui sont fait (je ne suis pas allé analyser plus loin je vous l’avoue) ne peuvent pas être tous correctement fait du moment où il tourne dans un container !

Et c’est là justement que j’ai fait un rollback monumental sur le choix d’architecture… Docker pour cette applis c’est le mal absolu ! En tout cas, comme il est packagé et livré. Ça fonctionne bien pour un « petit » usage, mais pas du moment où on veut avoir du monde dessus, on se retrouve à devoir avoir des machines avec une RAM monumentale pour… Rien…

Du coup réinstallation complète from packages sur une CentOS, migration totale via un gros coup de backup/restore (ça marche bien, le seul pré-requis c’est qu’il faut absolument la même version entre la source et la target… J’ai appris ça à mes dépends…).
Je suis passé d’une machine de 8Go de RAM complètement utilisé à une machine à 6Go utilisé à deux tiers plus. C’est fou comment ça change la vie alors que j’ai encore des users qui se sont accroché dessus.

Conclusion

Donc au final, j’ai certe changé de forge, mais je ne reviens pas en arrière sur ce que j’ai dis : GitLab est une vrai usine à gaz, ça fait énormément de choses, ce n’est pas toujours simple à configurer ni à mettre en place, mais ce qu’on ne peut pas lui enlever, c’est la stabilité quand c’est déployé proprement.
GitLab est, comme je l’ai dit, et restera quelque chose de « gros » et « lourd », tant au déploiement qu’à ce qu’il faut pour le faire tourner (encore que ça peut se discuter versus d’autres softs). Par contre, au regard du niveau d’intégration qu’il présente, c’est la seule forge « self-hostable » qui est à ce niveau qualitatif et d’intégration avec beaucoup de choses (registry, pipeline, notifications, …).

Si je devais retenir trois choses de cette aventure c’est :

  • Si vous devez utiliser une forge, qualifiez correctement le besoin et l’usage, ça sera déterminant dans le choix du soft
  • Si vous devez utiliser GitLab, ne le mettez JAMAIS dans Docker pour de la production
  • GitLab, ça se mérite, ça tombe pas en marche tout seul, et c’est « lourd » à configurer