Muchas de nuestras aplicaciones diarias utilizan una base de datos, y es muy fácil disponer de una utilizando los repositorios de la distribución utilizada. Sin embargo, en entornos críticos hace falta algo más profesional, capaz de resistir en caso de fallos en los nodos y capaz de asumir mucha más carga.
Lo más preciado de un desarrollo siempre es el código: Si se trata de código hecho por desarrolladores, hay muchas horas invertidas; si se trata de configuraciones como código, supone la forma de reconstruir un sistema desde un punto catastrófico. Por ello es necesario tenerlo a buen recaudo.
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.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 » »»