La historia de una API: GitLab Runner y Podman

Durante bastante tiempo, he estado trabajando en un proyecto que usa GitLab Runner con Docker como corredor. Dado que los corredores están alojados en CentOS 7, todo tenía sentido, hasta que comenzamos a considerar moverlo a CentOS 8 y nuestro mundo explotó.

Lo primero que pensamos fue que, dado que Podman es un reemplazo, debería ser fácil (ustedes mismos pueden imaginar la veracidad de esa afirmación). La verdad era que Podman no tenía la API que usaba GitLab Runner para administrar contenedores, así que, aunque podíamos hacer todo manualmente, todavía no estábamos allí.

Bien, volvamos a la mesa de dibujo, ¿qué le parece presentar un problema de GitLab para GitLab Runner para implementar Podman como ejecutor? Resulta que el problema ya existía. La respuesta parafraseada fue: "No aceptamos nuevos albaceas, pero si lo escribe usted mismo, podemos ver si podemos aceptarlo". Mi conocimiento del funcionamiento interno de GitLab Runner es peor que mi alemán, y todo lo que puedo decir es "Danke", ni siquiera la palabra completa.

Índice

No intente esto en casa

Esta migración "simple" fue todo menos, como último recurso, pensamos, debe haber alguna forma de instalar Docker en CentOS8. Bueno, puedes leer "tutoriales" que lo hacen, pero te dan ganas de sacarte los ojos, así que esa no era una opción. (En serio, no intentes esto en casa).

Pasó el tiempo y nos trasladamos temporalmente a otro proyecto más urgente. Aunque queríamos mover todo a CentOS 8, no había prisa.

Pero hace unos meses encontramos un artículo que decía que Podman está implementando una API REST compatible con Docker. Era como si nos estuvieran leyendo la mente; esto es exactamente lo que necesitábamos. Debería ser fácil ahora. (Ves a dónde voy, ¿no?)

Comenzamos a probar nuevamente cuando se lanzó Podman 2.0, todos felices y optimistas. GitLab Runner se conectó al socket pero no pudo crear volúmenes. Luego, leímos las notas de la versión con más cuidado, y decían que el punto final para los volúmenes aún no estaba implementado, pero estaba en el árbol principal (que pronto será 2.1). Así que todavía teníamos una oportunidad.

Un backport hackeado

Pasaron unos días; Hicimos un backport pirateado del punto final de volúmenes a 2.0 y también probamos la rama principal, pero todo falló y no estábamos seguros de por qué.

Afortunadamente, Podman 2.1 se lanzó con bastante rapidez y volvimos al camino correcto. Lo hicimos de nuevo, pero esta vez adoptamos un enfoque diferente. Después de comentar un poco sobre el corresponsal Problema del podman, comenzamos a pasar el rato en #podman en IRC y preguntamos sobre este problema. Hemos recibido algunas respuestas de los desarrolladores, ¡y aquí es donde las cosas se pusieron interesantes!

Configuramos un repositorio de prueba en GitLab, registramos un grupo de ejecutores y comenzamos a solucionar cada problema, uno por uno. También configuramos una instancia de Docker para usar como línea de base, pero monitoreamos toda su comunicación con GitLab Runner usando socat- de esa manera podíamos ver exactamente lo que estaba pasando y lo que necesitábamos combinar.

Comenzamos con un problema en el que el trabajo parecía estar funcionando, pero en realidad no estaba haciendo nada; Lo peor de todo fue que no estaba grabando nada, por lo que primero tuvieron que arreglar los registros y luego volver al problema principal. Una vez que se solucionó, hubo otro problema con las entradas / dev, que también se solucionó. Después de unos días de pruebas, las cosas empezaban a verse realmente bien; podríamos ejecutar líneas simples sin demasiados problemas. Así que pensamos que habíamos terminado, pero todavía teníamos un largo camino por recorrer.

Cuando pasamos a tareas más largas, se cortaron a la mitad debido a un problema con el seguimiento de las conexiones inactivas. La solución que condujo a otro problema con Podman nunca se apagó, pero los mantenedores de Podman solucionaron ambos problemas.

bicho por bicho

Sin embargo, hubo un problema que nos molestó desde el principio: requería que elimináramos los volúmenes antes de cada ejecución. Lo que nadie te dice de la compatibilidad es que a veces, para conseguirla, tienes que ser compatible bug a bug. Docker tiene un problema presentado hace más de cinco años que cuando solicite crear un volumen que ya existe, devolverá "todo está bien" y actuará como si nada hubiera pasado. Podman, d'autre part, renvoyait le message d'erreur correct (l'accent est mis sur « était » car il agit maintenant de la même manière que Docker, au moins en mode compatible. Bug-for-bug, n'est -No es ?)

Después de que se resolvieron estos problemas importantes, surgieron cosas menores, pero todo funcionaba bien, al menos hasta donde pudimos probar.

Envoltura

Entonces, ¿cómo van las cosas ahora? Bueno, todos los problemas que tuvimos con Podman ahora tienen soluciones en la rama principal y, si todo va bien, serán parte de la próxima versión de Podman 2.2. Esto marcará la primera versión de Podman que puede funcionar con GitLab Runner desde el primer momento, sin que él ni siquiera sepa que está hablando con Podman. Este es realmente un paso importante para nosotros.

Artículos de interés

Subir