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.
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.
Trabajando con Docker Swarm me doy cuenta de que hay muchos servicios tipo “ventanilla única” que suelo poner en los mismos managers. El asunto es que un despliegue con Docker Swarm funciona mejor con un número impar de managers, siendo 3 o 5 lo recomendable para un entorno de producción.
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.
Tras probar algunos servicios pensados para la nube o para contenedores, veo que algunos de ellos dependen de una pieza central llamada zookeeper. Como soy una persona curiosa, he decidido dedicar un artículo a entender como funciona este servicio, que se limita a guardar cosas de forma distribuida y redundante.
Me defino como una persona de tecnología clásica, pero últimamente me ha dado una aire de modernillo y me he empezado a mirar el tema de los podcasts. Como amante del terminal necesitaba conocer alguna herramienta que me permitiera hacer casts de mi terminal y encontré uno interesante: es asciinema.
Tras ver la facilidad con la que monté un firewall para un servidor solitario usando shorewall, he estado investigando sobre como hacer firewalls dedicados que enruten el tráfico en mis redes. En este artículo expongo lo que llegué a conseguir, esperando que le sirva a alguien en un futuro cercano.
Cada vez que me toca proteger un servidor con iptables me desanimo solo de pensarlo. No es que la herramienta sea mala (que me encanta), sino porque no es intuitiva y hay que tener en cuenta muchos casos raros. Por suerte hay utilidades que construyen el conjunto de reglas fácilmente.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 » »»