[native docker clustering with swarm] Meeting docker swarm mode

swarmkit

«toolkit for orchestrating distributed systems at any scale. It includes primitives for node discovery, raft-based consensus, task scheduling, and more» - Docker team at DockerCon16
Los cluster swarm está compuesto de nodos activos, que pueden actuar como managers o workers.
- los managers, coordinados via Etcd (raft), elegidos entre todos, son responsables de reservar recursos, orquestrar servicios y repartir tareas a lo largo del cluster
- los workers ejecutan las tareas.
Los servicios que se lanzan al cluster se convierten en tareas cuando llegan al worker
Los servicios no tienen porque ser contenedores. La intención del swarmkit es la de orquestrar cualquier objeto.
arquitectura:
- número impar de nodos manager (evitar split-brain en las elecciones)
- soporta cualquier tamaño de cluster de servicios
- managers y workers
- cualquier número de workers.
- en los managers, los servicios se definen y se balancean.
elección del mejor nodo para una tarea (scheduling)
swarmd
- usado para masters y slaves
- swarmctl
- docker run -it fsoppelsa/swarmkit swarmd –help
- docker run -it fsoppelsa/swarmkit swarmctl –help
  - cliente para operar con el cluster swarmkit

> 1.12
integrado en docker (al contrario que swarmkit). Comandos:
- swarm: docker swarm init
- nodes: docker node ls
- service: docker service tasks
- task
3 maneras de orquestrar (evolución)
- swarm v1
- swarmkit
- swarm mode

swarm v1	swarm mode
docker 1.8	docker 1.12
container	docker engine
servicio discovery externo (Consul, Etcd, Zookeeper)	Etcd integrado
no securizado por defecto	securizado por defecto
no replica, no scaling	si replica, si scaling
no existen los conceptos de servicio y tareas	servicios, tareas y balanceo de carga de serie
no existen servicios de networking adicionales	lleva integrado VxLAN (mesh networking)

swarmkit	swarm mode
binarios (swarmd, swarmctl)	integrados en docker
son tareas genéricas	son tareas en contenedores
incluye servicios y tareas	incluye servicios y tareas
no balanceo de carga, no VxLAN	incluye balanceo de carga y VxLAN

init:
- inicializa el swarm
- crea manager en el host actual
- genera secreto (token) para los workers
join:
- usado por los workers para añadirse al cluster.
- debe especificar el token y lista de IP:PORT de los managers
join-token:
- maneja los join-tokens (el de los managers y el de los workers)
- imprime el comando necesario para el join
  - docker swarm join-token { worker | manager }
update:
- actualiza valores del cluster (por ejemplo, una nueva URL de certificado)
leave:
- el nodo actual deja el cluster
- –force si hay algún incoveniente
- manager → worker → leave

para gestionar los nodos del cluster swarm.
se ha de lanzar desde un manager
demote/promote:
- demote: pasa un nodo de manager a worker
- promote: pasa un nodo de worker a manager
inspect:
- equivalente a docker info
- muestra información del nodo
ls:
- lista de nodos conectados al cluster
rm:
- intenta desconectar un worker (hacer demote si es un manager)
ps:
- lista las tareas corriendo en un nodo especificado
update:
- permite cambiar valores del nodo

cada servicio tiene un único nombre DNS
los balanceadores corriendo contenedores usan el DNS interno
por cada servicio con la etiqueta --name <SERVICE>, cada contenedor sera capaz de resolver la IP del servicio a través de ese nombre (intercomunicación)
posibilidad de publicar puertos de servicio al balanceador de carga externo → --publish-add
del 30000 al 32767 (externamente)
internamente, se usa iptables y IPVS para realizar filtrado de paquetes, reenvio y balanceo de carga.
docker service update --port-add 80 nginx-service
- crea un mapeo entre el puerto 30000 en cada uno de los nodos del cluster contra los contenedores nginx en el puerto 80. Si conectas <IP_NODO>:30000 aparecerá la página de presentación de nginx
- esto se consigue gracias a la red creada por ingress overlay swarm. Cualquier nodo del cluster resuelve a través de la VIP (VirtualIP) y el DNS interno. Cada nodo implementa el balanceo de carga a nivel de kernel, especificamente en el namespaces, añadiendo una regla MARK en la cadena OUTPUT en la red:

servicio: abstracción de la agrupación de un número de tareas arbitrario (conocido como replicas)
tareas: contenedores

asegurarse que un número determinado de réplicas se está ejecutando al mismo tiempo en el cluster.
cuando cambias el número de réplicas, se hacen los ajustes necesarios en los balanceadores, DNS y redes.
Swarm no rebalancea tareas si se añaden nuevos nodos al cluster (es concervador) hasta que algun operador reescala el servicio