21 de marzo de 2015

La revolución de Docker

El otro día hablaba de Snappy, el nuevo sistema de paquetes de Ubuntu. La verdad es que este nuevo sistema forma parte de toda una sorprendente ola-moda de virtualización a nivel de sistema de operativo, generalmente de mano de Docker, un software que en muy poco tiempo se ha hecho omnipresente en todas las fiestas. ¿Por qué demonios de repente la virtualización a nivel de sistema operativo de mano de Docker está tan de moda?

En principio, la virtualización a nivel de sistema operativo no es demasiado nueva. Durante muchos años, se ha oído a FreeBSD presumir de sus jails, y a OpenSolaris de sus zones. En el caso de FreeBSD, sus jaulas existen desde al menos FreeBSD 4.0, publicado en el año 2000, y durante muchos años, esa característica ha sido una de las razones por las que la gente usaba FreeBSD. Linux carecía de soporte de algo equivalente, y aunque existían parches extraoficiales de Linux-VServer desde 2001, sólo atraía la atención de casos particulares: La gente no huía masivamente de Linux por no tener estas capacidades integradas.

Con el tiempo -más de una década- el Linux oficial ha ido añadiendo diversos espacios de nombres, que son las columnas que permiten implementar este tipo de virtualización. Pero incluso cuando se implementó, tampoco parece que se le diera más importancia de la que se daba anteriormente a VServer y OpenVZ. Hasta que llegó Docker.

Docker. Docker por un lado, Docker por otro, Docker para todo y en todos sitios. Si leen sitios de noticias sobre software libre o programación ya se habrán acostumbrado a (y quizás cansado de) leer noticias relacionadas con Docker. Y es que Docker se ha extendido a gran velocidad. Su código fuente fue publicado en Marzo de 2013. Dos años después, ya es una plataforma soportada en Amazon EC2, Google Cloud y Microsoft Azure. La compañía líder en Linux, Red Hat, anunció un proyecto específico para Docker ya en Abril de 2014, "Atomic Host", y la primera versión estable se publicó a principios de este mes. Y nada menos que Microsoft ya ha anunciado que va a añadir soporte de Docker en la próxima versión de Windows Server. También VMware, que en principio podría parecer un rival, se apunta a Docker.

A un software que tenga la capacidad de alcanzar semejante estatus en tan sólo dos años no hay más remedio que describirlo como revolucionario. Y si en dos años ha tenido el efecto que ha tenido, cabe esperar que en los próximos años la expansión de Docker tenga muchas ramificaciones. Pero eso no responde a la pregunta de ¿por qué de repente hay tanta moda de virtualización de sistema operativo?

En realidad, no creo que haya un gran interés en esta clase de virtualización. Lo que hace a Docker interesante no es tanto su gestión de contenedores, habilidad en la que Docker no es superior a otras herramientas, sino su capacidad para facilitar la gestión de la implementación de "aplicaciones". El registro público de imágenes es una App Store más. No importa tanto el tipo de virtualización sobre el que se ejecuta una imagen (tal y como prueba el hecho de que Microsoft y VMware quieran portar Docker a sus plataformas), lo que importa es poder acceder a la App Store de turno. Del mismo modo que lo que hace relevante a un teléfono hoy es acceder a las tienda de aplicaciones de Android o iOS, existe la posibilidad de que estemos avanzando hacia una situación en la que un sistema que no tenga acceso a la "tienda de aplicaciones Docker", si bien estaría muy lejos de ser un sistema inutil, quedaría marginado por no poder acceder a las aplicaciones de moda.

La revolución de Docker no sería por tanto "la revolución de Docker", sino un capítulo más de la revolución de las tiendas de aplicaciones.

Por otro lado, esto no haría más que reafirmar la tendencia de cambio hacia un modelo en el que los repositorios Linux tradicionales quedan obsoletos como sistema para distribuir aplicaciones, y por tanto ponen en duda la esencia de muchas grandes distribuciones Linux. Ubuntu, con su Snappy, es de las primeras grandes distribuciones en prestar atención a este fenómeno, pero está por ver que otras hagan lo mismo. Será interesante observar lo que pase en los próximos años.

24 de febrero de 2015

KDE Frameworks 5: un ejemplo

Hace 9 días escribí un post sobre KDE Frameworks 5, hoy encontré este buen ejemplo de cómo una aplicación Qt puede aprovechar una librería de KDE Frameworks (KIO) con facilidad.

22 de febrero de 2015

Snappy Ubuntu Core, una manera diferente de gestionar paquetes

Ubuntu anunció hace un tiempo otra versión de Ubuntu: Snappy Ubuntu Core, una especie de equivalente al sistema base de Debian que presenta un nuevo sistema de gestión de software. Su objetivo inicial era presentarlo como plataforma para la nube, más concretamente como plataforma para usar el célebre Docker y así reaccionar frente a CoreOS, que se ha puesto de moda como distro favorita para usar Docker.

