En uno de los sitios en los que estuve trabajando, tenía un compañero un poco desordenado. Cada vez que hacía un script que necesitaba guardar la salida en un fichero temporal, reutilizaba los nombres o los acumulaba infinitamente en una carpeta temporal, cuyo nombre dependía de la inspiración del momento.
Tras aprender más de systemd y su modo de usuario, vi infinitas posibilidades para los servicios de usuario. Dependiendo del tipo de tarea en la que iba a trabajar, parecía lógico tener un subconjunto de servicios ejecutando en segundo plano. ¿Había alguna manera de levantar varios con un solo comando?
Una de las funciones que prometía systemd cuando apareció era la de reemplazar las utilidades tipo cron. Esto era bueno porque iba a estandarizar un servicio que no lo estaba (aunque las diferentes distribuciones lo daban por hecho); esta idea se quedó en el tintero y es hora de sacarla.
Es bastante habitual que en mi tiempo de ocio me dedique a trabajar con HTML y CSS por interés personal. A veces puedo hacer pruebas de concepto estáticas y otras puedo utilizar un generador estático; en todos los casos necesito de un servidor web levantado solo para mi sesión personal.
Tengo un usuario que es muy cómodo; él solo consiguió una excepción de seguridad para poder abrir el puerto TCP de docker de un servidor concreto, para chafardear cómodamente desde su máquina. A pesar de mis reticencias, cumplí con lo que se me pedía, y no tardamos mucho en lamentarlo.
Muchas veces he utilizado los volúmenes de Docker para “inyectar” un fichero de configuración que sobreescriba a otro. Cuando utilizamos Docker Swarm suele ser un problema distribuir estos ficheros de configuración; además, a veces necesitamos que se transmitan encriptados para que no los puedan ver los contenedores hermanos, por seguridad.
Una petición muy habitual que recibo es la de algún usuario que quiere ejecutar “algo” en un servidor. Como no puede ser de otra manera dadas las restricciones de seguridad de la compañía, solo le puedo dar acceso por SSH; pero poner una jaula para restringir sus acciones es tedioso.
Como bien sabemos los que trabajamos con Docker, el servidor es bastante malo comprobando si un contenedor está funcionando o no. El check que hace Docker solo se molesta en ver si el proceso invocado está ejecutando o no, aunque no esté respondiendo. Esto ha cambiado recientemente con los healthchecks.
Es un hecho inmutable que los desastres con nuestros datos ocurren; da igual lo cuidadosos que seamos, o si el servicio se autoreplica. En algún momento puede perderse información por un fallo imprevisto, o puede que sea necesario restablecer un punto conocido, para buscar errores o para cumplir imperativos legales.
Casi siempre he utilizado docker-compose en mi local, y eso me ayudó mucho cuando empecé a usar Docker Swarm. El fichero docker-compose.yml varía un poco en cada entorno y cada vez que se modifica se degrada respecto al original, por no mencionar el problema de mantener actualizadas las copias.