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.
Hace unos meses recibí una petición interesante; unos conocidos querían exponer un sitio web estático, pero lo querían replicado en muchos sitios porque era posible que les fueran cerrando sitios por su dudosa legalidad. Por supuesto me negué, pero el desafío era muy estimulante, así que intenté diseñarlo a posteriori.
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.
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.
Tras cambiar de oficina en mi trabajo, vuelvo a tener el dudoso honor de trabajar tras un proxy. Como viene siendo habitual, me puse un servidor Virtualbox con Debian para disponer de las opciones que una máquina auxiliar me ofrece, pero no fue hasta instalar Docker que estalló el desastre.
En mi trabajo estamos renovando el proveedor de infraestructura de nuestros servicios. Al migrar las máquina nos estamos encontrando servicios desorganizados, en varios lenguajes y en versiones antiguas. Uno de estos servicios es un frontal PHP mugriento, y lo migramos rápidamente en un contenedor usando el servidor incorporado de PHP.
Según el paradigma de externalización de mi empresa, todos los sistemas son gestionados por un tercero, a base de cambios. Por petición mia, tengo un usuario nominal de SSH y puedo entrar a mirar logs y configuraciones, pero no todas. Lo que no saben es que puedo hacer de todo.
Tras cambiar de equipo de trabajo, me encuentro con un repositorio de información procedimental consistente en una carpeta compartida con varias versiones de documentos que hacen referencia al mismo procedimiento. Esto convierte la tarea de buscar un procedimiento en un infierno, por no mencionar el gran esfuerzo de mantenerlos actualizados.
Cuando usamos integración continua o despliegues en varios servidores y usamos docker, se hace importante tener una fuente de imágenes de donde descargar las nuestras propias. Aquí entra en juego la confidencialidad, y es necesario pagar la capa privada de un registro, o podemos simplemente crear un registro nuestro propio.
Estaba yo el otro día intentando montar un jenkins con acceso al binario de docker y python. Como no quería instalar jenkins, me limité a extender la imagen jenkins/jenkins para dotarlo de las herramientas necesarias, como ya hicimos con ansible que, aunque funciona, no es ni elegante ni escalable.