Durante un tiempo, he estado trabajando en un proyecto que utiliza GitLab Runner con Docker como ejecutor. Dado que los corredores están alojados en CentOS 7, todo tenía sentido, hasta que empezamos a pensar en trasladarlo a CentOS 8 y nuestro mundo explotó.
Lo primero que pensamos fue que, dado que Podman es un reemplazo directo, esto 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 los contenedores, por lo que aunque pudiéramos hacer todo manualmente, aún no habíamos llegado.
Bien, volvamos a la mesa de dibujo, ¿qué tal si presentamos un problema de GitLab para que GitLab Runner implemente Podman como ejecutor? Resulta que el problema ya existía. La respuesta parafraseada fue:"No estamos aceptando nuevos albaceas, pero si lo escribe usted mismo, podemos ver si podemos aceptarlo". Mi conocimiento de las partes internas de GitLab Runner es peor que mi alemán, y todo lo que puedo decir es "Danke", ni siquiera la palabra completa.
No intentes esto en casa
Esta migración "simple" estaba siendo todo lo contrario, así que, como último recurso, pensamos que debía haber una forma de instalar Docker en CentOS8. Bueno, puedes leer algunos "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).
[ También te puede interesar: Integración mejorada de systemd con Podman 2.0 ]
Pasó un tiempo y nos mudamos temporalmente a otro proyecto que era más urgente. Aunque queríamos mover todo a CentOS 8, no había prisa.
Pero luego, hace unos meses, encontramos una publicación que decía que Podman estaba implementando una API REST compatible con Docker. Se sentía como si estuvieran leyendo nuestras mentes; esto es exactamente lo que necesitábamos. Esto debería ser fácil ahora. (Ves a dónde voy con esto, ¿verdad?)
Comenzamos a probar nuevamente cuando se lanzó Podman 2.0, todos felices y optimistas. GitLab Runner se estaba conectando al socket pero no podía 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 se había implementado, pero estaba en el árbol principal (que pronto será 2.1). Así que todavía teníamos una oportunidad.
Un backport pirateado
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 estaba fallando y no teníamos idea de por qué.
Afortunadamente, Podman 2.1 se lanzó con bastante rapidez y volvimos a la normalidad. Empezamos de nuevo, pero esta vez, adoptamos un enfoque diferente. Después de comentar un poco sobre el problema de Podman correspondiente, comenzamos a pasar el rato en #podman en IRC y a hacer preguntas sobre este problema. Recibimos algunas respuestas de los desarrolladores, ¡y ahí fue cuando las cosas se pusieron interesantes!
Configuramos un repositorio de prueba en GitLab, registramos un grupo de corredores y comenzamos a abordar cada problema, uno por uno. También configuramos una instancia de Docker para usar como referencia, 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.
Empezamos con un problema en el que el trabajo parecía funcionar, pero en realidad no estaba haciendo nada; Lo peor de todo es que no estaba registrando nada, por lo que primero tuvieron que arreglar los registros y luego volver al problema principal. Con eso fuera del camino, hubo otro problema con las entradas /dev, que también se resolvió. Después de unos días de pruebas, las cosas empezaban a verse realmente bien; podríamos ejecutar frases sencillas sin muchos problemas. Así que pensamos que habíamos terminado, pero en realidad todavía teníamos un poco de camino por recorrer.
Cuando pasamos a trabajos de ejecución más larga, se cortaron a la mitad debido a un problema en el seguimiento de la conexión inactiva. Arreglar eso llevó a otro problema con Podman que nunca se cerraba, pero los mantenedores de Podman abordaron ambos problemas.
Error por error
Sin embargo, había un problema que nos había estado molestando desde el principio:nos obligaba a eliminar los volúmenes antes de cada ejecución. Lo que nadie te dice sobre la compatibilidad es que, a veces, para lograr esto, tienes que ser compatible error por error. Docker tiene un problema presentado hace más de cinco años sobre el hecho de que cuando solicita crear un volumen que ya existe, devolverá "todo bien" y actuará como si nada hubiera pasado. Podman, por otro lado, estaba devolviendo el mensaje de error correcto (énfasis en "era" porque ahora actúa de la misma manera que Docker, al menos en el modo de compatibilidad. Error por error, ¿verdad?)
Una vez resueltos esos problemas importantes, aparecieron algunas cosas menores, pero todo funcionaba sin problemas, al menos hasta donde pudimos probar.
[ El manual del propietario de API:7 prácticas recomendadas para programas de API efectivos ]
Conclusión
Entonces, ¿cómo están las cosas ahora? Bueno, todos los problemas que encontramos con Podman ahora tienen soluciones en la rama principal y, si todo sale bien, serán parte del próximo lanzamiento de Podman 2.2. Eso marcará el primer lanzamiento de Podman que puede ejecutarse con GitLab Runner desde el primer momento, sin que siquiera sepa que está hablando con Podman. Ese es un hito realmente importante para nosotros.