474 - Porqué cambié mi uso de Docker y otras preguntas

Algunas ideas para utilizar #Docker en #Linux o sin él, como init, los named volumes, el modo rootless y sobre la creación de imagen sin usuario root

1:25

-3:15

0.8x 1.0x 1.2x 1.4x 1.6x 1.8x 2.0x

1.0x

Mi uso de la tecnología de los contenedores ha ido variando con el paso del tiempo. Inicialmente solo utiliza las imágenes creadas por otros, posteriormente, pasé a crear mis propias imágenes, y así sucesivamente. También estuve utilizando durante un tiempo Podman en lugar de Docker, para ver las opciones y posibilidades que ofrecía cada uno de ellos. Y finalmente, después de consolidado el uso de Docker, he ido realizando diferentes variaciones con su uso, algunas, por los propios cambios de Docker con las versiones, y otros inspirados por mi propio aprendizaje y produndización en el conocimiento de Docker. Esto me ha llevado a preguntarme porqué cambié mi uso de Docker y otras preguntas.

Porqué cambié mi uso de Docker y otras preguntas

¿Porque Docker y no Podman?

Docker y Podman son dos tecnologías de contenedorización que tienen objetivos similares pero enfoques diferentes.

Docker es una plataforma de contenedores que permite a los desarrolladores empaquetar una aplicación con todas sus dependencias en un contenedor. Docker utiliza un enfoque cliente-servidor, lo que significa que se necesita un demonio de Docker en el sistema operativo host para administrar los contenedores. Docker es ampliamente utilizado y tiene una gran comunidad de usuarios y desarrolladores que crean y comparten imágenes de Docker para una variedad de aplicaciones.

Por otro lado, Podman es una herramienta de contenedorización que se centra en proporcionar una experiencia similar a Docker, pero sin la necesidad de un demonio en segundo plano. Podman utiliza un enfoque basado en procesos y no en demonios, lo que significa que los contenedores se ejecutan como procesos normales del sistema operativo, lo que reduce la complejidad y la superficie de ataque. Además, Podman se integra bien con herramientas de administración de contenedores existentes, como Kubernetes.

¿Porque utilizo init con Docker?

En Docker, init se refiere al proceso de inicialización dentro de un contenedor que se encarga de arrancar todos los demás procesos que se ejecutan dentro del contenedor.

En un sistema operativo normal, el proceso init es el primer proceso que se inicia cuando se arranca el sistema, y es responsable de iniciar todos los demás procesos necesarios para ejecutar el sistema. En un contenedor de Docker, el proceso init se ejecuta dentro del contenedor en lugar del proceso init del sistema operativo host.

El proceso init de Docker es responsable de configurar el entorno de ejecución del contenedor, como la asignación de recursos, la configuración de variables de entorno, la inicialización de redes y la ejecución de servicios adicionales necesarios dentro del contenedor. Es importante tener en cuenta que el proceso init de Docker solo se ejecuta si el contenedor se inicia con la opción --init.

Algunas ventajas de utilizar init, son las siguientes,

• Gestión de procesos: al utilizar la opción --init, se proporciona una gestión centralizada y coordinación de todos los procesos dentro del contenedor.
• Término adecuado de los procesos: el proceso init dentro del contenedor asegura que los procesos que se ejecutan dentro del contenedor se terminen adecuadamente y de forma segura en caso de una señal de interrupción o un error en el proceso.
• Mejora la seguridad: utilizando la opción --init, se reduce la posibilidad de ataques a través de la explotación de procesos huérfanos que no están gestionados por el proceso init dentro del contenedor.

Pero, no todos son ventajas, también existen algunos inconvenientes,

• Mayor tiempo de inicio: al utilizar la opción --init, se añade un proceso adicional al contenedor, lo que puede aumentar el tiempo de inicio del contenedor.
• Consumo de recursos: la opción --init utiliza un proceso adicional dentro del contenedor, lo que puede aumentar el consumo de recursos del contenedor.
• Incompatibilidad con algunos programas: algunos programas pueden no ser compatibles con el proceso init dentro del contenedor, lo que puede hacer que el proceso no se inicie correctamente.

¿Estoy usando rootless?

El modo «rootless» en Docker se refiere a la capacidad de ejecutar y administrar contenedores de Docker sin la necesidad de tener privilegios de root (superusuario) en el sistema operativo host. Esto significa que los usuarios no necesitan tener permisos de root para instalar y ejecutar Docker, lo que mejora la seguridad y reduce la superficie de ataque.

En el modo rootless de Docker, cada usuario tiene su propio espacio de nombres (namespaces) para los contenedores, lo que significa que los contenedores se ejecutan en un entorno aislado del sistema operativo host y de otros usuarios. Además, el modo rootless utiliza la tecnología UserNS de Linux para asignar identificadores de usuario únicos a los usuarios y contenedores, lo que mejora la seguridad al evitar conflictos de identificación.

El modo rootless presenta algunas ventajas, pero también inconvenientes respecto al uso normal. Así entre las ventajas cabe citar las siguientes,

