En 2005, Linus Torvalds (el creador de Linux) se tomó unas semanas para trabajar en un sistema de control de versiones que pudiera reemplazar a BitKeeper, que por razones políticas se había vuelto imposible seguir usando (era propietario, no software libre como Linux mismo).
Ahí inició la historia de Git, el sistema de control de versiones más existoso que jamás haya existido, bajo cualquier métrica que uno se interese en tratar de medirlo. Como programador, Git es de las herramientas más poderosas que yo haya usado; también es de las menos amigables de usar, pero eso es otra historia. Mis documentos están en control de versiones desde 2004, usando Subversion; poco después de que Git tomara control del universo los moví al mismo y así los he tenido durante años. Es de esta manera que mantengo el trabajo que hago en mi oficina, mi casa y mi laptop sincronizado.
Cuando entré como profesor de tiempo completo a la Facultad de Ciencias y me ofrecieron como voluntario para coordinar el curso propedéutico que le damos a los estudiantes de nuevo ingreso, de las cosas que decidí que quería hacer era darles Git en dicho curso. De verdad, como programador es de las herramientas más útiles que existen; es por eso que sitios como GitHub son tan exitosos (y por lo que Microsoft los compró por $7,500,000,000 USD). Ofrecerle dicha herramienta a nuestros estudiantes es de lo mejor que se nos ha ocurrido, me parece.
Por el mismo motivo, mis cursos en la Facultad utilizan Git para darle a los estudiantes sus prácticas; y de hecho los estudiantes entregan sus prácticas con archivos diferenciales (diff) contra la rama maestra.
Para poder hacer todo esto, me facilitaba la vida tener un sistema parecido a GitHub, pero que yo pudiera controlar; que es básicamente la razón de GitLab. Después de no pocos quebraderos de cabeza, instalé una instancia de GitLab en Aztlán, donde tengo mis cursos, mis proyectos personales e incluso algunos proyectos grupales con otros profesores de la Facultad. Como yo controlo por completo el sistema, puedo tener grupos y proyectos públicos o privados, como yo quiera.
GitLab es una maravilla, sin duda alguna. Pero también es una pesadilla mantenerlo actualizado, especialmente en una distribución tan anárquica como lo es Gento, que es lo que uso en todas mis computadoras. Gentoo en particular es terrible para mantener aplicaciones web; es por esto que mi instancia de WordPress la he mantenido a pie toda la vida.
Como sea; GitLab es una pesadilla de mantener actualizado porque está escrito sobre Ruby on Rails, que como su nombre indica utiliza Ruby, que usa “gemas” para mantener sus dependencias. El problema es que es relativamente sencillo que una gema de Ruby ya esté instalada en el sistema y que las versiones necesarias no concuerden, lo que resulta en que todo se eche a perder. Si actualicé 4 veces mi instancia de GitLab en Aztlán en el par de años que la he tenido, son muchas. Esto me molestaba bastante, porque soy muy paranoico con tener Aztlán actualizada y segura; GitLab lo hacía bastante más difícil de lo normal.
Paralelamente a esto, en el último par de años me he estado enamorando de Flatpak. No sólo me ha permitido utilizar versiones actualizadas de varios programas que utilizo (Inkscape, GNOME Builder, Pitivi), porque luego Gentoo se tarda en estabilizar dichas versiones; también me ha permitido por fin hacer fácilmente algo que siempre había querido hacer en Linux: jugar juegos AAA de manera legal y sencilla.
Gracias a Flatpak, pude instalar sin ningún tipo de problemas Steam y ahora puedo jugar Cities: Skylines en mi computadora sin tener que iniciar Windows. De hecho, jala mejor que en Windows; está increíble y no tengo que preocuparme de dependencias y cosas así, porque justo Flatpak utilizar contenedores para aislar los procesos de sus aplicaciones.
Toda la idea de los contenedores es una maravilla, evolucionando la tecnología de máquinas virtuales que se popularizó a inicios de siglo. Un contenedor no es una máquina virtual; como su nombre indica, sólo contiene un ambiente de trabajo, compartiendo el mismo kernel con el que corra la computadora anfitriona del contenedor. Esto se traduce en casi todas las ventajas de las máquinas virtuales, pero corriendo a una velocidad más que decente. Y pues justamente Flatpak le robó la idea a Docker, que viene utilizando contenedores en servidores desde hace múltiples años.
Lento como soy, no se me había ocurrido que podía correr GitLab en una imagen de Docker, así que hace unos días decidí buscar si era posible. No sólo es posible; el mismo proyecto de GitLab ofrece imágenes para Docker fácilmente utilizables.
Ahora, si quisiera correr GitLab como aplicación única de un dominio (por ejemplo, https://gitlab.fciencias.unam.mx), la imagen jalaría casi sin necesidad de hacerle ningún cambio. Por supuesto, no es mi caso donde tiene que correr desde un URL relativo (justo https://aztlan.fciencias.unam.mx/gitlab); pero más grave que esto, es que yo ya tengo un servidor de HTTP (Apache), que además sirve a este blog y otras aplicaciones Web.
Esto resultó en que tuviera que hacerle trutrú al contenedor de GitLab, que por suerte lo permite, para poder correrlo en un URL relativo y además montarse de mi instancia de Apache. Me llevó varios días estarle probando a las opciones del contenedor, pero al final lo logré y entonces me puse a ver cómo migrar mi instancia de GitLab a la del contenedor; dícese la base de datos, los repositorios, etc. Eso también fue un relajo, porque originalmente tenía mi instancia de GitLab con MySQL (es lo que usa WordPress para el Pensadero) y el contenedor usa PostgreSQL; así que tuve que primero migrar de MySQL a PostgreSQL 10; luego tratar de migrar de mi instancia al contenedor; luego echarlo para atrás usando mis respaldos porque el contenedor usa PostgreSQL 9; volver a migrar de MySQL pero ahora a PostgreSQL 9; migrar al contenedor; y echarme un mezcal porque ya estaba harto de todo el proceso.
Sin embargo me parece que valió la pena; he actualizado como 10 veces el contenedor desde que migré mi instancia de GitLab al mismo, el proceso es casi trivial (aunque me parece que podría ser todavía más fácil). En cuanto mi instancia me dice que debo actualizar, detengo el servicio (que envuelvo en una unidad de systemd, usando docker-compose para controlarlo), borro el viejo contenedor e imagen, bajo la nueva imagen, recreo el contendor y reinicio el servicio; todo funciona sin ningún problema.
Me gustó tanto que estoy viendo qué otras cosas puedo mover a contenedores; por ejemplo mi instancia de WordPress para el blog; o mi lector de RSS (que bien podría cambiar, porque no me gusta tanto el que uso). Ya veré, en mi extensísimo tiempo libre.
Pero esta nueva manera de manejar aplicaciones, tanto en el escritorio como en servidores, me parece que es sin duda alguna el futuro para aplicaciones en Linux. Si siguen mejorando (en particular con Flatpak para aplicaciones de escritorio), es posible que Linux ahora sí comience a ser usado por muchísimas más personas; aunque la verdad ya han habido múltiples esquemas que se supone eso iban a permitir.
