Pour diverses raisons, je vomis Debian, Ubuntu, CentOS et autres distributions populaires. Au contraire, je prends mon pied avec Gentoo, et plus récemment avec Alpine. Je ne m’étendrais pas plus que cela, ce sujet mérite à mon avis un poste dédié. La plupart du temps, je m’y retrouve mais pour GitLab, une aventure a commencé.

Il était une fois…

Pour l’historique, j’ai commencé avec SVN pour gérer mes sources et ceux de ma boîte. A cette époque là, il n’existait pas réellement d’alternative cloud, il fallait gérer soi-même l’hébergement, ce que j’ai fait naturellement.

Puis il y a eu des déplacements, l’impossibilité de fetcher le dépôt SVN sur le téléphone ou lorsque je n’étais pas sur mon poste de travail ou tout simplement le souhait de vouloir consulter une version spécifique du code sans devoir récupérer la copie à partir de mon poste. Pour rappel, contrairement à git ou mercurius, une copie de travail svn ne contient qu’une seule version (la base de travail) et les modifications en cours (les fichiers modifiés par rapport à la base). L’historique est consultable à travers un client svn mais est en réalité stocké sur un serveur svn. Un serveur « git » est un abus de langage au sens où git est un VCS décentralisé : la copie sur un serveur git contient autant d’information que la copie sur un poste de travail, autrement dit : il est possible de consulter tout l’historique d’un dépôt uniquement à partir d’une copie sur un poste de travail en déconnecté. C’est l’un des points forts de git, mais rend de fait les dépôts locaux assez fat. J’avais déjà mis en place redmine, un outil de gestion de projet relativement simple, pour la gestion des accès et il proposait un accès web aux dépôts. Ca a fait le taff durant plusieurs années.

Pendant ce temps, l’écosystème git se développe, github devient incontournable, des alternatives cloud apparaissent avec bitbucket, gitorius, gitlab, les outils permettant d’utiliser git sans prises de têtes deviennent assez matures, il est temps d’abandonner svn pour git, les avantages de git n’étant plus dans l’ombre de sa ligne de commande ô-combien puissante, mais horrible d’utilisation. Eventuellement nos projets passent sous git mais toujours sous gestion redmine.

En parallèle je fais une excursion professionnelle sous TFS 2010, le produit s’intégrant bien avec une gestion centralisé de la sécurité sous Active Directory. J’ai expérimenté TFS et son VCS propriétaire TFVC au travers d’un projet web. TFVC est une véritable horreur côté dev, chaque fichier modifié devant d’abord être marqué modifiable. TFS est en soit pas mal, mais TFVC ne figure pas dans ses points forts, étant en outre un VCS centralisé à l’instar de SVN.

Et un jour (automne 2016), Gitlab est arrivé sur la table. Un clone de github, que j’apprécie pour sa simplicité et la notion de merge-request, à installer chez soi (on-premise). Gitlab propose des packages d’installation pour les distributions usuelles mais rien pour Gentoo, si ce n’est l’installation from source. J’avoue ne pas être très surpris. J’y vais donc à suivre le tutoriel d’installation à partir des sources et, afin de contrôler les fichiers installés et faciliter les mises à jour, créer les ebuilds (packages Gentoo boites blanches).

Gitlab

Gitlab est un produit complexe. Chacun de ses composants a sa propre installation, qui fonctionne mais n’est pas clean d’un point de vue packaging (il n’y a pas de clean up des codes sources go après compilation par exemple, ce qui ne sert à rien au runtime). L’écriture des ebuilds est en soit un petit challenge, que je relève haut la main… jusqu’à ce que gitlab passe à ruby 2.3 à partir de leur mouture 9.x. Gentoo est encore à ce jour coincé en ruby 2.2. Impossible de mettre à jour Gitlab, je le laisse en état pendant plusieurs mois en attendant de trouver une solution qui m’éviterais d’installer un ruby 2.3 instable sous Gentoo.

Plusieurs mois plus tard je monte une plateforme Docker, pour l’instant standalone. Il est peut-être temps de voir s’il l’on peu dockeriser Gitlab. Gitlab propose sa propre image Docker officielle mais elle est basée sur Ubuntu (et pas la dernière) et comme dit au début, c’est à vomir. Rien que par la surcharge pondérale des images docker basées sur Ubuntu/Debian en comparaison de Alpine, surcharge qui ne les rendent même pas plus pratique à l’utilisation. Faite donc un less sur l’image Cassandra, Oops ya pas, on tente view alors, ah bah ça n’existe pas, et vi n’est pas non plus fournit. En 5MB, alpine fournit tout ça de base et plus. Je ne fais pas spécialement de pub pour Alpine mais il est difficile de ne pas s’énerver quand on se retrouve à poil à débugger une image fat et moisie.

Maîtrisant plutôt bien l’installation source de Gitlab ainsi que le packaging Alpine, je me lance dans la création d’une image Docker permettant de faire tourner une version à jour de Gitlab. Cela ma conduit à créer plusieurs packages intermédiaires, ruby2.3, yarn (node js), gitlab-shell, gitlab-gitaly. Après pas mal d’effort, j’arrive à avoir une image fonctionnelle en 10.2.5 ! Youpi !!

git-archive

Mais c’est aussi là que j’arrête l’image custo. Alors que l’image officielle de gitlab arrive à intégrer Gitlab et toutes ses dépendances et même plus (postgresql, redis, mattermost, prometheus), mon image ne contient que Gitlab et se prend 100Mo de plus, même en supprimant les packages non-nécessaires au runtime. Frustrant mais s’explique notamment par le manque d’instructions sur le clean, celles-ci étant décrites dans le cookbook ayant servi à concevoir l’image officielle. Mais je n’ai pas le courage de déchiffrer ce qu’à fait le chef.
J’ai mis beaucoup d’effort dans la conception de cette image Docker mais ce n’est pas assez pour qu’elle soit prod-ready, contrairement aux ebuilds Gentoo. Cette fois, j’abandonne, Ubuntu a gagné. J’ai converti la base de données mysql en postgresql pour pouvoir utiliser l’image officielle Docker et c’est dessus que je vais rester. Cette défaite va me permettre de me focus sur d’autres projets à hacker 🙂

Le travail n’aura pas été totalement vain. J’aurais appris au moins deux choses :

• l’architecture de Gitlab
• savoir sacrifier certaines choses pour pouvoir se concentrer sur d’autres

Sur cette fin, je félicite d’avance les acharnés qui m’auront lu jusqu’au bout :p