En mi trabajo, los problemas llegan sin previo aviso. De repente, alguien te pone en aviso que su aplicación web está caída y es inaccesible. Se trata de un problema de resolución DNS, pero queremos probarlo para estar seguros de que solo es ese el problema y no es general.
Muchas veces necesitamos herramientas para nuestro trabajo y no las usamos desde la misma máquina; otras veces no queremos instalar muchos paquetes en nuestra máquina. Tener una máquina virtual suele ser overkill para ejecutar algunos binarios. En este caso podemos tener nuestras imágenes docker listas para ser usadas según convenga.
Algunas veces me he encontrado con usuarios de alguno de mis servidores SFTP que se quejan porque “les desaparecen archivos”. Si estamos seguros que esas desapariciones no tienen nada que ver con nosotros, lo mas probable es que lo hayan hecho los mismos usuarios, sea manualmente o de forma automática.
Hemos hablado de generar nuestro contenido HTML estático con otras herramientas, y finalmente ha llegado la hora de servirlo. Normalmente, los ficheros que cambian tal y como vamos generando páginas son pocos y nos interesa copiarlo de forma remota, pero no podemos hacerlo con docker porque hacen falta dos servicios.
Algunas veces nos hemos planteado la posibilidad de tener nuestro propio servidor con nuestras propias aplicaciones, pero el coste del hosting nos lo ha hecho replantear, especialmente para proyectos de pruebas sin beneficio. Si no nos importa hospedar contenido HTML estático, las páginas de GitHub pueden cumplir con nuestras necesidades.
Antes de la masiva invasión de PHP y mysql en todos los proveedores de internet, existían solamente las páginas HTML estáticas. Los servidores eran más simples y tenían menos superficie de ataque, aunque mantener las páginas web era un auténtica pesadilla; para eso se han creado los generadores web estáticos.
Como ya sabemos, un contenedor docker solo puede ejecutar un proceso, y su finalización implica la parada del contenedor. Sin embargo, a veces nos puede interesar cargar los contenedores con algún servicio más, para hacerlos autosuficientes. Para ello, nos podemos ayudar de un gestor de procesos, como por ejemplo, runit.
Cuando tenemos un servicio balanceado, los backends no tienen relación entre sí y podemos poner tantos como queramos, sin miedo a que alguno se caiga. Sin embargo, para los servicios tipo “ventanilla única” interesa tener varios dispuestos a dar un servicio failover; si uno se cae, otro asume la carga.
Finalmente ha sucedido: el ingeniero de seguridad de la empresa ha decidido cerrar servicios de sincronizado de ficheros, dejando inútiles servicios como Dropbox, Mega y otros. Sin embargo, cualquier bloqueo que se haga mediante el dominio hace que sea imposible cerrar todos estos servicios, e incluso podemos poner el nuestro.
El otro día tuvimos una caída del centro de datos de desarrollo. Inmediatamente después vimos que teníamos afectación en el entorno de producción, ya que lanzaba peticiones al DNS de desarrollo. Sin saber claramente porque pasaba, hice un servidor DNS en python, para ver que tipos de peticiones se lanzaban.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 » »»