Continuamos la serie enfocada a construir un entorno entero basado en docker swarm siguiendo desde el punto en que lo dejamos: con los servidores a punto y el cluster en marcha. Ahora vamos a poner en marcha un cluster de base de datos en el mismo swarm que, por ejemplo, va a ser un replica set de mongodb.
Continuamos con esta serie de artículos con la finalidad de crear un entorno dockerizado completo. Vamos a ir creando la infraestructura necesaria para alojar nuestro cluster de docker swarm. Esto implica crear una red privada, un gateway para esconderla, y finalmente ataremos el cluster de docker swarm.
Hace tiempo trabajé en una compañía que tenía un entorno productivo basado en docker. Fueron de los primeros en adoptar docker y no utilizaban ninguna tecnología de clusterización. Los contenedores se ponían en alguna máquina con capacidad adecuada; los balanceadores y las bases de datos tenían máquinas dedicadas.
Tras aprender más de systemd y su modo de usuario, vi infinitas posibilidades para los servicios de usuario. Dependiendo del tipo de tarea en la que iba a trabajar, parecía lógico tener un subconjunto de servicios ejecutando en segundo plano. ¿Había alguna manera de levantar varios con un solo comando?
Una de las funciones que prometía systemd cuando apareció era la de reemplazar las utilidades tipo cron. Esto era bueno porque iba a estandarizar un servicio que no lo estaba (aunque las diferentes distribuciones lo daban por hecho); esta idea se quedó en el tintero y es hora de sacarla.
Es bastante habitual que en mi tiempo de ocio me dedique a trabajar con HTML y CSS por interés personal. A veces puedo hacer pruebas de concepto estáticas y otras puedo utilizar un generador estático; en todos los casos necesito de un servidor web levantado solo para mi sesión personal.
Hace ya algún tiempo escribí un artículo sobre como montar un gateway utilizando Debian, iptables y dnsmasq. Siguiendo mi política de ir actualizando los artículos más útiles, y visto la aparición en mi toolbox de una nueva herramienta para simplificar iptables, le ha tocado una reescritura al artículo mencionado anteriormente.
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.
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.