Docker Swarm
Orquestando contenedores en la Nube
Creada por Alejandro Escanero Blanco / Twitter: @aescanero Documentación y demo en https://github.com/aescanero/dockerevents/opensouthcode Presentación en Disasterproject
Introducción a Docker
¿Que es un "Contenedor"?
Es un proceso que ejecuta aislado su propio espacio de memoria, CPU, I/O y red
En linux se utilizan dos caracteristicas para ello: Namespaces an Cgroups
Existen muchas implementaciones en el mercado: Docker, LXC, RKT, OpenVZ...
Fuente: What even is a container: namespaces and cgroups
Fuente: Cgroups, namespaces, and beyond: what are containers made from?
Existe un gran esfuerzo de estandarización
Open Container Initiative: Define las especificaciones del motor de ejecución e imagenes de los contenedores
Cloud Native Computing Foundation: Bajo el paraguas de la Linux Foundation define las tecnologías de contenedores y cloud
Fuente: Native Landscape (CNCF and OCI)
¿Que es Docker?
Es un proyecto Open Source: Moby Project
Es un producto orientado a la comunidad: Community Edition
Es un producto orientado a entornos empresariales: Enterprise Edition
Fuente: INTRODUCING MOBY PROJECT
Pero sobre todo es una tendencia del mercado
Es una tendencia en Empleo
Fuente: Indeed: Docker, Kubernetes and Swarm.
Se espera un importante crecimiento para 2017 en entornos DevOps
Fuente: Get the RightScale State of the Cloud Report
Interes en 2016 en entornos DevOps
Fuente: Docker Trends
Fuente: Cloud Trends for 2017 and Actions You Can Take Now
Charlas Relacionadas con Docker en OpenSouthCode
Desarrollando con Docker
Sala Fuengirola 16:00
Integración Contínua de aplicaciones móviles con Docker y Appium
Sala Fuengirola 17:00
Cuando Dev conoció a Ops
Sala Fuengirola 18:00
Zero downtime applications with OpenShift
Sala Riogordo 13:00
Nubes de Contenedores
Desarrollos mas rápidos, con mayor libertad para los desarrolladores
Entornos mas complejos, densos y cambiantes
Entornos de tecnología dispares y distribuidos
Politicas y seguridad empresarial
...Y Producción...
Fuente: Top 5 challenges with deploying containers in production
Fuente: DevOps, Microservices and containers - a high level overview
El modo de gestión de cluster distribuido de Docker: Swarm
Los Engine ("Nodos" en modo Swarm) Docker se configuran para distribuir la carga y tendremos dos tipos.
Aquellos Nodos que se mantienen la configuración de todos los servicios Docker son los "Manager", se configuran para que se comuniquen entre ellos usando el protocolo Raft
Uno de los Managers será elegido lider, mientras que el resto son elegibles.
Todos los Nodos (incluso los Managers) reciben y ejecutan tareas enviadas por los Manager
Fuente: Raft consensus in swarm mode
Fuente: DevOps, Microservices and containers - a high level overview
Fuente: Swarm mode key concepts
Ejemplo
Iniciando el primer nodo manager en la IP 192.168.8.2, nos devolverá un "token" que usaremos
para conectar los nodosdocker swarm init --advertise-addr "192.168.8.2" --listen-addr "192.168.8.2:2377"
Procedemos a consultar que "token" es necesario para añadir nuevos Managers
docker swarm join-token manager
Añadimos un nuevo manager con la IP 192.168.8.3
docker swarm join --advertise-addr "192.168.8.3" --listen-addr "192.168.8.3:2377" --token $key 192.168.8.2
Añadimos el resto de nodos no Manager
docker swarm join --token $key 192.168.8.2
Un resultado de un conjunto de nodos con dos Manager, podemos ver cual es el lider y que los
nodos están en Down (estan apagados)swarm-master-1:~$ sudo docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 1jl7pgsx23vpxnet7lvsyq9yf swarm-node-3 Down Active 5p00x5dn53xfz33v8ad1jwiyq swarm-node-2 Down Active mjxf52vga4t47ns92ym7pq8xq swarm-node-1 Down Active o7az8ubf8sk8yb9jp18gz53w8 * swarm-master-1 Ready Active Reachable q19pfkrgd2nphqmj1yd0wp2yz swarm-master-2 Ready Active Leader
Gestionando las imagenes de los contenedores: Registry
Los contenedores se generan desde imagenes que descargaremos desde hub.docker.com
El registro es una herramienta que nos permite guardar las imagenes que hallamos creado o descargado
Debemos tener un registro es nuestra nube para evitar que cada nodo vaya a internet a descargar las imagenes
Redes dentro de la nube
Dentro del modelo de red de Contenedores, los contenedores mantienen una red que los conecta al directamente nodo (red host)
Para acceder al exterior, se utiliza una red de puente (bridge).
Utilizando la red bridge y VXLAN se pueden conseguir redes que conecten unos contenedores con otros
Estas redes se conocen como redes overlay
Fuente: Docker Reference Architecture: Designing Scalable, Portable Docker Container Networks
Ejemplo
Creamos dos redes overlay
sudo docker network create -d overlay be
sudo docker network create -d overlay fe
Comprobamos que efectivamente se despliegan
sudo docker network ls
NETWORK ID NAME DRIVER SCOPE
p13bh7pilb71 be overlay swarm
cca979284ca2 bridge bridge local
abedd882c417 docker_gwbridge bridge local
2k04q42d8l9v fe overlay swarm
0fab68cf1222 host host local
jsh8aaw7nebr ingress overlay swarm
3fba02d48df4 none null local
Se pueden añadir otros tipos de redes (Network Plugins)
Contiv
Es una extensión (plugin) creada por Cisco, ideada para integrar las redes de soluciones de cloud heterogeneas con gestión de políticas
Weave
Permite la integración de redes de cloud heterogeneas, integra su propio sistema de descubrimiento e IPAM.
Los Servicios o como se despliegan los contenedores en Swarm.
El servicio es un empaquetado de contenedores que ademas incluye una serie de reglas
El puerto donde es visible el servicio, la red a la que se conecta, reservas de CPU y memoria
Politicas de despliegue, disponibilidad y número de réplicas
Fuente: How services work
Comportamiento de los servicios en la red (Endpoint Mode)
VIP (Virtual IP): Se asigna una IP para el servicio, y a cada contenedor una IP del mismo rango
La IP del servicio es virtual y sirve para balancear entre los contenedores. El nombre del servicio apunta a la IP Virtual
DNSRR: Se asigna a cada contenedor una IP del mismo rango, el nombre del servicio apunta a cada contenedor por orden (round robin)
Fuente: Attach services to an overlay network
Fuente: Reference Architecture: Universal Control Plane 2.0 Service Discovery and Load Balancing
Ejemplo
Creamos un servicio para el registro
sudo docker service create --constraint=engine.labels.myproject.service==fe --endpoint-mode vip \
--network fe --publish 5000:5000 --restart-condition any --name registry registry:2
Comprobamos que efectivamente se despliega
sudo docker service list
ID NAME MODE REPLICAS IMAGE
qb5wpzv0z077 registry replicated 1/1 registry:2
Comprobamos donde se despliega
sudo docker service ps registry
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
sxuhruy385t3 registry.1 registry:2 swarm-master-2 Running Running about a minute ago
Los servicios son escalables
Un servicio puede desplegar un número indeterminado del mismo contenedor ya que son elasticos
Podemos descubrir los otros nodos forman parte del mismo servicio (service discover), ya que dispone de un servicio DNS integrado para conocer quien conforma el servicio y la dirección VIP.
La dirección VIP es el nombre del servicio
/ # ping registry
PING registry (10.0.1.2): 56 data bytes
64 bytes from 10.0.1.2: seq=0 ttl=64 time=0.094 ms
Los contenedores que forman el servicio se publican como tasks.SERVICIO
/ # nslookup tasks.registry
Name: tasks.registry
Address 1: 10.0.1.3 8cad19f2c5dd
Stacks y Compose
Las aplicaciones están hechas por mas de un único tipo de contenedor
Un Stack es un paquete donde se definen los servicios y redes que forman parte de la aplicación
Compose es una aplicación capaz de convertir un guion donde se definen multiples servicios y redes en un Stack
Fuente: Overview of Docker Compose
Fuente: Compose file version 3 reference
Ejemplo
version: '3.1'
services:
ldap:
image: localhost:5000/myproject:ldap_v1
deploy:
mode: replicated
replicas: 3
restart_policy:
condition: on-failure
placement:
constraints:
- engine.labels.myproject.service == be
resources:
limits:
cpus: '0.1'
memory: 100M
reservations:
cpus: '0.01'
memory: 50M
networks:
- be
fd:
image: localhost:5000/myproject:fd_v1
deploy:
placement:
constraints:
- engine.labels.myproject.service == fe
resources:
limits:
cpus: '0.1'
memory: 300M
reservations:
cpus: '0.01'
memory: 200M
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost"]
interval: 1m30s
timeout: 10s
retries: 3
networks:
- fe
- be
ports:
- "3100:80"
tty: true
networks:
fe:
be:
Monitorización
Existen múltitud de herramientas para gestionar las métricas generadas por Docker
Una combinación de herramientas en linea de comandos puede ser util (systemd-cgtop, docker stats), pero con multitud de servidores necesitamos herramientas mas amigables.
Como ejemplos tenemos Elastic (ELK), Prometheus, Grafana, Graphite, cAdvisor, y un sin fin.
Y por supuesto los clasicos (Nagios, Zabbix, Sensu, etc), se pueden utilizar para monitorizar contenedores.
Fuente: Container Performance Analysis
Fuente: Monitoring Docker Swarm with cAdvisor, InfluxDB and Grafana
Registros
Al igual que con las métricas tenemos múltiples opciones para una gestión centralizada de los registros de los servicios
Al crear el servicio se puede configurar para que utilice un syslog remoto, aunque hay otras opciones como Filebeat para el envio de registros
Docker dispone de plugins para envios de registros a soluciones como Graylog2, Splunk y Fluentd entre muchas.
Fuente: Configure logging drivers
