systemd es desde hace tiempo el init estándar de GNU/Linux, o al menos es el utilizado por defecto en la mayoría de las grandes distribuciones. Sus detractores lo acusan de “tragar” muchos componentes y de no ser portable a otros sistemas, pero es que systemd no pretende solo ser un init, sino todo un framework de sistema capaz de sacar lo mejor de GNU/Linux.
El desarrollador principal y creador de systemd es Lennart Poettering, quien desde el principio ha defendido con ahínco las ventajas de su creación frente a productos de la competencia, como Upstart. Hoy os presentamos una característica que puede resultar bastante interesante, porque si algo tiene systemd es que quiere ser capar de hacer muchas cosas además de encargase de la gestión de los servicios. Hace un mes fue introducida en el repositorio de GitHub una nueva característica llamada portablectl, que hace referencia a Servicios Portables (Portable Services), una funcionalidad que puede recordar un poco a los contenedores de software, tema que en MuyLinux estamos tratando con mucha frecuencia en los últimos meses. Estas son sus características según la documentación:
Esta versión de systemd incluye una implementación en fase previa del concepto de Servicios Portables. Los Servicios Portables son supuestamente una mejora incremental sobre el sistema tradicional de servicio, haciendo que dos facetas específicas de la gestión de los contenedores estén disponibles para los servicios del sistema más fácilmente. Siendo más específicos:
- El empaquetado de las aplicaciones. Por ejemplo, el empaquetado de múltiples servicios, sus binarios y todas las dependencias en una única imagen, y ejecutarlas directamente desde ahí.
- Políticas de seguridad predeterminadas más estrictas. Por ejemplo, aislamiento de las aplicaciones.
La herramienta primaria para hacer de interfaz con los Servicios Portables es el nuevo programa “portablectl”. Actualmente está disponible en «/usr/lib/systemd/portablectl» y todavía no está considerado como una parte oficialmente soportada por systemd, ya que después de todo está en fase previa (será incluido en systemd 239 en ese estado).
Los Servicios Portables no traen nada nuevo de forma inherente a la tabla. Todo lo que hacen es poner juntos conceptos conocidos de una manera un poco más agradable para cubrir un conjunto específico de casos de uso de una mejor manera.
¿Qué es un Servicio Portable?
Un servicio portable es, en última instancia, solo OS Tree, ya sea dentro de un árbol de directorios o dentro de una imagen de disco sin formato que contiene un sistema de archivos Linux. Este árbol es llamado “imagen”. Puede ser “adjuntado” o “separado” del sistema. Cuando se adjunta unidades específicas de systemd desde la imagen se vuelven disponibles en el sistema host, luego se comporta exactamente igual que los servicios del sistema instalados localmente. Cuando se separan, estas unidades son eliminadas de nuevo del host, no dejando artefactos alrededor (excepto posiblemente mensajes de que podrían estar registrados).
La imagen/OS Tree puede ser creada con cualquier herramienta que se elija. Por ejemplo, se puede usar ‘dnf –installroot=’ si se quiere o ‘debootstrap’, el formato de la imagen es totalmente genérico, y no tiene que llevar ningún metadato específico además de qué imágenes de distribución se cargan. O para decirlo de forma diferente: el formato de la imagen no define ningún metadato nuevo como unidad de ficheros y los directorios de OS Tree o las imágenes de disco son suficientes, y están disponibles universalmente en estos días. Una herramienta particularmente buena para crear imágenes adaptadas es mkosi, pero existen otras muchas que también lo hacen.
Si se quiere, los Servicios Portables son una mejor manera de manejar entornos chroot(), con mejores seguridad, herramientas y comportamiento.
¿Dónde está la diferencia con un contenedor?
“Contenedor” es un término muy vago, después de todo es usado para contenedores systemd-nspawn/LXC-type OS, para el microservicio de contenedores Docker/rkt-like y hasta ciertos entornos de ejecución de máquinas virtuales “ligeras”.
El concepto de Servicio Portable, el última instancia, no proporcionará un entorno totalmente aislado a la carga útil, como generalmente intentan los contenedores. En su lugar son desde el principio más como servicios regulares del sistema, que pueden ser controlados con las mismas herramientas, son expuestos de la misma manera en toda la infraestructura y así sucesivamente. La principal diferencia es el uso de un directorio raíz diferente al del resto del sistema. Por lo tanto, la intención no es ejecutar código en un mundo diferente y aislado del host, como harían los contenedores, sino ejecutar en el mismo mundo, pero con un acceso más restringido a los controles sobre lo que el servicio puede ver y hacer.
Como un punto de diferenciación, como los programas que son ejecutados como servicios portables, son más parecidos a servicios regulares del sistema, no se ejecutarán como PID 1 (como se haría en Docker), sino como un proceso normal. Un corolario de eso es que no están supuestos para manejar cualquier cosa en su propio entorno (como en la red) como la ejecución de un entorno que mayormente es compartido con el resto del sistema.
El foco principal de caso de uso de los Servicios Portables es extender el sistema host con extensiones encapsuladas, pero ofrece casi integración total con el resto del sistema, aunque posiblemente restringido por botones de seguridad efectivos. Este enfoque incluye extensiones del sistema que a veces se denominan como contenedores “súper privilegiados”.
Hay que tener en cuenta que los servicios portables solo están disponibles para los servicios del sistema, no para los servicios del usuario. Por ejemplo, la funcionalidad no puede ser usada para las cosas en las que bubblewrap/flatpak está enfocado.
