درباره این اپیزود
Te doy la bienvenida al episodio 27 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 20 de marzo de 2018.
Si recuerdas el episodio anterior de deployándome habíamos estado conversando en forma general sobre los cluster de docker y habíamos visto que permiten solucionar problemas de escalabilidad. Vimos que son útiles cuando tus aplicaciones o servicios tienen requisitos de disponibilidad continua y en caso de problemas necesitas recuperarte automáticamente. También los clusters, permiten adaptar en forma elástica el consumo de recursos de computación asignando mas recursos o liberándolos.
En esta edición voy a concentrar las características del cluster nativo de Docker; vamos a estar viendo Docker Swarm: que podemos definir como la manera de tener varios Docker Engine corriendo como un enjambre.
Decir que Docker Swarm es nativo en Docker tiene una doble implicancia:
Por un lado significa que no se debe instalar nada más que docker (y me refiero al daemon Docker Engine y su cliente docker) para poder armar un cluster, es decir que Docker Swarm está integrado en Docker que ya tienes instalado.
Y, por el otro lado, significa que es muy fácil de implementar, pues el trabajo de instalarlo es exactamente el mismo que instalar Docker en varias máquinas. Lo que vamos a tener son Docker Engine que asumen distintos roles y esos roles son dos: manager y worker. Los worker solamente levantarán dockers con mi aplicación y los manager también lo harán, pero además se encargarán de los servicios del propio cluster.
Además de estas dos características, Docker Swarm tiene una serie de funciones automáticas, de las cuales te comento cinco de ellas:
Primero, la reconciliación de estado, es decir que si mi servicio se basa en tener levantados, por ejemplo, cinco réplicas de contenedores balanceados y por algún motivo alguna se cae, Docker Swarm se dará cuenta del problema y se encargará de recuperar el estado deseado de mi servicio sin que necesite tomar ninguna acción.
Pero la reconciliación del estado no se queda solo en el servicio o mi aplicación. Si por algún motivo el nodo con el rol de manager activo se cae otro nodo con el rol manager tomará su lugar y se volverá activo, si es que configuramos más de un manager dentro del cluster (algo recomendado en ambientes de producción)
Segundo el descubrimiento de los servicios. ¿qué quiere decir esto? supongamos que tengo un cluster formado por diez computadores (o máquinas virtuales) cada una de ellas corriendo Docker Swarm y cuando levanto mi servicio digo que debe tener cinco réplicas corriendo, cada una ira a levantarse en alguno de los nodos, sin un orden y será tarea del manager activo registrar en qué nodos se levantó cada réplica de mi servicio, para conducir las peticiones de los clientes hasta la aplicación. Obviamente podemos definir políticas de afinidad para que una aplicación vaya al nodo o grupo de nodos que deseo.
En tercer lugar Docker Swarm hará una magia interesante a nivel de red para que mi servicio que puede requerir multiples dockers pueda funcionar como siempre, es decir, como si estuviera en una sola máquina.
A ver si me explico:
Supongamos que levantamos WordPress: tendremos un docker para el servidor web, digamos nginx, otro para el PHP con php-fpm y otro para la base de datos MySQL, cada uno de estos docker tendrá con la directiva EXPOSE configurado el puerto que escucha su servicio y se vinculará con la directiva LINK desde el docker que consume los servicios. Hasta aquí algo que hacemos con cualquier WordPress que levantamos en docker.
Cuando lo llevamos a un cluster Docker Swarm esto se complica, pues podemos configurar que tendremos solo una réplica para el MySQL que se levanta en algun nodo, digamos el nodo 1; tres réplicas de PHP que se levantará en los nodos 2, 3 y 4 y dos réplicas del web d
