A veces descubrimos algunos trucos que no merecen un artículo en sí mismos. Para estos casos, una opción es dejarlos olvidados en algún apartado remoto de la memoria; como no queremos tener que recordar, me voy a limitar a dejarlos por aquí como ideas para cuando se puedan utilizar.
Muchas veces nos ponemos a escribir nuestros ficheros Dockerfile sin prestar mucha atención a lo
que salga, siempre que funcione. Es una forma correcta de ver las cosas, pero suele ser un error;
verificar unos pocos puntos antes de dar el fichero por bueno nos puede ahorrar problemas futuros
y no requiere mucho tiempo.
Ya hace tiempo que trabajo a nivel personal con varios blogs hechos con generadores estáticos y algunas aplicaciones simples PHP. Como ninguno tiene una carga demasiado alta, decidí unificarlos en pocos servidores pequeños para economizar. En algún momento se me ocurrió que podía hacerlo de forma estándar.
Ha vuelto a pasar: tengo una máquina virtual con un disco secundario que se queda pequeño.
Añado otro disco, lo preparo, sincronizo los datos y configuro su montaje en el /etc/fstab,
usando su nombre de dispositivo. Eventualmente, reinicio el servidor, tras retirar el disco
antiguo y su nombre de dispositivo ha cambiado, causando que la máquina no arranque.
Hace mucho tiempo que he creído en MongoDB. Sin embargo, con el cambio de licencia el soporte del mismo ha caído en los repositorios oficiales de las diferentes distribuciones. Para añadir más sal a la herida, la empresa responsable no soporta las últimas distribuciones estables de Debian en sus repositorios.
No es un secreto que me encanta utilizar systemd; aunque hay una buena parte de la comunidad que lo detesta, siempre encuentro la manera de hacer lo que yo necesito. Y es que las funcionalidades que ofrece son muchas y la documentación es excelente. Vamos a ver algunas recetas útiles.
Ya vimos en otro artículo sobre los sistemas de ficheros tipo stacked, como por ejemplo AUFS. Estos nos pueden ser útiles en multitud de ocasiones, y en particular OverlayFS, que ya viene en el kernel de muchos de los Linux habituales y sirve como la base sobre la que se construye Docker.
Hace tiempo que no usaba haproxy. Puede ser porque he priorizado otras soluciones, sean otros servicios como nginx o, simplemente la plataforma ya me ofrecía soluciones incorporadas o empresariales. Pero la verdad es que haproxy funciona, y es una solución a la que vuelvo de forma recurrente.
Cada vez nos encontramos con el mismo problema; empezamos un nuevo proyecto y tenemos que crear toda la estructura del proyecto partiendo de cero, de un ejemplo, o haciendo copy-paste de otro anterior. Esto implica cambiar algunos nombres de ficheros y carpetas, o contenido de ciertos ficheros; es toda una invitación al desastre.
Ya hablamos sobre los sidekick containers en otro artículo. Vimos como podemos tener contenedores que se dediquen a “ayudar” a otros contenedores, y la idea es la misma cuando trabajamos con Docker Swarm. Lo que no es tan simple es crear un contenedor que ejecute una acción y “muera”, una vez cumplido su objetivo.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 » »»