Ich arbeite seit einiger Zeit an einem Projekt, das GitLab Runner mit Docker als Executor verwendet. Da Runner auf CentOS 7 gehostet werden, machte alles Sinn – bis wir anfingen, es auf CentOS 8 zu verschieben, und unsere Welt explodierte.
Das erste, was wir dachten, war, da Podman ein Drop-in-Ersatz ist, sollte dies einfach sein (Sie können sich selbst vorstellen, wie wahr diese Aussage ist). Die Wahrheit war, dass Podman nicht über die API verfügte, die GitLab Runner zum Verwalten der Container verwendete. Selbst wenn wir alles manuell erledigen könnten, waren wir noch nicht am Ziel.
OK, zurück zum Reißbrett, wie wäre es, wenn wir ein GitLab-Problem für GitLab Runner einreichen, um Podman als Executor zu implementieren? Es stellt sich heraus, dass das Problem bereits existierte. Die paraphrasierte Antwort lautete:"Wir nehmen keine neuen Testamentsvollstrecker, aber wenn Sie es selbst schreiben, können wir sehen, ob wir es übernehmen können." Meine Kenntnisse der Interna von GitLab Runner sind schlechter als mein Deutsch, und ich kann nur "Danke" sagen, nicht einmal das ganze Wort.
Versuche das nicht zu Hause
Diese „einfache“ Migration war alles andere als das. Als letzten Ausweg dachten wir, dass es eine Möglichkeit geben muss, Docker in CentOS8 zu installieren. Nun, Sie können einige "Tutorials" lesen, die das tun, aber Sie möchten sich die Augen auskratzen, also war das keine Option. (Im Ernst, versuchen Sie das nicht zu Hause).
[Das könnte Ihnen auch gefallen:Verbesserte systemd-Integration mit Podman 2.0 ]
Es verging einige Zeit, und wir wechselten vorübergehend zu einem anderen Projekt, das dringender war. Obwohl wir alles auf CentOS 8 umstellen wollten, hatten wir keine Eile.
Aber dann haben wir vor ein paar Monaten einen Beitrag gefunden, der besagt, dass Podman eine Docker-kompatible REST-API implementiert. Es fühlte sich an, als würden sie unsere Gedanken lesen; das ist genau das, was wir brauchten. Das sollte jetzt einfach sein. (Sie sehen, worauf ich damit hinaus will, oder?)
Als Podman 2.0 veröffentlicht wurde, begannen wir erneut mit dem Testen, alle glücklich und optimistisch. GitLab Runner stellte eine Verbindung zum Socket her, konnte jedoch keine Volumes erstellen. Dann haben wir die Versionshinweise genauer gelesen, und sie sagten, dass der Endpunkt für Volumes noch nicht implementiert sei, aber er sei im Hauptbaum (bald 2.1). Wir hatten also noch eine Chance.
Ein hackiger Backport
Ein paar Tage vergingen; Wir machten einen hackigen Backport des Volumes-Endpunkts auf 2.0 und versuchten es auch mit dem Hauptzweig, aber alles schlug fehl und wir hatten keine Ahnung, warum.
Glücklicherweise wurde Podman 2.1 ziemlich schnell veröffentlicht und wir waren wieder auf Kurs. Wir haben wieder angefangen, aber dieses Mal haben wir einen anderen Ansatz gewählt. Nachdem wir das entsprechende Podman-Problem ein wenig kommentiert hatten, fingen wir an, in #podman im IRC herumzuhängen und Fragen zu diesem Problem zu stellen. Wir haben einige Antworten von den Entwicklern erhalten, und dann wurde es interessant!
Wir haben ein Test-Repository in GitLab eingerichtet, eine Reihe von Runnern registriert und begonnen, jedes Problem einzeln anzugehen. Wir haben auch eine Docker-Instanz als Basis eingerichtet, aber die gesamte Kommunikation mit GitLab Runner mithilfe von socat überwacht – Auf diese Weise konnten wir genau sehen, was los war und was wir abgleichen mussten.
Wir begannen mit einem Problem, bei dem der Job zu funktionieren schien, aber tatsächlich nichts bewirkte; Am schlimmsten war, dass nichts protokolliert wurde, also mussten die Jungs zuerst die Protokolle reparieren und dann zum Hauptproblem zurückkehren. Nachdem dies aus dem Weg geräumt war, gab es ein weiteres Problem mit /dev-Einträgen, das ebenfalls gelöst wurde. Nach ein paar Testtagen sahen die Dinge wirklich gut aus; Wir konnten einfache Einzeiler ohne große Probleme ausführen. Also dachten wir, wir wären fertig, aber wir hatten tatsächlich noch ein Stück Weg vor uns.
Als wir zu länger laufenden Jobs übergingen, wurden sie aufgrund eines Problems bei der Nachverfolgung von Leerlaufverbindungen in der Mitte abgeschnitten. Die Behebung dieses Problems führte zu einem weiteren Problem, bei dem Podman nie geschlossen wurde, aber die Podman-Betreuer haben beide Probleme behoben.
Fehler für Fehler
Es gab jedoch ein Problem, das uns von Anfang an gestört hatte – es führte dazu, dass wir die Volumes vor jedem Lauf entfernen mussten. Die Sache, die Ihnen niemand über Kompatibilität sagt, ist, dass Sie manchmal Bug-für-Bug-kompatibel sein müssen, um dies zu erreichen. Docker hat vor über fünf Jahren ein Problem darüber gemeldet, dass, wenn Sie darum bitten, ein bereits vorhandenes Volume zu erstellen, es "alles gut" zurückgibt und sich so verhält, als wäre nie etwas gewesen. Podman hingegen gab die richtige Fehlermeldung zurück (Betonung auf „war“, weil es sich jetzt genauso verhält wie Docker, zumindest im Kompatibilitätsmodus. Bug-for-Bug, oder?)
Nachdem diese großen Probleme aus dem Weg geräumt waren, tauchten einige kleinere Dinge auf, aber alles lief reibungslos, zumindest soweit wir es testen konnten.
[ Das API-Eigentümerhandbuch:7 Best Practices effektiver API-Programme ]
Abschluss
Also, wie steht es jetzt? Nun, alle Probleme, auf die wir mit Podman gestoßen sind, sind jetzt alle im Hauptzweig behoben, und wenn alles gut geht, werden sie Teil der bevorstehenden Version von Podman 2.2 sein. Das wird die erste Podman-Veröffentlichung sein, die sofort mit GitLab Runner ausgeführt werden kann, ohne dass es überhaupt weiß, dass es mit Podman kommuniziert. Das ist ein wirklich wichtiger Meilenstein für uns.