539 - Volúmenes Docker y el tiempo

¿Porque prefiero los volúmenes #Docker en #Linux del tipo named a los bind? Scripts para lidiar con este tipo de volúmenes, así como las zonas horarias

1:25

-3:15

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

1.0x

Te quiero hablar de dos asuntos que seguro que en mas de una ocasión te han dado mas de un quebradero de cabeza. Por un lado los volúmenes, y por otro lado el tiempo. Y es que tanto los volúmenes como el tiempo, se pueden comportar de forma distinta, dependiendo de en que lado te encuentres. Si estás en el lado del host o estás en el lado del contenedor. Y esta diferencia de comportamiento, como te decía, te pueden acarrear algún que otro disgusto, como el que te voy a contar hoy. Así, quiero hablarte sobre volúmenes Docker y el tiempo. Y me refiero a la escala temporal, y no a la situación meteorológica.

Algo que seguro que en mas de una ocasión te ha dado dolores de cabeza son los permisos en Linux. Pero todavía es mas doloroso si cabe en Docker. Lidiar con los permisos en Docker, es un dolor mayor. Esto es algo que he sufrido durante bastante tiempo, mientras enlazaba los directorios o archivos del host con los directorios o archivos del contenedor. Sin embargo, después de dale muchas vueltas a la cabeza.

Volúmenes Docker y el tiempo

Volúmenes bind o mapeados y volúmenes named

Uno de los problemas que te puedes encontrar con Docker son los volúmenes, y mas en concreto los permisos con los volúmenes. En ocasiones, para levantar un determinado servicio es necesario mapear un archivo o un directorio del host en el contenedor.

Es probable que en alguna ocasión te hayas encontrado con el echo de que en lugar de que en lugar de mapear contra un archivo, se ha creado un directorio. Esto, es porque previamente no habías creado el archivo.

En otras ocasiones, lo que puede ser que te haya sucedido es que el contenedor, no se termina de levantar porque el directorio o el archivo mapeado, no tiene los permisos adecuados. ¿Como resolver todo esto?.

Hoy te puedo decir que esto a mi no me pasa. Hace ya algún tiempo decidí abandonar los volúmenes bind o mapeados y utilizar solo los volúmenes named. Esto, nos evita el problema de los permisos, pero tiene el problema de que no puedes mapear archivos de forma directa, y por otro lado pierdes el acceso directo a esos archivos.

La realidad es que no pierdes el acceso, lo que si es que no lo tienes de una forma tan directa. Pero por otro lado, sigues las recomendaciones de Docker a la hora de trabajar con volúmenes.

La solución unos pocos scripts

Para resolver este problema de acceso, he utilizado dos técnicas. La primera de las técnicas es utilizar Filebrowser y mapear los directorios de configuración a un volumen de Filebrowser que puedo editar directamente desde este increíble servicio.

La otra solución es con unos sencillos scripts que me permitan realizar determinadas operaciones con esos volúmenes.

Así, he creado los siguientes scripts que puedes encontrar en un repositorio en GitHub,

• dcat. Este primer script me permite realizar un cat de un archivo que se encuentre en un volumen. Solo tengo que pasar como parámetro algo similar a volumen:/ruta. Donde, como te puedes imaginar, volumen es el nombre del volumen y /ruta, es la ruta hasta el archivo.
• dcp. Este es un script que me permite copiar tanto del host al volumen como al revés. El script sabe de donde a donde copia simplemente por los :. Así, es sencillo realizar cualquier tipo de estas operaciones. Aquí, el único inconveniente que nos podemos encontrar es con los permisos. Esto es algo que hay que tener en cuenta. Y no solo los permisos, sino también el propietario de los archivos.
• dls, es el script que implementé para listar archivos dentro de la ruta de un volumen.
• dmnt, me permite entrar dentro de un volumen y realizar todas las operaciones que quiera, en tanto en cuento, me encuentro trabajando como root, en el interior de ese contenedor.
• drm, este script es el que me permite borrar tanto archivos como directorios en el interior de un contenedor. De nuevo, puedo borrar cualquier cosa, en tanto en cuanto, lo estoy haciendo como root.

Algún detalle sobre estos scripts

Si que quería mencionarte algunos detalles sobre estos scripts, en lo que a su implementación se refiere.

Actualmente estoy utilizando la imagen busybox para realizar todas las operaciones, pero, no tengo claro, que esto siga así, o utilice finalmente una Alpine tuneado. Me refiero a tuneado por añadir algunas herramientas adicionales que me faciliten este tipo de operaciones. Me refiero a herramientas como rigpgrep, bat, fd y similares.

También estoy pensando si sería interesante tener en su interior vim o neovim, aunque fuera una versión sencilla.

Todo esto es algo que ando pensando, porque la solución del acceso de los volúmenes, me parece muy interesante.

El tiempo en el interior de un contenedor

Hace algún tiempo implementé un servicio tipo cron que llamé cronirs. Esto lo he montado en un Docker, de forma que lo utilizo para llamar vía API a otros contenedores de forma sencilla.

Hasta la fecha, todo había funcionado mas o menos bien. Y digo esto, porque tal y como tenía implementada la herramienta, siempre funcionaba en UTC. Hasta hace poco, que en España se cambió el horario de a invierno, y se produjo el desastre.

Así que decidí modificar este comportamiento de la herramienta. La cuestión, es que era necesario establecer la zona horaria dentro del contenedor. ¿Como hacerlo?

Para el caso de Alpine Linux, la solución pasa por instalar el paquete tzdata, y por supuesto añadir una variable de entorno indicando la zona horaria en la que me encuentro. Simplemente, tengo que pasar,

TZ=Europe/Madrid

Esto por supuesto para mi caso. En tu caso, tendrás que utilizar la zona horaria que necesites.

Esto además tiene su gracia, porque estoy utilizando un contenedor que está en un VPS en un DataCenter de Alemania. Y sin embargo, dentro del contenedor, la zona horaria es completamente distinta. Esta es la magia de los contenedores.

También he aprovechado para cambiar el log de cronirs, y que me muestre la hora en la zona horaria que le he indicado, lo que me facilita sensiblemente el trabajo a la hora de encontrar algún error.