Depuis un certain temps, je travaille sur un projet qui utilise GitLab Runner avec Docker comme exécuteur. Puisque les coureurs sont hébergés sur CentOS 7, tout avait du sens, jusqu'à ce que nous commencions à envisager de le déplacer vers CentOS 8, et notre monde a explosé.
La première chose à laquelle nous pensions était que, puisque Podman est un remplacement instantané, cela devrait être facile (vous pouvez imaginer vous-mêmes la véracité de cette déclaration). La vérité était que Podman n'avait pas l'API que GitLab Runner utilisait pour gérer les conteneurs, donc même si nous pouvions tout faire manuellement, nous n'en étions pas encore là.
OK, revenons à la planche à dessin, que diriez-vous de déposer un problème GitLab pour que GitLab Runner implémente Podman en tant qu'exécuteur ? Il s'avère que le problème existait déjà. La réponse paraphrasée était:"nous ne prenons pas de nouveaux exécuteurs testamentaires, mais si vous l'écrivez vous-même, nous pouvons voir si nous pouvons le prendre." Ma connaissance des rouages de GitLab Runner est pire que mon allemand, et tout ce que je peux dire, c'est "Danke", même pas le mot en entier.
N'essayez pas cela à la maison
Cette migration "simple" était tout sauf, donc en dernier recours, nous avons pensé qu'il devait y avoir un moyen d'installer Docker dans CentOS8. Eh bien, vous pouvez lire des "tutoriels" qui le font, mais ils vous donnent envie de vous arracher les yeux, donc ce n'était pas une option. (Sérieusement, n'essayez pas ça à la maison).
[ Vous aimerez peut-être aussi : Amélioration de l'intégration systemd avec Podman 2.0 ]
Un certain temps s'est écoulé et nous sommes temporairement passés à un autre projet plus urgent. Même si nous voulions tout déplacer vers CentOS 8, rien ne nous pressait.
Mais il y a quelques mois, nous avons trouvé un article disant que Podman implémentait une API REST compatible Docker. C'était comme s'ils lisaient dans nos pensées; c'est exactement ce dont nous avions besoin. Cela devrait être facile maintenant. (Vous voyez où je veux en venir, n'est-ce pas ?)
Nous avons recommencé à tester lorsque Podman 2.0 est sorti, tous heureux et optimistes. GitLab Runner se connectait au socket mais ne parvenait pas à créer des volumes. Ensuite, nous avons lu les notes de version plus attentivement, et ils ont dit que le point de terminaison pour les volumes n'était pas encore implémenté, mais qu'il était dans l'arborescence principale (bientôt 2.1). Nous avions donc encore une chance.
Un backport hacky
Quelques jours passèrent; nous avons effectué un rétroportage hacky du point de terminaison des volumes vers la version 2.0 et avons également essayé la branche principale, mais tout échouait et nous ne savions pas pourquoi.
Heureusement, Podman 2.1 est sorti assez rapidement et nous étions de retour sur la bonne voie. Nous avons recommencé, mais cette fois, nous avons adopté une approche différente. Après avoir commenté un peu le problème correspondant de Podman, nous avons commencé à traîner dans #podman sur IRC et à poser des questions sur ce problème. Nous avons reçu quelques réponses des développeurs, et c'est là que les choses sont devenues intéressantes !
Nous avons mis en place un référentiel de test dans GitLab, enregistré un groupe de coureurs et commencé à résoudre chaque problème, un par un. Nous avons également configuré une instance Docker à utiliser comme référence, mais avons surveillé toutes ses communications avec GitLab Runner à l'aide de socat. – de cette façon, nous pouvions voir exactement ce qui se passait et ce que nous devions faire correspondre.
Nous avons commencé avec un problème où le travail semblait fonctionner, mais en réalité il ne faisait rien ; le pire de tout, il n'enregistrait rien, donc les gars devaient d'abord réparer les journaux, puis revenir au problème principal. Avec cela à l'écart, il y avait un autre problème avec les entrées /dev, qui a également été résolu. Après quelques jours de test, les choses commençaient à être vraiment bonnes; nous pourrions exécuter des one-liners faciles sans trop de problèmes. Nous pensions donc que nous avions terminé, mais nous avions encore du chemin à faire.
Lorsque nous sommes passés à des travaux plus longs, ils étaient coupés au milieu en raison d'un problème de suivi des connexions inactives. La correction qui a conduit à un autre problème avec Podman ne se fermant jamais, mais les responsables de Podman ont résolu ces deux problèmes.
Bogue pour bogue
Cependant, il y avait un problème qui nous dérangeait depuis le début :il nous obligeait à supprimer les volumes avant chaque exécution. La chose que personne ne vous dit à propos de la compatibilité, c'est que parfois, pour y parvenir, vous devez être compatible bogue pour bogue. Docker a signalé un problème il y a plus de cinq ans concernant le fait que lorsque vous demandez à créer un volume qui existe déjà, il renvoie "tout va bien" et fait comme si rien ne s'était passé. Podman, d'autre part, renvoyait le bon message d'erreur (l'accent est mis sur "était", car il agit désormais de la même manière que Docker, du moins en mode de compatibilité. Bug pour bug, n'est-ce pas ?)
Une fois ces problèmes majeurs résolus, certaines choses mineures sont apparues, mais tout fonctionnait bien, du moins pour ce que nous pouvions tester.
[ Manuel du propriétaire de l'API :7 bonnes pratiques pour des programmes d'API efficaces ]
Conclusion
Alors, comment ça va maintenant ? Eh bien, tous les problèmes que nous avons rencontrés avec Podman ont tous maintenant des correctifs dans la branche principale, et si tout se passe bien, ils feront partie de la prochaine version de Podman 2.2. Cela marquera la première version de Podman qui peut fonctionner avec GitLab Runner dès la sortie de la boîte, sans même savoir qu'il parle à Podman. C'est une étape vraiment importante pour nous.