• Mejora de la seguridad: al utilizar el modo rootless, se reduce la necesidad de privilegios de root en el sistema operativo host, lo que mejora la seguridad al limitar el acceso a los recursos del sistema operativo y reducir la superficie de ataque.
• Mayor portabilidad: el modo rootless permite que los contenedores se ejecuten en diferentes sistemas operativos y en la nube, lo que facilita la portabilidad de las aplicaciones y la implementación en diferentes entornos.
• Permite el uso de Docker en entornos donde los usuarios no tienen permisos de root: el modo rootless facilita el uso de Docker en entornos donde los usuarios no tienen permisos de root, como en algunos sistemas compartidos o en entornos de desarrollo.
• Fácil de configurar: la configuración del modo rootless es sencilla y no requiere configuraciones adicionales complicadas.

Respecto a los inconvenientes, cabría citar los siguientes, al menos,

• Limitaciones en algunas funcionalidades: algunas funcionalidades avanzadas de Docker, como el uso de dispositivos específicos o la gestión de redes avanzadas, pueden no estar disponibles en el modo rootless.
• Menor rendimiento: el modo rootless puede ser un poco más lento que el modo convencional, ya que cada usuario tiene su propio espacio de nombres (namespaces) y se utiliza la tecnología UserNS de Linux para asignar identificadores de usuario únicos a los usuarios y contenedores, lo que puede consumir más recursos del sistema.
• Dificultades en la configuración de red: la configuración de la red puede ser más complicada en el modo rootless, ya que los contenedores se ejecutan en un entorno aislado del sistema operativo host y de otros usuarios.

En resumen, el modo rootless de Docker proporciona una solución segura y eficaz para ejecutar y administrar contenedores de Docker sin la necesidad de tener privilegios de root en el sistema operativo host. Sin embargo, tiene algunas limitaciones en funcionalidades avanzadas y puede ser un poco más lento y complicado de configurar en algunos aspectos.

Sin embargo mi problema es mucho mas mundano que todo esto, simplemente se refiere a la distribución que estoy utilizando, Manjaro, y es que hasta el momento, no he sido capaz de configurarlo adecuadamente, y por esta razón sigo utilizando el modo habitual. Pero esto es algo temporal, hasta que lo consiga.

¿Cuando y porque he cambiado a los named volumes?

Los named volumes (volúmenes con nombre) son una funcionalidad de Docker que permite persistir datos generados por los contenedores en el sistema de archivos del host o en un volumen independiente que se puede compartir entre varios contenedores.

Los named volumes proporcionan una forma fácil y flexible de almacenar y compartir datos entre contenedores, lo que los hace especialmente útiles en entornos de producción y en aplicaciones que requieren almacenamiento de datos a largo plazo.

A diferencia de los «bind mounts» (montajes vinculados), que están vinculados a una ubicación específica en el sistema de archivos del host, los named volumes se crean y gestionan a través de Docker y se pueden utilizar en cualquier contenedor. Además, los named volumes son independientes del ciclo de vida de los contenedores y pueden sobrevivir incluso después de que se eliminen los contenedores que los utilizaron.

Los named volumes se pueden crear y gestionar mediante el uso de comandos de Docker, como docker volume create para crear un nuevo volumen y docker volume ls para listar todos los volúmenes disponibles. Los volúmenes se pueden especificar en la definición de un contenedor mediante la opción -v, seguida del nombre del volumen y la ruta dentro del contenedor donde se montará el volumen.

En resumen, los named volumes de Docker son una forma fácil y flexible de persistir y compartir datos entre contenedores, lo que los hace especialmente útiles en entornos de producción y en aplicaciones que requieren almacenamiento de datos a largo plazo.

¿Que ventajas e inconvenientes presenta utilizar los named volumes frente a los bind?

Existen varias ventajas e inconvenientes al utilizar named volumes en comparación con los bind mounts en Docker. Algunas de las ventajas de utilizar este tipo de volúmenes son las siguientes,

• Portabilidad: Los named volumes son independientes del sistema de archivos del host y, por lo tanto, son más portátiles entre diferentes sistemas operativos y plataformas de contenedores.
• Facilidad de gestión: Los named volumes son más fáciles de gestionar que los bind mounts porque Docker se encarga de crear, administrar y eliminar los volúmenes de manera automática.
• Persistencia de datos: Los named volumes persisten los datos incluso si el contenedor que los creó se elimina, lo que los hace especialmente útiles en entornos de producción donde los datos deben ser duraderos.

Pero no todo son ventajas, también existen algunos inconvenientes como los siguientes,

• Menor flexibilidad: Los named volumes son menos flexibles que los bind mounts porque solo pueden ser gestionados a través de comandos de Docker y no pueden ser vinculados a una ubicación específica en el sistema de archivos del host.
• Mayor complejidad: El uso de named volumes puede ser más complejo que el de los bind mounts en algunos casos, especialmente si se necesita personalizar la configuración del volumen para satisfacer requisitos específicos.
• Mayor consumo de recursos: Los named volumes pueden consumir más recursos del sistema que los bind mounts porque Docker debe gestionar y mantener los volúmenes de manera automática.

El inicio de mis imágenes

Otro de los cambios que he introducido es el inicio de mis imágenes. Todo ha ido evolucionando, y esto se ha debido en parte al uso de init, que he mencionado anteriormente, y por supuesto y también el uso de los named volumes. Hasta la fecha daba la opción de que se indicara tanto el id del usuario como del grupo. Sin embargo, para ello, utilizaba un script, que permitía acceder con cualquier usuario.

Sin embargo, aún así, esto obligaba a iniciar el contenedor como root, algo que no me terminaba de convencer. Ahora con el uso de estos volúmenes, no me tengo que preocupar por la gestión de permisos, y puedo iniciarlo perfectamente con el usuario destinado para ello.