Docker Logo

Filtros y estrategias de planificación de un cluster con Swarm

Swarm tiene disponible a día de hoy dos estrategias para desplegar los contenedores entre los nodos de Docker del cluster: BinPacking y Random. Por defecto, Swarm utiliza la primera; la segunda únicamente escoge un nodo al azar y está pensada para tareas de depuración según indica la documentación.

En este artículo cubriremos los detalles del planificador y los filtros que se le pueden aplicar para desplegar nuestros contenedores.

La estrategia BinPacking

Esta estrategia intenta evitar la fragmentación de nuestros contenedores a lo largo de los diferentes nodos para permitir que si necesitamos contenedores con alto consumo de recursos puedan desplegarse en los nodos sin usar. Swarm realizar una ordenación de los nodos basada en la cantidad de memoria y procesado disponible devolviendo aquel que esté más compactado (más recursos en uso)

Podemos cambiar la estrategia de planificación a la hora de lanzar nuestro nodo de gestión con el parámetro –strategy. Siguiendo los ejemplos de los artículos anteriores sería de la siguiente forma:

# Estrategia BinPacking
$ docker run -d --name manageBinPacking -p 5005:2375 swarm manage --strategy binpacking token://"ClusterID"
# Estrategia Random
$ docker run -d --name manageRandom -p 5006:2375 swarm manage --strategy random token://"ClusterID"

El primer contenedor que se despliegue, dado que todos los nodos están vacíos, será elegido por Swarm de forma aleatoria.

Filtros para el planificador

Si nos interesa tener un mayor control de cómo se despliegan nuestros contenedores en el cluster es posible utilizar filtros de restricción. Dichos filtros establecerán una serie de condiciones extras que el planificador de Swarm necesitará tener en cuenta antes de desplegarlo. Tenemos disponibles los siguientes:

  • Filtro de afinidad: despliega los contenedores basándose en otros contenedores existentes o en imágenes disponibles en los nodos. Admite una sintaxis variada que permite definir reglar más complejas que incluyen también escenarios de antiafinidad.
  • Filtro de puerto: despliega los contenedores basándose en la disponibilidad de un puerto público dentro del nodo.
  • Filtro de dependencia: despliega contenedores que tienen dependencias entre sí en el mismo nodo. Dichas dependencias se relacionan con volúmentes compartidos, enlaces, o una pila de red compartida.
  • Filtro de estado de salud: evita que se desplieguen contenedores en nodos que tienen actualmente algún tipo de problema.
  • Filtros definidos por el usuario: es posible definir una serie de etiquetas asociadas a cada nodo del cluster en el momento de su arranque que pueden ser utilizadas por Swartm para desplegar los contenedores. Por ejemplo, el tipo de almacenamiento del nodo (SSD/HDD), la región (Europa/EEUU/…), el entorno (Producción/Pruebas/…)

Vamos a partir de un escenario donde queremos desplegar dos entornos de WordPress que utilicen un servidor de MySQL para alojar los datos. El primer WordPress estará en nuestros servidores de producción junto con un contenedor con motor de MySQL, el segundo estará replicando el mismo escenario en nuestro entorno de testing. Para el de producción, utilizaremos un servidor que tendrá almacenamiento de tipo SSD que mejorará el rendimiento del motor.

Para ello, necesitaremos en primer lugar establecer un filtro definido por nosotros asociado a cada nodo para indicar a qué entorno pertenecen. Esta configuración es necesario realizarla en el momento de arrancar el nodo empleando el parámetro –label. Por lo tanto, configuraremos las opciones de arranque como indicaba en el primer artículo sobre Swarm modificando el fichero /etc/default/docker de cada nodo.

# az4li-dock-sw-1: Producción, Almacenamiento HDD
DOCKER_OPTS="-H 0.0.0.0:2375 --label storage=hdd --label environment=production"
 
# az4li-dock-sw-2: Producción, Almacenamiento SSD
DOCKER_OPTS="-H 0.0.0.0:2375 --label storage=ssd --label environment=production"
 
# az4li-dock-sw-3: Pruebas, Almacenamiento HDD
DOCKER_OPTS="-H 0.0.0.0:2375 --label storage=hdd --label environment=testing"

Tras aplicar los cambios al fichero será necesario reiniciar el servicio de Docker para que coja los nuevos parámetros desde el fichero.

El siguiente paso será empezar a desplegar los contenedores; comenzaremos con el de MySQL y luego desplegaremos el de WordPress. En el proceso, pasaremos a Swarm las restricciones para que los sitúe como hemos comentado.

$ docker -H tcp://0.0.0.0:5005 run -d -e MYSQL_ROOT_PASSWORD=Passw0rd -e constraint:environment==production -e constraint:storage==ssd --name wp-mysql mysql

Como vemos, el scheduler lo desplegará en el nodo az4li-docker-sw-2 siguiendo nuestras restricciones. Si no existen las imágenes en el nodo éstas serán descargadas por lo que el proceso de creación del contenedor puede llevar unos minutos.

Despliegue con restricciones del planificador de Swarm
Despliegue con restricciones del planificador de Swarm

Hacemos ahora lo mismo con nuestro primer nodo de WordPress

$ docker -H tcp://0.0.0.0:5005 run -d --link wp-mysql:mysql -p 8080:80 -e constraint:environment==production --name prod-wordpress wordpress
Despliegue con restricciones del planificador de Swarm
Despliegue con restricciones del planificador de Swarm

Y repetimos con el segundo entorno de replica en testing.

$ docker -H tcp://0.0.0.0:5005 run -d -e MYSQL_ROOT_PASSWORD=Passw0rd -e constraint:environment==testing --name wp-mysql-test mysql
$ docker -H tcp://0.0.0.0:5005 run -d --link wp-mysql-test:mysql -p 8080:80 -e constraint:environment==testing --name test-wordpress wordpress
Escenarios desplegados con Swarm
Escenarios desplegados con Swarm

Con ello, ya podremos trabajar con nuestro entorno de producción y pruebas de WordPress.

Wordpress desplegado a través de Swarm
WordPress desplegado a través de Swarm

Seguro que estás pensando en las capacidades de poder desplegar diferentes contenedores en diferentes nodos y comunicarlos entre sí. Si lo haces con el parámetro –link no te lo va a permitir ya que restringe al nodo específico donde esté ejecutándose el contenedor con el que nos queremos enlazar. Para esos entornos, será necesario echarle un ojo al patrón ambassador

Leave a Reply

Your email address will not be published. Required fields are marked *