Hace alrededor de un mes, Canonical anunció que también promocionarían Snappy Ubuntu Core para la "internet de las cosas" (horripilante expresión que, como ya habrán notado, está de moda), es decir, para sistemas del estilo de Raspberry Pi. La reducción del tamaño, consumo energético y coste de estos sistemas hacen posible empotrar estos sistemas en casi cualquier cosa, y como la flexibilidad de un sistema operativo complejo es infinitamente mayor que el firmware de los circuitos integrados, se prevé que en pocos años empecemos a encontrar estos sistemas en todos lados.

Lo diferente e interesante de Ubuntu Snappy, desde el punto de vista del ecosistema linuxero, es que se deshace por completo del sistema de gestión de paquetes APT. Con toda la literalidad de la expresión. El sistema de gestión de software es el corazón de la identidad de una distro, por lo que estamos ante un cambio importantísimo, y para mi sorpresa muy poco comentado. El cambio es hacia Snappy, un nuevo sistema de gestión de paquetes muy curioso. Snappy es, en concepto, parece ser una imitación y evolución del "updateservicectl" de CoreOS. Técnicamente, es una confluencia de varias tendencias tecnológicas, desde APT al aislamiento de aplicaciones de los teléfonos.


Snappy

Al igual que APT, Snappy (invocado mediante el comando "snappy") consta de repositorios de software. A diferencia de APT, los paquetes no son tal como solemos concebir los paquetes. Existe un paquete llamado "ubuntu-core" que contiene, literalmente, todo el sistema de Snappy Ubuntu Core. Todo. Nada de cientos de paquetes separados, sólo uno para todo el sistema base (es decir, la dirección opuesta a la fisión en infinidad de paquetes que vemos en Debian). Tras el sistema base, existen los "frameworks". Uno de los frameworks posibles es "docker", y es fácil imaginar a "gtk", "qt" o "kde" como ejemplos de otros frameworks que se añadan en el futuro. La finalidad de los frameworks es extender el sistema base.

Luego tenemos las aplicaciones. La diferencia fundamental entre frameworks y aplicaciones es que las aplicaciones están aisladas entre si mediante virtualización con contenedores, y tienen restringido el acceso al sistema de archivos, a la red, a listados de procesos que muestren otros procesos. Una de las consecuencias inmediatas de esta organización es que desaparece el concepto de dependencias al que estamos acostumbrados. Nada de cientos, miles de paquetes, cada uno con una librería, cada uno con su versión, cada uno con sub-dependencias. En Snappy Ubuntu Core, el paquete de sistema y los paquetes de framework son sólo un paquete cada uno, y las aplicaciones sólo pueden depender de frameworks.

La última gran diferencia de este sistema es el carácter transaccional y reversible de las actualizaciones, especialmente las del sistema. Gracias a un extraño sistema con dos particiones, copiado de CoreOS, las actualizaciones de paquetes del sistema se hacen a la partición que no se está utilizando en ese momento, y al arrancar se utiliza la partición con el sistema nuevo. Con "snappy rollback" se puede volver a utilizar la versión anterior del sistema. En el caso de las aplicaciones, se instalan varias aplicaciones en /app/nombredelaapp/1.2.3, y hay un enlace simbólico en /app/nombredelaapp/current a la versión que se desea utilizar.

Por último, destacar el enrevesado proceso de ensamblado de las particiones al arrancar. Las particiones que contienen el sistema son de sólo lectura, no se permite su modificación. Eso hace que sea necesario dedicar una partición extra en la que se almacenan las modificaciones o añadidos a /var o /etc. Es también en esa partición donde se instalan las aplicaciones, y donde se crean los directorios de usuario. Naturalmente, esos juegos de particiones no resultan en un sistema funcional por sí solos,  de ahí que al arrancar el sistema tenga que hacer un total de 28 montajes bind de la partición modificable a varias rutas en /etc y /var del sistema principal no modificable.



Consecuencias de Snappy

Snappy es muy interesante porque logra mezclar la muy razonable decisión de ejecutar todas las aplicaciones en entornos aislados, con los repositorios tradicionales linuxeros, al mismo tiempo que añade funciones que deberían ser estándar, y no meras opciones, en cualquier sistema de paquetes moderno (revertido de actualizaciones) y elimina aspectos de los repositorios linuxeros (miles de paquetes y laberintos de dependencias) que quizás deberíamos empezar a cuestionar.

El dilema que puede surgir frente a snappy es que Snappy puede considerarse como algo bueno. Y no sólo bueno: podría incluso considerarse una evolución de los sistemas de paquetes en Linux, algo superior. Y si Snappy es superior, y logra ser mejor que los sistemas de paquetes tradicionales, la evolución lógica sería que Canonical llegase a sustituir en un futuro (futuro no inmediato) a APT por Snappy, con consecuencias impredecibles. Es difícil prever qué pasará exactamente en el futuro (porque hay varios proyectos compitiendo por hacer lo mismo, como Gnome Apps), pero existe la posibilidad de que haya verdaderas revoluciones en las herramientas de gestión de software en el mundo Linux en los próximos años. Snappy bien puede ser sólo el comienzo de una nueva ola.