Implementación Docker Swarm AWS ASG y ELB - …...diferencia es que uno se lanza en modo cliente y...

3

ÍNDICE

ÍNDICE ............................................................................................................................................ 3

1 Objetivos ............................................................................................................................... 8

2 Docker ................................................................................................................................... 9

¿Qué no es Docker? ...................................................................................................... 9

¿Qué es Docker?............................................................................................................ 9

Máquinas virtuales vs. Contenedores ......................................................................... 10

3 Componentes y Conceptos Docker ..................................................................................... 10

Docker Engine (Cliente/Servidor) ................................................................................ 10

Docker Registry ........................................................................................................... 11

Docker Network .......................................................................................................... 11

3.3.1 Puertos en contenedores Docker ........................................................................ 12

Dockerfile .................................................................................................................... 12

Imagen de Docker ....................................................................................................... 13

Docker Hub .................................................................................................................. 13

Volúmenes de Docker ................................................................................................. 13

4 Docker Swarm ..................................................................................................................... 14

Docker Swarm ............................................................................................................. 14

Docker Machine .......................................................................................................... 15

Docker Compose ......................................................................................................... 15

Docker Services ........................................................................................................... 15

Stack de servicios ........................................................................................................ 16

5 Trabajando con Docker ....................................................................................................... 17

Instalación Docker en Ubuntu 18.04 ........................................................................... 17

5.1.1 Instalación Docker ............................................................................................... 17

5.1.2 Ejecutar el comando Docker sin sudo o desde otro usuario ............................... 17

Referencia comandos Docker ..................................................................................... 18

5.2.1 Comandos gestión Docker................................................................................... 18

5.2.2 Comandos Docker Swarm ................................................................................... 23

5.2.3 Comandos Docker Machine ................................................................................ 23

5.2.4 Comandos Docker Node ...................................................................................... 23

5.2.5 Comandos Docker Service ................................................................................... 24

5.2.6 Comandos Docker Compose ............................................................................... 25

5.2.7 Comandos Docker Stack ...................................................................................... 26

4

Creando un dockerfile ................................................................................................. 27

5.3.1 ¿Qué es Supervisor? ............................................................................................ 29

6 Crear una imagen Wordpress personalizado ...................................................................... 30

Diagrama: Dockerfile, Imagen, Docker Hub. ............................................................... 30

Crear una imagen a partir de un Dockerfile ................................................................ 30

Ejecutar un nuevo contenedor usando la imagen creada. ......................................... 33

Subir una imagen local a un repositorio público Docker Hub. .................................... 34

7 Conceptos Amazon Web Services ....................................................................................... 36

Diagrama: AWS - Docker Swarm, Autoscaling Group, Elastic Load Balancing ............ 36

Regiones y Zonas de disponibilidad ............................................................................ 37

7.2.1 Regiones .............................................................................................................. 37

7.2.2 Zona de disponibilidad ........................................................................................ 37

Instancias EC2 - Elastic Compute Cloud ...................................................................... 37

Amazon VPC - Virtual Private Cloud ............................................................................ 38

7.4.1 Crear una VPC ...................................................................................................... 38

7.4.2 Crear tres subredes en tres zonas de disponibilidad distintas ............................ 38

7.4.3 Crear un Internet Gateway .................................................................................. 39

7.4.4 Crear una tabla de rutas para una VPC y subredes. ............................................ 40

7.4.5 Auto asignar una IP pública para cada subred .................................................... 41

7.4.6 Network ACL y Security Group ............................................................................ 41

8 Implementación de Docker Swarm en AWS ....................................................................... 43

Crear una keypair en AWS para conectarse a instancias EC2 ..................................... 43

Crear un instancia EC2 (Docker Gestión) .................................................................... 44

Crear instancias con Docker Machine ......................................................................... 44

8.3.1 IAM: Identity and Access Management .............................................................. 44

8.3.2 Configurar las credenciales de AWS en el sistema local ..................................... 45

8.3.3 Instalación de Docker Machine ........................................................................... 45

8.3.4 Crear los nodos Manager y Worker para Docker Swarm .................................... 46

8.3.5 Establecer variables de entorno para máquinas creadas con Docker Machine . 47

Crear rol manager de un Swarm ................................................................................. 48

8.4.1 Security Group Docker Machine ......................................................................... 49

Crear AMI (Amazon Machine Image) de un nodo Worker.......................................... 50

9 Auto Scaling Groups para Docker Swarm............................................................................ 51

Security Group para nuevas instancias lanzadas con ASG .......................................... 51

¿Qué es Cloud-init? ..................................................................................................... 52

Ciclo de vida de instancias EC2 en Auto Scaling .......................................................... 53

5

9.3.1 Política de terminación de instancias .................................................................. 53

9.3.2 Conceptos: Scale-Up, Scale-In y Scale-Out .......................................................... 54

Crear un Launch Configuration ................................................................................... 55

Crear y configurar: Auto Scaling Group ....................................................................... 57

Opciones del servicio de Auto Scaling Groups ............................................................ 58

9.6.1 ASG: Details ......................................................................................................... 58

9.6.2 ASG: Activity History ............................................................................................ 59

9.6.3 ASG: Scaling Policies (Alertas CloudWatch) ........................................................ 59

9.6.4 ASG: Instances ..................................................................................................... 61

9.6.5 ASG: Monitoring .................................................................................................. 62

9.6.6 ASG: Notifications................................................................................................ 62

9.6.7 ASG: Tags ............................................................................................................. 63

9.6.8 ASG: Scheduled Actions ...................................................................................... 63

9.6.9 ASG: Lifecycle Hooks ........................................................................................... 64

10 ASG con Elastic Load Balancing ........................................................................................... 65

Tipos de Elastic Load Balancer (ELB) ........................................................................... 65

AWS Certificate Manager ............................................................................................ 65

Crear y configurar: Elasctic Load Balancer .................................................................. 66

10.3.1 Balanceo de carga entre zonas en el Classic Load Balancer ................................ 68

Vincular Elastic Load Balancer con Auto Scaling Groups ............................................ 69

ELB: Crear registro DNS tipo CNAME para el dominio web.itgal.es ............................ 70

11 Crear servicios en Docker Swarm ........................................................................................ 72

Docker Visualizer ......................................................................................................... 72

Crear un servicio de la imagen de Wordpress personalizada ..................................... 75

12 Testing de Balanceos entre ELB y Docker Swarm ............................................................... 77

Balanceo de ELB entre instancias y el balanceo de Docker Swarm en el acceso al

servicio web.itgal.es ................................................................................................................ 77

12.1.1 Metadatos de instancia y datos de usuario ........................................................ 79

12.1.2 Habilitar “Stickiness” en Elastic Load Balancer ................................................... 79

Actualización de réplicas: Balanceo entre contenedores con Docker Swarm y entre

Instancias con ELB ................................................................................................................... 81

Balanceo entre ELB y Docker Swarm en nuevas instancias lanzadas con ASG (Scale-

Out)……………………………………………………………….……………………………………………………………………82

Reducir las réplicas en los nodos del Swarm............................................................... 86

Terminar las instancias desplegadas por ASG (Scale-In) ............................................. 87

Script para eliminar nodos en estado “Down” del Swarm .......................................... 89

6

13 Instalación y administración usando Portainer.io, Rancher y Grafana ............................... 91

Instalación de Portainer con Docker Compose ........................................................... 91

Instalación de Portainer con “docker run” .................................................................. 92

Rancher ....................................................................................................................... 97

Grafana - Monitorización de recursos ......................................................................... 99

14 Docker Cloud, Docker Datacenter y AWS Containers ....................................................... 100

Docker Cloud ........................................................................................................... 100

Docker Datacenter................................................................................................... 100

AWS Containers ......................................................................................................... 100

14.3.1 Amazon Elastic Container Service ................................................................... 100

14.3.2 Amazon Elastic Container Service for Kubernetes ............................................ 100

14.3.3 Amazon Elastic Container Registry .................................................................. 101

14.3.4 AWS Fargate ...................................................................................................... 101

15 Costes y presupuesto de servicios e implantación ........................................................... 102

16 Mejoras del proyecto ........................................................................................................ 104

Centralización BBDD Wordpress ............................................................................... 104

Automatización de réplicas del Swarm ..................................................................... 104

Mejorar la tolerancia a fallos .................................................................................... 104

Uso de Kubernetes .................................................................................................... 104

17 Conclusiones...................................................................................................................... 105

Video demo (PoC) y Repositorio Github del proyecto .............................................. 106

18 Bibliografía ........................................................................................................................ 107

19 Autor y Licencia ................................................................................................................. 108

Implementación Docker Swarm en AWS usando ASG y ELB

8 Adrián Gómez Lois

1 OBJETIVOS

En este proyecto se ve como implementar un cluster de nodos con Docker Swarm funcionando en Amazon Web Services usando a su vez para su alta disponibilidad Auto Scaling Groups y Elastic Load Balancing.

La finalidad es ofrecer un sitio web basado en Wordpress usando contenedores Docker. El sitio web será estático, se crea una imagen a partir de un Dockerfile y se sube a un repositorio público como es Docker Hub.

Se implementa Docker Swarm permitiendo el balanceo de carga entre los contenedores de distintos nodos manager y workers. Con Docker Visualizer se muestra el funcionamiento de Docker Swarm, la creación de nuevas tareas réplicas en el servicio que ofrece el sitio web a través de contenedores.

Docker Swarm se integra con Amazon Web Services, los nodos serán instancias EC2 autogestionables y autoescalables horizontalmente de forma elástica usando Auto Scaling Groups, a través de un launch configuration previamente configurado con una AMI y un user data cloud-init.

Mediante políticas de escalado creadas con alertas y gestionadas a su vez desde Cloudwatch, que en base al consumo de CPU y el nivel de transferencia de datos de red si ASG realiza scale-out o scale-in de las instancias, aumentando o disminuyendo la capacidad de máquinas EC2 de la infraestructura virtual.

Para aumetar la disponibilidad, cada instancia gestionada por ASG se crea en una zona de disponibilidad distinta (a, b y c) dentro de la misma región (us-east-2 “Ohio”).

Finalmente para unificar una misma dirección DNS de entrada para cualquiera de las instancias con distintas direcciones IP y también balancear la carga entre instancias EC2 se implementa Elastic Load Balancer Classic para las instancias gestionadas dentro del grupo de auto escalado definido (ASG) y a su vez ELB balancerá la carga de peticiones entre las tres zonas de disponibilidad de la región definida.



2 DOCKER

¿QUÉ NO ES DOCKER?

▪ Un gestor de entornos de desarrollo virtuales (tipo Vagrant). ▪ Un software de virtualización (Hypervisor tipo WMWare, Xen, KVM, Hyper-V). Ya que no

hay un hypervisor debajo (no hay una virtualización) sino simplemente una ejecución bajo contenedor.

▪ Un gestor de configuración (tipo Ansible, Puppet, Chef). ▪ Un simple contenedor de software (tipo LXC).

¿QUÉ ES DOCKER?

Docker es una herramienta para desarrolladores y administradores de sistemas. Ayuda a automatizar el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción eliminando el overhead (sobrecarga/sobrecoste de recursos) que provoca correr un sistema operativo entero virtual para una sola aplicación. Docker está bajo licencia de código abierto Apache 2.0

Además de la propia aplicación que gestiona los contenedores (a la que llamamos Docker Engine), existe un repositorio de imágenes creadas por la comunicada, llamado Docker Hub.

Por tanto, Docker, aunque no deja de ser un sistema de contenedores, va más allá, habiendo creado un ecosistema nuevo donde los desarrolladores y administradores de sistemas pueden compartir sus entornos de trabajo (imágenes).

Gran parte del éxito de Docker se basa en su:

▪ Ligereza: Una imagen de Docker limpia ocupa unos 85MB Debian y 192MB Ubuntu. Sin necesitar los requisitos mínimos de cualquiera de esos dos sistemas.

▪ Portabilidad: Puede desplegarse en cualquier otro sistema operativo con soporte Docker. Permite empaquetar los servicios aislando bibliotecas y dependencias, utilizando un sistema de microservicios los pasos a producción no suponen grandes problemas.

▪ Integración: Puede integrarse con múltiples herramientas para infraestructuras como serivicio (IaaS), facilitando así una gestión específica para cada proeevedor (Amazon Web Services, Microsoft Azure, Google Cloud Platform).

▪ Autosuficiencia: Un contenedor Docker no contiene todo un sistema completo, sino únicamente aquellas librerías, archivos y configuraciones necesarias para desplegar las funcionalidades que contenga. Asimismo, Docker se encarga de la gestión del contenedor y de las aplicaciones que contenga. Genera así la la indepencia y convivencia de aplicaciones heterogéneas en una misma máquina.



MÁQUINAS VIRTUALES VS. CONTENEDORES

Con máquinas virtuales, cuando queremos instalar una aplicación o servicio lo haremos instalando el sistema operativo completo y usando una máquina virtual para cada aplicación o servicio, esto es un problema ya que estamos desperdiciando espacio en disco así como el overhead que provoca al hypervisor tener uno de cada los sistemas operativos completos corriendo.

Con contenedores, se pueden instalar esos microservicios de forma completamente independiente en una misma máquina.

Figura 1: Máquinas Virtuales vs Contenedores Docker

3 COMPONENTES Y CONCEPTOS DOCKER

DOCKER ENGINE (CLIENTE/SERVIDOR)

Docker Engine o simplemente Docker, es una aplicación cliente-servidor. Un servidor que es un tipo de programa llamado proceso de daemon (dockerd). El mismo binario se utiliza tanto en ambos, la diferencia es que uno se lanza en modo cliente y el otro en modo servidor. El servidor crea y administra objetos Docker, como imágenes, contenedores, redes y volúmenes. Opera también junto al Docker Client que a diferencia del servidor este es el encargado de enviar las ordenes a ejecutar por el servidor.

Una API REST que especifica las interfaces que los programas pueden usar para comunicarse con el daemon e indicarle qué hacer. Se puede considerar que el cliente de línea de comandos (CLI) sería el propio comando “docker”.



DOCKER REGISTRY

Docker Registry almacena y permite distribuir imágenes de Docker. Controla donde se almacenan las imágenes, a diferencia de ser un repositorio público como Docker Hub. Se trata de un repositorio privado. Mejorando así la seguridad y velocidad en el momento de descargas las imágenes. Suele estar instalado en un equipo distinto en el que estamos trabajando.

Figura 2: Arquitectura Cliente-Servidor Docker

DOCKER NETWORK

Docker Network es el sistema de conexión de Docker en el que podemos gestionar y administrar las redes de Docker. Los contenedores ni siquiera necesitan saber que están implementados en Docker, Docker puede establecer comunicaciones entre contenedores o fuera del entorno de Docker. Manipula reglas iptables o enrutamiento en servidores Windows.

Después de instalar Docker este crea una interface llamada docker0, la cual usarán el resto de contenedores creados para establecer enrutar la comunicación con el exterior.

Existe un módulo llamado docker-proxy que hará la acción contraria, permitir accesos extern os a los contenedores.

El subsistema de Docker de forma predeterminada hace uso de varios controladores:

▪ Bridge: Asigna a la instancia una IP de la subred de la IP configurada en la interface docker0 ▪ Host: Asigna a la instancia los interfaces de red e IPs de la máquina host. ▪ None: No asigna ningún interfaz de red a la instancia. ▪ Overlay: Las redes superpuestas conectan varios daemons de Docker y permiten que los

servicios de Swarm se comuniquen entre sí.



3.3.1 Puertos en contenedores Docker

▪ Exposed ports: son puertos que un contenedor o servicio está utilizando para proporcionar un servicio o escuchar. De forma predeterminada, los puertos expuestos en Docker solo son accesibles de forma privada. Esto significa que solo otros servicios vinculados al servicio que expone los puertos pueden comunicarse a través del puerto expuesto. Los puertos expuestos no se pueden acceder públicamente a través de Internet. (--expose)

▪ Published ports: son puertos expuestos a los que se puede acceder públicamente a través de Internet. Los puertos publicados se publican en la interfaz de red pública en la que se ejecuta el contenedor en el host. (--publish)

▪ Docker routing mesh

En el caso de usar Docker Swarm el enrutamiento de puertos se hace utilizando el modo Docker routing mesh. Permite que un servicio sea accesible por el mismo puerto en todos los nodos, incluso si el nodo no tiene el servicio desplegado en él.

▪ Puerto 7946 TCP/UP: Para el descubrimiento de red de contenedores. ▪ Puerto 4789 UDP: Para la comunicación de red de contenedores.

Cuando se accede al puerto 8080 en cualquier nodo, Docker enruta la solicitud a un contenedor activo. En los propios nodos del Swarm, el puerto 8080 puede no estar enlazado, pero routing mesh sabe cómo enrutar el tráfico y evita que ocurran conflictos de puertos.

Routing mesh escucha en el puerto publicado de cualquier dirección IP asignada al nodo.

▪ Para direcciones IP enrutables externamente, el puerto está disponible desde fuera del host.

▪ Para todas las demás direcciones IP, el acceso solo está disponible desde el host.

Figura 3: Diagrama de ejemplo del funcionamiento de Routing Mesh en Docker Swarm.

DOCKERFILE

Es un archivo de texto con una serie de instrucciones necesarias que reconoce Docker para automatizar la creación de un contenedor. Se trata de una “receta” que permite construir de forma personalizada la imagen del contenedor.

https://docs.docker.com/engine/swarm/ingress/

https://docs.docker.com/engine/swarm/ingress/



IMAGEN DE DOCKER

Una imagen de Docker es una “plantilla” o captura de estado de un contenedor. Por decirlo de algún modo es un Dockerfile ya construido y listo para usarse. Pueden estar almacenadas en un Docker Hub de forma pública (o privada) o un Docker Registry local. Se pueden descargar de los repositorios y almacenarlas en local para hacer uso de ellas de forma más rápida.

DOCKER HUB

Docker Hub es un repositorio de imágenes de Docker. Permite compartir imágenes construidas por otros usuarios.

De forma gratuita permite crear repositorios públicos ilimitados y solamente un único repositorio privado (siendo de pago el resto de repositorios privados).

Docker Cloud integra los repositorios de Docker Hub, la cuenta de acceso es la misma para ambos servicios web.

VOLÚMENES DE DOCKER

Los volúmenes de Docker es un mecanismo para la persistencia de datos generados y utilizados por los contenedores Docker. Cuando se ejecuta un contenedor sin un volumen de datos asociado todo lo que se modifique en ese contenedor se perderá (no persistente). Será necesario crear un volumen de datos en Docker y asociarlo en el lanzamiento del contenedor. De ese modo, los datos se almacenaran en la máquina local y serán persistentes.

Figura 4: Volúmenes de Docker



4 DOCKER SWARM

DOCKER SWARM

Docker Swarm es un clúster de nodos en los que se incorpora un Docker Engine, se crean utilizando swarmkit. Swarmkit es un proyecto separado que implementa la capa de orquestación de Docker y se usa directamente dentro de Docker.

A partir de la versión de Docker 1.12.0, Docker Swarm está integrado de forma predeterminada.

Los nodos creados con Docker Machine se pueden establecer con roles manager o worker. Puede haber uno o más nodos managers y workers. Estos roles se pueden actualizar, de modo que un nodo worker puede hacer el rol de manager o viceversa, por defecto un manager puede ser manager y worker al mismo tiempo.

Los nodos manager serán los encargados de orquestar los servicios y/o tareas al resto de nodos worker del cluster Swarm.

Tolerancia a fallos: Docker recomienda mantener un número impar de managers para la soportar posibles fallos.

Un nodo manager puede orquestar nodos worker específicos.

Figura 5: Docker Swarm - Managers y Workers

Algunas de las características de Docker Swarm:

▪ Administración de clústeres integrada con Docker Engine. ▪ Diseño descentralizado. ▪ Modelo de servicio declarativo. ▪ Escalado, Swarm se adapta automáticamente al agregado o eliminado de tareas. ▪ Monitoreo centralizado (desde los managers). ▪ Red multi-host. ▪ Swarm asigna un nombre DNS único a los nodos y los contenedores que se ejecutan en

ellos. Puede consultar cada contenedor que se ejecuta en el enjambre a través de un servidor DNS incrustado en el Swarm.

▪ Balanceo de carga. ▪ Autenticación y el cifrado mutuos TLS. ▪ Actualizaciones continuas.



DOCKER MACHINE

Docker Machine es una herramienta que permite crear, configurar y administrar nodos físicos o virtuales a través de drivers o conectores. Instala Docker Engine en hosts virtuales y administrar los hosts Dockerized con los comandos de Docker Machine.

Cuando se crea un nodo se instala boot2docker en él, una distribución muy liviana del sistema operativo Linux (Tiny Core Linux) que incluye Docker Engine en su interior.

Se pueden aprovisionar hosts Dockerized en la nube usando la autenticación oportuna con el servicio cloud e indicando el driver como parámetro según el proveedor: Amazon Web Services, Microsoft Azure, OpenStack, DigitalOcean, VMware vCloud Air, Hyper-V, etc.

Figura 6: Docker Machine

DOCKER COMPOSE

Docker Compose permite desplegar y administrar aplicaciones compuestas por varios contenedores relacionados entre sí. Utiliza un archivo YAML para configurar los servicios.

▪ Define el entorno de la aplicación con una Dockerfile para que pueda reproducirse en cualquier lugar.

▪ Define los servicios que conforman la aplicación docker-compose.yml para que puedan ejecutarse juntos en un entorno aislado (contenedores independientes).

DOCKER SERVICES

Para implementar una imagen de aplicación en Docker Swarm, se crea un servicio. Un servicio es la imagen de un microservicio en el contexto de una aplicación más grande, cada uno de ellos será un contenedor de Docker.

Cuando se crea un servicio, se especifica que imagen de contenedor usar y que comandos se ejecutarán dentro de los contenedores en ejecución.



El servicio se ubica en el Docker Swarm Manager, que lo despliega en el resto de nodos creados a través de tareas, cada una de ellas invoca a un contenedor con una imagen, que será la misma para todos.

Figura 7: Docker Services

Para estos casos la terminología correcta para referirse a cada réplica no es contenedores si no tareas. Estas tareas son desplegadas en contenedores.

STACK DE SERVICIOS

Un stack de servicios es un conjunto de servicios que se ejecutan a la vez. Estos servicios son definidos en un archivo en formato YAML (similar al docker-compose.yml).

Los stack son la forma de implementar automáticamente varios servicios que están vinculados entre sí, sin necesidad de definir cada uno por separado. En ellos se recogen especificaciones y características de cada servicio.

Los nodos manager asignan tareas a los nodos worker de acuerdo con el número de réplicas establecidas en el servicio. Una vez se asigna una tarea a un nodo, no se puede mover a otro nodo. Solo puede ejecutarse en el nodo asignado.



5 TRABAJANDO CON DOCKER

INSTALACIÓN DOCKER EN UBUNTU 18.04

5.1.1 Instalación Docker

Actualizar los repositorios existentes.

sudo apt update

Instalar paquetes previos que permitan a apt usar paquetes a través de HTTPS.

sudo apt install apt-transport-https ca-certificates curl software-properties-common

Agregar la clave GPG del repositorio oficial de Docker.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Agregar el repositorio de Docker en las fuentes de APT.

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable"

Finalmente, se instala Docker.

sudo apt install docker-ce

Se comprueba que el daemon de Docker está iniciado y el proceso está habilita para iniciarse en el arranque.

sudo systemctl status docker

Si no estuviese iniciado y/o habilitado para el arranque del sistema.

sudo systemctl start docker

sudo systemctl enable docker

5.1.2 Ejecutar el comando Docker sin sudo o desde otro usuario

De forma predeterminada el comando Docker solo puede ser ejecutado por el usuario root o por un usuario del grupo docker. Donde “username” sería el nombre del usuario.

sudo usermod -aG docker username

Para comprobar que el usuario forma parte del grupo docker se pude ejecutar.

id -nG



REFERENCIA COMANDOS DOCKER

Mencionar simplemente algunos comandos básicos de Docker, siendo este apartado como una pequeña guía de referencia.

https://docs.docker.com/engine/reference/commandline/docker

5.2.1 Comandos gestión Docker

Listar contenedores en ejecución. Listar todos los contenedores en ejecución y parados (-a indica todos).

docker ps –a

Listar imágenes descargadas en local (-a muestra todas las imágenes incluidas las intermedias).

docker images

Descargar imagen a caché local desde un repositorio público.

docker pull ubuntu:18.04

Loguearse en Docker Hub, será necesario estar autenticado para subir (push) una imagen.

docker login

docker login -u <usuario> -p <password>

Subir una imagen a un repositorio (Docker Hub).

docker push <imagen_local>

Crear una imagen de un contenedor personalizado en ejecución.

docker commit <ID o nombre_contenedor> <nombre_imagen_nueva>

Para subir una imagen creada a un repositorio como puede ser Docker Hub, es neecsario “tagearla” antes.

docker tag <imagen_local> <nombre_tag_imagen>

docker push <nombre_tag_imagen_creada>

Construir una imagen a partir de un Dockerfile. (--file será necesario si el nombre del fichero no es “Dockerfile” y no está situado el mismo directorio)

docker build --tag <nombre_imagen> --file <fichero_dockerfile>

Eliminar una imagen local (-f o --force fuerza la eliminación).

docker rmi <id o nombre_imagen>

https://docs.docker.com/engine/reference/commandline/docker



Eliminar un contenedor, si el contenedor está en ejecución será necesario detenerlo (docker stop <contenedor>) antes de eliminarlo se puede indicar el parámetro -f o --force (esto fuerza la detención y eliminación del contenedor).

docker rm <id o nombre_imagen>

Eliminar todos contenedores, redes, imágenes o volúmenes "colgantes" sin referencia o no utilizados

docker system prune

#Parámetros

--all #Eliminar todas las imágenes no utilizadas, no solo las que cuelgan.

--force #Forzar el eliminado, no pedir confirmación.

--volumes #Eliminar volúmenes no utilizados o colgantes.

--filter #Proporcionar valores de filtro.

Crear e iniciar un contenedor basado en una imagen Ubuntu 18.04, que ejecuta una Shell en modo interactivo (-it) como entrypoint.

docker run –name <nombre_contenedor> -h <nombre_hostname> -it ubuntu:18.04 /bin/bash

Crear y ejecutar un contenedor con un comando/servicio en segundo plano un comando como entrypoint (-d modo detached, no interactivo) (-c comando dentro del modo interactivo bash).

docker run -d --name <nombre_contenedor> -h <hostname> <nombre_imagen> bash -c "<comando>"

docker run -d --name mi_web -h web ubuntu_web bash -c "apache2ctl -D FOREGROUND"

Crear e iniciar un contenedor en modo interactivo con una Shell (-i interactivo -t asociar una tty)

docker run -it --name test debian bash

Crear contenedores. El contenedor se crea pero no se inicia (sería necesario usar después docker start). “docker créate” dispone de multitud parámetros.

docker create -it --storage-opt size=120G fedora /bin/bash

Iniciar, detener y reiniciar contenedores.

docker start <id o nombre_imagen>

docker stop <id o nombre_imagen>

docker restart <id o nombre_imagen>

Publicar puertos en contenedores (aunque se ejecute una imagen que ya predefina exposición de puertos, igualmente habría que establecerlos en la ejecución del contenedor).

#Publicar el puerto 80 del contenedor en un puerto aleatorio del host.

docker run -it --name test -p 80 debian bash



#Publicar el puerto 80 del contenedor al 8080 del host.

docker run -it --name test -p 8080:80 debian test

#Publicar todos los puertos expuestos a puertos aleatorios del host.

docker run -it --name test -P debian bash

Listar los puertos de contenedores.

docker port <id o nombre_imagen>

Finalizar (matar) contenedores.

docker kill <id o nombre_imagen>

Buscar registros de logs de contenedores (-f muestra logs a tiempo real).

docker logs -f <id o nombre_imagen>

Mostrar los procesos en ejecución de contenedores.

docker top <id o nombre_imagen>

Buscar imágenes en repositorios (Docker Hub).

docker search <término>

Importar, exportar y guardar imágenes en un archivo tar.

docker save --outpout <nombre_contenedor> <nombre_empaquetado_contenido.tar>

docker export --output <nombre_contenedor> <nombre_empaquetado_contenido.tar>

docker import <nombre_empaquetado_contenido.tar> <nombre_contenedor>

Cargar una imagen desde un archivo tar o STDIN (Standard Input).

docker load --input <test.tar>

Gestionar Docker.

docker df #Mostrar el uso del disco docker.

docker system events o docker events #Mostrar eventos en tiempo real.

docker system info o docker info #Mostrar información de todo el sistema.

Desactivar procesos de contenedores.

docker unpause <id o nombre_imagen>



Actualizar la configuración de contenedores.

docker update <id o nombre_imagen>

Mostrar la versión de Docker.

docker version

Inspeccionar cambios de archivos o directorios de contenedores.

docker diff <id o nombre_imagen>

Inspeccionar contenedores (devuelve información de bajo nivel).

docker inspect <id o nombre_imagen>

Mostrar estadísticas de uso de los recursos de contenedores (CPU, Memoria, I/O, PIDs).

docker stats #Muestra todos los contenedores actuales en ejecución.

docker stats <id o nombre_imagen>

Gestionar volúmenes Docker.

docker volume create #Crear un volumen.

docker volume inspect #Mostrar información detallada de volúmenes.

docker volume ls #Listar volúmenes.

docker volume rm #Eliminar volúmenes.

docker volume prune #Eliminar volúmenes locales no utilizados.

Gestión de redes Docker.

docker network create #Crear una red.

docker network connect #Conectar un contenedor a una red.

docker network disconnect #Desconectar un contenedor de una red.

docker network inspect #Mostrar información detallada de redes.

docker network ls #Listar redes.

docker network rm #Eliminar redes.

docker network prune #Eliminar todas las redes no utilizadas.

Montar un volumen de un directorio local en un contenedor (útil para trabajar con volúmenes de datos que se están editando habitualmente).

docker run -it -v /home/user/codigoWeb:/var/www/html debian bash

Crear un contenedor que usará un volumen asociado a otro contenedor existente.

#Crear el contenedor sin bash, simplemente para tenerlo como referencia para crear posteriormente otros contenedores basados en este usando su volumen de datos como referencia.



docker run -it -v /tmp:/var/www/html --name container_code debian /bin/false

#Asociar el volumen creado en el contenedor anterior con un nuevo contenedor usando el ID del contenedor.

docker run -it --name code -h code --volumenes-from ec3456a3d16cb debian bash

Copiar datos desde el contenedor al host local (opcional -a --archive copia toda la información uid/gid).

docker cp -a <id_contenedor>:<path_contenedor> <path_host_local>

Copiar desde el host local al contenedor.

docker cp -a <path_host_local> <id_contenedor>:<path_contenedor>

Ejecutar un comando en un contenedor en ejecución. Por ejemplo una Shell bash en modo interactivo (útil para acceder a un contenedor en ejecución).

https://docs.docker.com/engine/reference/commandline/exec

docker exec -it nombre_contenedor /bin/bash

docker exec -it nombre_contenedor /bin/sh

▪ Salir de un contenedor con bash interactivo

# Con la combinación de teclas: Ctrl+p+q

# exit: si el contenedor se inició en modo --detach o -d

▪ Live restore Docker

Permite que los contenedores permanezcan en ejecución aunque el daemon no esté disponible (por ejemplo en un reinicio del daemon dockerd). Ayuda a reducir la inactividad del contenedor debido a fallas del daemon, interrupciones planificadas o actualizaciones.

https://docs.docker.com/config/containers/live-restore

Para habilitar es necesario crear el fichero “/etc/docker/daemon.json”, con el contenido.

{

"live-restore": true

}

▪ Iniciar contenedores automáticamente

Iniciar automáticamente un contenedor con “--restart always” se trata de una política de reinicio que siempre reinicia el contenedor si este se detiene (útil para auto iniciar el contenedor después de reiniciar la máquina host).

docker run -d --restart always --name test -h test debian

https://docs.docker.com/engine/reference/commandline/exec

https://docs.docker.com/config/containers/live-restore/



#Políticas de reinicio automático de contenedores

no #No reinicia automáticamente el contenedor. (valor por defecto)

on-failure #Reinicia el contenedor si sale debido a un error.

unless-stopped #Reinicia el contenedor a menos que se detenga explícitamente o el propio Docker se detenga o reinicie.

always #Siempre reinicia el contenedor si se detiene.

5.2.2 Comandos Docker Swarm

Referencia de comandos Docker Swarm.

https://docs.docker.com/engine/reference/commandline/swarm

https://docs.docker.com/engine/reference/commandline/swarm_update

Iniciar, unirse, dejar y actualizar un cluster Swarm.

docker swarm init #Inicializar un Swarm.

docker swarm join #Unirse a un Swarm como nodo worker y/o manager (dependiendo si se trata de un –token manager o worker).

docker swarm leave #Dejar un Swarm.

docker swarm update #Actualizar un Swarm, dispone de varias opciones.

5.2.3 Comandos Docker Machine

Referencia de comandos Docker Machine.

https://docs.docker.com/machine/reference

docker-machine create #Crear un nodo.

docker-machine kill #Detener una nodo.

docker-machine ls #Listar nodos.

docker-machine ssh #Iniciar sesión en un nodo activo.

docker-machine rm #Eliminar un nodo.

docker-machine env #Establecer variables de entorno para definir que docker debe ejecutar un comando en una máquina en particular.

Crear dos nodos usando driver de Amazon Web Services, estableciendo región y zona de disponibilidad, red VPC y tamaño de disco.

docker-machine create --driver amazonec2 --amazonec2-region "us-east-2" --amazonec2-zone "b" --amazonec2-vpc-id vpc-0d1dd38... --amazonec2-root-size 8 test

5.2.4 Comandos Docker Node

Referencia de comandos Docker Node.

https://docs.docker.com/engine/reference/commandline/node

docker node inspect #Mostrar información detallada en uno o más nodos.

docker node ls #Listar nodos del Swarm.

https://docs.docker.com/engine/reference/commandline/swarm/

https://docs.docker.com/engine/reference/commandline/swarm_update

https://docs.docker.com/machine/reference

https://docs.docker.com/engine/reference/commandline/node



docker node ps #Enumerar las tareas que se ejecutan en uno o más nodos.

docker node rm #Eliminar uno o más nodos del Swarm.

docker node update #Actualizar un nodo.

Promover un nodo worker a manager.

docker node promote <nodo>

Degradar un nodo manager a worker.

docker node demote <nodo>

Cambiar nodo a solo Manager y no Manager+Worker (que sería la función por defecto).

docker node update --availability drain <nodo>

▪ Docker node update

Referencia de comandos Docker node update.

https://docs.docker.com/engine/reference/commandline/node_update

--availability #Disponibilidad del nodo ("active"|"pause"|"drain").

--label-add #Agregar o actualizar una etiqueta de nodo (key=value).

--label-rm #Eliminar una etiqueta de nodo si existe.

--role #Rol del nodo ("worker"|"manager").

5.2.5 Comandos Docker Service

Referencia de comandos Docker Service.

https://docs.docker.com/engine/reference/commandline/service

docker service create #Crear un nuevo servicio.

docker service inspect #Mostrar información detallada sobre uno o más servicios.

docker service logs #Obtener los registros de un servicio o tarea.

docker service ls #Listar servicios.

docker service ps #Listar las tareas de uno o más servicios.

docker service rm #Eliminar uno o más servicios.

docker service rollback #Revertir cambios a la configuración de un servicio.

docker service scale #Escalar uno o múltiples servicios replicados.

docker service update #Actualizar un servicio.

Crear un servicio. Se debe crear desde un nodo manager.

▪ --publish: Publicar puertos ▪ --replicas: Número de réplicas totales a repartir entre los nodos existentes. ▪ --update-parallelism: Ejecución del número de contenedores/tareas por nodo. ▪ --update-delay: Retraso entre las actualizaciones (ms|s|m|h) ▪ --restart-condition on-failure: Reiniciar la tarea en caso de fallo. ▪ --constraint node.role manager: Los nodos solo admitirán tareas de un nodo manager ▪ test: Imagen a ejecutar.

https://docs.docker.com/engine/reference/commandline/node_update

https://docs.docker.com/engine/reference/commandline/service



docker service create --name test -p 80:80 --replicas 3 --update-parallelism 1 --update-delay 5s --restart-condition on-failure --constraint 'node.role == manager' test

Otra forma de crear un servicio es añadiendo \ para un salto de línea y seguir definiendo los parámetros del servicio.

docker service create \

--name test \

--publish 80:80 \

--replicas 3 \

--update-parallelism 1 \

--update-delay 5s \

--restart-condition on-failure \

--constraint 'node.role == manager' \

test

▪ Docker service update

Referencia de comandos Docker service update.

https://docs.docker.com/engine/reference/commandline/service_update

Actualizar réplicas de un Swarm de modo que se pueda controlar un escalado elástico.

docker service update --replicas=50 test

docker service scale test=50

Forzar actualización de un servicio, incluso si ningún cambio lo requiere. Útil para actualizar un cluster de nodos Swarm en los que se actualizaron réplicas en un servicio con un paralelistmo concreto y Docker Swarm ignoró el balanceo de tareas (replicas del servicio) a nuevos nodos worker unidos al Swarm.

docker service update --force test

5.2.6 Comandos Docker Compose

Referencia de comandos Docker Compose.

https://docs.docker.com/compose/gettingstarted (docker-compose --help)

docker-compose up #Crear y ejecutar los servicios y ver el proceso.

docker-compose up -d #Crear y ejecutar los servicios en segundo plano, seguir desde la misma tty.

docker-compose run <servicio> <comando> #Ejecutar un comando único para un servicio concreto.

docker-compose stop #Parar todos los servicios.

docker-compose down #Eliminar los servicios.

docker-compose down --volumes #Eliminar los servicios y los volúmenes asociados.

docker-compose ps #Listar los servicios.

docker-compose ps --services #Listar solo los nombres de los servicios.

docker-compose restart #Reiniciar los servicios.

Docker-compose rm #Parar y eliminar los servicios.

https://docs.docker.com/engine/reference/commandline/service_update

https://docs.docker.com/compose/gettingstarted



5.2.7 Comandos Docker Stack

Referencia de comandos Docker Stack.

https://docs.docker.com/engine/reference/commandline/stack

docker stack deploy #Implementar o actualizar un stack.

docker stack ls #Lista de pilas.

docker stack ps #Listar las tareas en la pila.

docker stack rm #Eliminar una o más pilas.

docker stack services #Listar los servicios en la pila.

Implementar o actualizar un stack a partir de un fichero “Docker-Compose”. Debe ejecutarse desde un nodo manager.

docker stack deploy --compose-file docker-compose.yml test

https://docs.docker.com/engine/reference/commandline/stack



CREANDO UN DOCKERFILE

Se construirá un fichero llamado “Dockerfile” el cual:

▪ Partirá de una imagen limpia de Debian. ▪ Instalará los paquetes: net-tools, curl, mysql, apache2, php y otros paquetes necesarios

relacionados: wget, nano, curl, openssh-server y supervisor. ▪ Creará una BBDD Worpress con usuario y password y le otorgará permisos. ▪ Copiará un contenido de una instalación previamente configurada con un theme

personalizado y adaptado de Worpress, asignará el propietario www-data al directorio. ▪ Creará un directorio en el contenedor y copiará en él los certificados SSL para el dominio

de la web. (Del dominio “itgal.es” adquirido a través del registrar (registrador) 1&1). ▪ Copiará dos ficheros Virtualhost previamente configurados al servidor Apache2 del

contenedor y habilitará los módulos utilizados y necesarios para Apache2. ▪ Creará y configurará un usuario para para la conexión SSH al contenedor. ▪ Establecerá un banner motd personalizado. ▪ Expondrá públicamente los puertos para SSH/22, HTTP/80 y HTTPS/443. ▪ Establecerá como entrypoint (CMD) del contenedor la ejecución de supervisord.

Los ficheros referenciados deberán estar en el mismo directorio donde esté el fichero Dockerfile.

FROM debian

MAINTAINER adrianlois <[email protected]>

## Instalación y configuración mysql

RUN apt-get update

RUN apt-get install -y net-tools

RUN apt install -y sudo

RUN echo "mysql-server-5.7 mysql-server/root_password password abc123." | debconf-set-selections

RUN echo "mysql-server-5.7 mysql-server/root_password_again password abc123." | debconf-set-selections

## Instalación de servicios y librerías

RUN apt-get install -y apache2 php-mysql php libapache2-mod-php mysql-server wget nano curl

## Establecer permisos mysql

RUN /etc/init.d/mysql start && mysql -uroot -pabc123. -e "create database wordpress" && mysql -uroot -pabc123. -e "grant all on wordpress.* to 'wordpress'@'localhost' identified by 'abc123.';flush privileges"

##############

#### OPCION 1: Descargar, descomprimir e instalar Wordpress desde cero

##############

# Descargar y descomprimir Wordpress

#RUN cd /tmp;wget https://wordpress.org/latest.tar.gz

#RUN cd /var/www/html; rm index.html; tar xvzf /tmp/latest.tar.gz; mv wordpress/* .; rm -rf wordpress

# Copiar wp-config.php al directorio Wordpress

#COPY wp-config.php /var/www/html/wp-config.php



##############

#### OPCION 2: Copiar Wordpress con plantilla previamente configurada y adaptada.

##############

# Copiar Wordpress con plantilla modificada, configuraciones y wp-config.php

RUN cd /var/www/html; rm index.html

COPY webitgal/ /var/www/html/

# Establecer permisos en el directorio donde trajará apache

RUN chown -R www-data:www-data /var/www/html

# Agregar certificados SSL Web ITGAL

RUN mkdir /certificados

COPY itgal.es_private_key.key /certificados/itgal.es_private_key.key

COPY itgal.es_ssl_certificate.cer /certificados/itgal.es_ssl_certificate.cer

RUN chown -R root:www-data /certificados

RUN chmod -R 755 /certificados

# Copiar VirtualHosts Apache2

COPY itgal-http.conf /etc/apache2/sites-available/itgal-http.conf

COPY itgal-https.conf /etc/apache2/sites-available/itgal-https.conf

# Habilitar sitios y modulos Apache2

RUN a2enmod rewrite ; a2enmod ssl ; a2dissite 000-default.conf ; a2ensite itgal-http.conf ; a2ensite itgal-https.conf

RUN /etc/init.d/apache2 restart

# Agregar usuario raso para conexión por SSH

RUN mkdir /home/adrian ; useradd adrian -d /home/adrian -s /bin/bash

RUN echo "adrian:abc123." | chpasswd adrian

RUN echo "adrian ALL=(ALL:ALL) ALL" > /etc/sudoers

# Instalar y configurar servidor SSH

RUN apt-get install -y openssh-server

RUN mkdir /var/run/sshd

RUN echo "Port 22" >> /etc/ssh/sshd_config

RUN echo "ListenAddress 0.0.0.0" >> /etc/ssh/sshd_config

RUN echo "PermitRootLogin no" >> /etc/ssh/sshd_config

RUN echo "AllowUsers adrian" >> /etc/ssh/sshd_config

## Configuración de Supervisord

RUN apt-get install -y supervisor

COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf

## Establecer banner motd

RUN mv /etc/motd /etc/motd.bak

COPY motd /etc/motd

## Abrir puertos: SSH, HTTP, HTTPS

EXPOSE 22 80 443

## Comando en el que se ejecutará el contenedor. Supervisa en un único daemon los servicios: SSH, Apache2 y Mysql

CMD ["/usr/bin/supervisord"]



5.3.1 ¿Qué es Supervisor?

En el contexto de Docker cuando se ejecuta un contenedor y se accede a él de forma interactiva mediante bash y posteriormente se necesita salir de contenedor usando “Ctrl+c” se finalizada la ejecución del contenedor y con ello los servicios corriendo en él.

Es posible salir de un modo interactivo sin detener un contenedor:

▪ Tecleando “exit”. ▪ La combinación de teclas “Ctrl+p+q”. ▪ Instalar un servidor SSH en el contenedor y en el momento de iniciar el contenedor exponer

el puerto 22, de modo que sea posible conectarse por SSH.

Supervisor es un sistema cliente/servidor que permite monitorear y controlar una serie de procesos. Supervisord inicia los procesos como subprocesos y puede configurarse para que se reinicien automáticamente en caso de bloqueo, así como también configurarse para iniciar procesos en su propia invocación.

De ese modo, y siguiendo el caso del Dockerfile anterior, al lanzar supervisord este puede iniciar los servicios de ssh, apache2 y mysql. Si es bien es verdad que se podría utilizar un bash script para un entrypoint en el lanzamiento del contendor de Docker, supervisor es una buena alternativa a tener en cuenta. http://supervisord.org. Otras alternativas similares podrían ser: systemd o upstart.

La estructura del fichero “supervisord.conf” para este caso sería la siguiente:

[supervisord]

nodaemon=true

[program:sshd]

command=/usr/sbin/sshd -D

autorestart=true

autostart=true

user=root

[program:apache2]

command=/bin/bash -c "source /etc/apache2/envvars && exec /usr/sbin/apache2 -DFOREGROUND"

autorestart=true

autostart=true

user=root

[program:mysql]

command=/usr/bin/pidproxy /var/run/mysqld/mysqld.pid /usr/sbin/mysqld &

autorestart=true

autostart=true

user=root

http://supervisord.org/

https://freedesktop.org/wiki/Software/systemd

http://upstart.ubuntu.com/



6 CREAR UNA IMAGEN WORDPRESS PERSONALIZADO

DIAGRAMA: DOCKERFILE, IMAGEN, DOCKER HUB.

Continuando el esquema del proyecto, con el Dockerfile elaborado anteriormente se construye una imagen y se sube a un repositorio público de Docker Hub.

Figura 8: Diagrama - Dockerfile (Wordpress, Apache2, MySQL, SSH y Supervisor) > Imagen > Docker Hub.

CREAR UNA IMAGEN A PARTIR DE UN DOCKERFILE

Basándose en el Dockerfile anterior, se crea una imagen basada en un sistema operativo Debian con un Wordpress instalado y configurado. En el directorio de trabajo actual estarían los siguientes ficheros.

root@docker-1:~/docker# ls

Dockerfile itgal-http.conf supervisord.conf

itgal.es_private_key.key itgal-https.conf webitgal

itgal.es_ssl_certificate.cer motd

Se usan certificados SSL para el dominio DNS “itgal.es” que es el dominio principal utilizado para este proyecto. El directorio “webitgal” contiene todos los ficheros Wordpress (theme adaptado y personalizado, wp-config.php, etc.), los Virtualhost definidos para el sitio web que usará Apache2.

Hay dos ficheros Virtualhost, uno para las peticiones al puerto 80 HTTP que hará redirección de la raíz al servername “web.itgal.es” al fichero escuchando peticiones por el puerto 443 HTTPS.

root@docker-1:~/docker# cat itgal-http.conf

<VirtualHost *:80>

ServerName web.itgal.es

Redirect / https://web.itgal.es/

</VirtualHost>

root@docker-1:~/docker# cat itgal-https.conf

<IfModule mod_ssl.c>

<VirtualHost *:443>

ServerName web.itgal.es

ServerAdmin [email protected]

DocumentRoot /var/www/html

SSLEngine on

SSLCertificateFile /certificados/itgal.es_ssl_certificate.cer



SSLCertificateKeyFile /certificados/itgal.es_private_key.key

<Directory /var/www/html>

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Order allow,deny

allow from all

</Directory>

<FilesMatch "\.(cgi|shtml|phtml|php)$">

SSLOptions +StdEnvVars

</FilesMatch>

<Directory /usr/lib/cgi-bin>

SSLOptions +StdEnvVars

</Directory>

ErrorLog ${APACHE_LOG_DIR}/itgal-https-error.log

CustomLog ${APACHE_LOG_DIR}/itgal-https-access.log combined

</VirtualHost>

</IfModule>

El contenido más relevante del fichero “wp-config.php” establece los datos de conexión a la BBDD MySQL y define las URLs de acceso al sitio web.

root@docker-1:~/docker/webitgal# cat wp-config.php

...

/** Nombre de la base de datos de WordPress */

define('DB_NAME', 'wordpress');

/** Nombre del usuario de MySQL */

define('DB_USER', 'wordpress');

/** Contraseña de MySQL */

define('DB_PASSWORD', 'aGht4yx9U');

/** Host de MySQL (es muy probable que no necesites cambiarlo) */

define('DB_HOST', 'localhost');

/** Codificación de caracteres para la base de datos. */

define('DB_CHARSET', 'utf8');

/** Cotejamiento de la base de datos. No lo modifiques si tienes dudas. */

define('DB_COLLATE', '');

/** Definir direcciones URLs **/

define('WP_HOME','https://web.itgal.es');

define('WP_SITEURL','https://web.itgal.es');

...



Se lanza el comando para construir la imagen basada en el Dockerfile anterior. Al estar el fichero el mismo path y tener el nombre por defecto “Dockerfile” no es necesario indicar el parámetro --file.

root@docker-1:~/docker# docker build --tag webitgal $(pwd)

Sending build context to Docker daemon 68.46MB

Step 1/36 : FROM debian

latest: Pulling from library/debian

bc9ab73e5b14: Pull complete

Digest: sha256:802706fa62e75c96fff96ada0e8ca11f570895ae2e9ba4a9d409981750ca544c

Status: Downloaded newer image for debian:latest

---> be2868bebaba

Step 2/36 : MAINTAINER adrianlois <[email protected]>

---> Running in 7ac5511488b7

Removing intermediate container 7ac5511488b7

---> ec54365bf1ad

Step 3/36 : RUN apt-get update

---> Running in b3270a39b676

Get:1 http://security.debian.org/debian-security stretch/updates InRelease [94.3 kB]

Ign:2 http://cdn-fastly.deb.debian.org/debian stretch InRelease

Get:3 http://cdn-fastly.deb.debian.org/debian stretch-updates InRelease [91.0 kB]

Get:4 http://cdn-fastly.deb.debian.org/debian stretch Release [118 kB]

... ...

Step 34/36 : COPY motd /etc/motd

---> 0c4303d234a9

Step 35/36 : EXPOSE 22 80 443

---> Running in fcbcb6eb0633

Removing intermediate container fcbcb6eb0633

---> d76f5f396a27

Step 36/36 : CMD ["/usr/bin/supervisord"]

---> Running in 88201031e0ce

Removing intermediate container 88201031e0ce

---> 76ce174aec68

Successfully built 76ce174aec68

Successfully tagged webitgal:latest

Se listan las imágenes actuales disponibles en local.

root@docker-1:~/docker# docker images

REPOSITORY TAG IMAGE ID CREATED SIZE

webitgal latest 76ce174aec68 4 minutes ago 887MB

debian latest be2868bebaba 2 weeks ago 101MB



EJECUTAR UN NUEVO CONTENEDOR USANDO LA IMAGEN CREADA.

Para lanzar la imagen en local, se ejecuta un nuevo contenedor con los parámetros necesarios referenciando la imagen “webitgal”.

root@docker-1:~/docker# docker run -d --name webitgal -h webitgal -p 80:80 -p 443:443 -p 2222:22 webitgal

d6b96a46308dabf80a02538621bee1e72380e4f82298c2258453b81b05f2b94d

root@docker-1:~/docker# docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

d6b96a46308d webitgal "/usr/bin/supervisord" 6 seconds ago Up 5 seconds 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:2222->22/tcp webitgal

Se puede acceder al contenedor con bash usando docker exec y comprobar que los puertos estén escuchando, certificados y el contenido del sitio web de Wordpress. Con exit se sale del contenedor sin detener los servicios ni el contenedor, también se podría utilizar la combinación de teclas “Ctrl+p+q”.

root@docker-1:~/docker# docker exec -it webitgal bash

root@webitgal:/# netstat -paton

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name Timer

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 10/apache2 off (0.00/0/0)

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 8/sshd off (0.00/0/0)

tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 10/apache2 off (0.00/0/0)

root@webitgal:/# ls /certificados

itgal.es_private_key.key itgal.es_ssl_certificate.cer

root@webitgal:/# ls /var/www/html

index.php wp-activate.php wp-comments-post.php wp-content wp-links-opml.php wp-mail.php wp-trackback.php

license.txt wp-admin wp-config-sample.php wp-cron.php wp-load.php wp-settings.php xmlrpc.php

readme.html wp-blog-header.php wp-config.php wp-includes wp-login.php wp-signup.php

root@webitgal:/# exit

exit

root@docker-1:~/docker#



Al publicar el puerto 22 del contenedor al puerto 2222 del host, se puede acceder por SSH desde una terminal independiente, IP_HOST:2222 con el usuario y contraseña creados en el fichero Dockerfile.

El usuario adrian puede elevarse a root ya que se le había indicado en el Dockerfile que se añadiera al fichero /etc/sudoers con todos los permisos.

También se cargará el banner motd que se había copiado y establecido en el fichero Dockerfile para la creación de esta imagen.

login as: adrian

[email protected]'s password:

Linux webitgal 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64

#=========================================================#

# _____ _______ _____ _ #

# |_ _|__ __/ ____| /\ | | #

# ______ | | | | | | __ / \ | | ______ #

# |______| | | | | | | |_ | / /\ \ | | |______| #

# _| |_ | | | |__| |/ ____ \| |____ #

# |_____| |_| \_____/_/ \_\______| #

# #

# @adrianlois_ #

#=========================================================#

adrian@webitgal:~$ sudo su

We trust you have received the usual lecture from the local System

Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.

#2) Think before you type.

#3) With great power comes great responsibility.

[sudo] password for adrian:

root@webitgal:/home/adrian#

SUBIR UNA IMAGEN LOCAL A UN REPOSITORIO PÚBLICO DOCKER HUB.

Una vez se comprueba que la imagen está bien configurada y que todo funciona correctamente.

Se sube la imagen local a un repositorio público de Docker Hub.

▪ Loguearse en una cuenta de Docker Hub (previamente creada a través del sitio web oficial). ▪ Se taguea la imagen: usuarioDockerHub/nombreImagen (se genera una réplica de la

imagen, con el mismo ID). ▪ Se sube la imagen tagueada al repositorio público de la cuenta de Docker Hub.

root@docker-1:~/docker# docker login

Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.

Username: adryanaws

Password:



WARNING! Your password will be stored unencrypted in /root/.docker/config.json.

Configure a credential helper to remove this warning. See

https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded





root@docker-1:~/docker# docker tag webitgal adryanaws/webitgal



adryanaws /webitgal latest 76ce174aec68 45 minutes ago 887MB



root@docker-1:~/docker# docker push adryanaws/webitgal

The push refers to repository [docker.io/adryanaws/webitgal]

ffb930791b09: Pushed

e8920398be30: Pushed

... ...

eb2c5243c935: Pushed

7a4e93bf2d05: Pushed

f715ed19c28b: Mounted from library/debian

latest: digest: sha256:466134f1ccfc90e1fac1cee7a9f76c708899c006064b211adbed7791cac2ed09 size: 7209

La imagen “webitgal” ha sido subida al repositorio público de Docker Hub en la cuenta adryanaws.

Para poder utilizar esta imagen se tendría que descargar usando: docker pull adryanaws/webitgal.

https://hub.docker.com/r/adryanaws/webitgal

https://cloud.docker.com/repository/docker/adryanaws/webitgal

Figura 9: Imagen subida a un repositorio público Docker Hub.

https://hub.docker.com/r/adryanaws/webitgal

https://cloud.docker.com/repository/docker/adryanaws/webitgal



7 CONCEPTOS AMAZON WEB SERVICES

DIAGRAMA: AWS - DOCKER SWARM, AUTOSCALING GROUP, ELASTIC LOAD

BALANCING

Figura 10: Esquema infraestructura AWS - Docker Swarm, Autoscaling Group, Elastic Load Balancing.



REGIONES Y ZONAS DE DISPONIBILIDAD

Cada región es totalmente independiente y cada zona de disponibilidad está aislada, pero las zonas de disponibilidad de una región están conectadas a través de conexiones de baja latencia.

Figura 11: Regiones y Zonas de disponibilidad en AWS.

7.2.1 Regiones

Cada región de Amazon EC2 se ha diseñado para que esté totalmente aislada de las demás regiones. Con ello se consigue una mayor tolerancia a fallos y estabilidad.

Solo se verán los recursos que estén vinculados a la región especificada. De forma automática los recursos no se replican para distintas regiones. Las regiones se definen; por ejemplo, us-east-1a, siendo “us-east-1” la región y “a” la zona de disponibilidad de esa región.

En https://www.cloudping.info se puede comprobar la latencia desde la ubicación actual a la región que más nos convenga. Normalmente si nos encontramos en la misma región o muy cerca alguna que AWS tenga sus data center suele ser la aconsejable y de menor latencia, pero no siempre es así.

7.2.2 Zona de disponibilidad

Cuando se lanza una instancia, esta se puede seleccionar a una zona de disponibilidad o dejar que AWS la seleccione de forma automática. Las instancias EC2 se deben crear en zonas de disponibilidad distintas de modo que se garantice una mayor disponibilidad.

Una zona de disponibilidad está representada por un código de región seguido de un identificador de letra; por ejemplo, us-east-1a (la zona de disponibilidad sería la parte “a” pudiendo haber tres zonas de disponibilidad a, b y c). Para garantizar que los recursos se distribuyen por todas las zonas de disponibilidad de una región, estas se mapean de forma independiente según los identificadores de cada cuenta.

INSTANCIAS EC2 - ELASTIC COMPUTE CLOUD

Una instancia EC2 no es más que una “máquina virtual” con sus características hardware con las que se trabajará en AWS. Actualmente existen múltiples varios tipos de instancias: T3, T2, M4 y M5. Cada tipo con sus ventajas y características de rendimiento hardware.

https://www.cloudping.info/



AMAZON VPC - VIRTUAL PRIVATE CLOUD

Las redes VPC permiten aprovisionar una sección de la nube de AWS aislada de forma lógica, en la se pueden lanzar recursos de AWS en una red virtual. Se pueden definir los rangos de direcciones IP tanto en IPv4 como IPv6, creación de subredes, configuraciones de tablas de enrutamiento, gateways de red, ACLs, security groups, establecer opciones DHCP, elastic IPs (IPs fijas), conexiones VPN, conexiones Peering entre VPCs de diferentes cuentas AWS. etc.

7.4.1 Crear una VPC

Se crea una red 192.168.0.0/16 llamada web-itgal.

Figura 12: Creación de una red VPC.

7.4.2 Crear tres subredes en tres zonas de disponibilidad distintas

Se crea tres subredes dentro de la VPC creada anteriormente. Cada una de esta subred en una zona de disponibilidad diferente (us-east-2a, us-east-2b, us-east-2c). De modo que si se utiliza Autoscaling groups cuando se levante una nueva instancia en una zona de disponibilidad y esa se caiga, autoscaling levantará una nueva instancia en una zona de disponibilidad activa.

Figura 13: Creación de subred en una zona de disponibilidad (a).



Se siguen creando tres zonas de disponibilidad asociadas a la misma red VPC. 192.168.10.0/24, 192.168.0.20.0/24, 192.168.0.30/24.

Figura 14: Subredes creadas en las tres zonas de disponibilidad (a, b y c).

7.4.3 Crear un Internet Gateway

Esto no es suficiente para empezar a crear instancias EC2, ya que no tendrían salida a internet. Por lo que se crea un Internet Gateway asociado a la VPC creada.

Figura 15: Creando un Internet Gateway para dar salida a internet a la VPC creada.

Se asocia este Internet Gateway a la VPC creada. Cada Internet Gateway solo puede estar asociado a una VPC concreta.

Figura 16: Asociar un Internet Gateway a la VPC creada.



7.4.4 Crear una tabla de rutas para una VPC y subredes.

Se agrega una nueva regla que enrutará el tráfico a la red VPC que proceda de 0.0.0.0/0 (es decir, todo internet cualquier IP) se asocie al Internet Gateway creado anteriormente.

Figura 17: Enrutar "todo internet" a la VPC asociando el Internet Gateway.

Las tres subredes creadas se asocian a la tabla de rutas.

Figura 18: Asociar las tres subredes a esta tabla de rutas.



7.4.5 Auto asignar una IP pública para cada subred

Para que las nuevas instancias EC2 creadas se le asigne de forma automática una nueva IP pública IPv4, es neceario habilitar el check para cada subred “Modify auto-assign IP settings”.

Figura 19: Auto asignar una IP pública a cada subred.

7.4.6 Network ACL y Security Group

Una de las formas que AWS tiene para aumentar y monitorear la seguridad a las infraestructuras cloud, es el uso de Security Groups y Network ACLs. Existen ciertas diferencias.

Security Group Network ACL

Opera en el nivel de la instancia Opera en el nivel de la subred

Solo admite reglas de permiso Admite reglas de permiso y de denegación

Es con estado: el tráfico de retorno se admite automáticamente, independientemente de las reglas

Es sin estado: las reglas deben permitir de forma explícita el tráfico de retorno

Evalua todas las normas antes de decidir si permitir el tráfico

Procesa las reglas por orden numérico al decidir si permitir el tráfico

Se aplica a una instancia únicamente si alguien especifica el grupo de seguridad al lanzar la instancia, o asocia el grupo de seguridad a la instancia más adelante

Se aplica automáticamente a todas las instancias de las subredes con las que se ha asociado (por tanto, no tiene que confiar en que los usuarios especifiquen el grupo de seguridad)



Un diagrama de ejemplo del funcionamiento de Network ACL y Security Group dentro de una VPC.

Figura 20: Diagrama de ejemplo - Security Group y Network ACL.

Cuando se crea un una nueva VPC se crea un Security Group por defecto asociado a dicha VPC. En principio se añadirá una regla de entrada que permita todo el tráfico solamente para el mismo Security Group que a su vez está asociado a la ID de la VPC “webitgal”.

A lo largo del proyecto se irán especificando nuevas reglas de entrada para los Security Groups que sean necesarios.

Figura 21: Reglas Security Group por defecto de la VPC webitgal.



8 IMPLEMENTACIÓN DE DOCKER SWARM EN AWS

CREAR UNA KEYPAIR EN AWS PARA CONECTARSE A INSTANCIAS EC2

Para conectarse a instancias EC2 es necesario generar un par de claves de conexión SSH para autenticarse de forma segura a las instancias cloud de AWS.

Se puede generar la Keypair a través del menú Keypair que se encontrará en el panel de EC2 o también generarla manualmente a través de software de terceros como “Putty Key Generator”.

Figura 22: Generar par de claves para conexión SSH con Puttykeygen.

La clave privada se guarda en un lugar seguro del equipo local y se importa solamente la clave pública en la cuenta de AWS. De modo que en la creación de nuevas instancias se defina esta Keypair para conectarse a ellas.

Figura 23: Importar clave pública SSH para conexiones a instancias EC2.



CREAR UN INSTANCIA EC2 (DOCKER GESTIÓN)

Se crea una nueva instancia EC2 simplemente para tener una máquina que facilite la gestión para Docker Machine y que tendrá las claves SSH para conectarse a los nodos creados con Docker Machine.

Simplemente se sigue el asistente de lanzamiento de instancias configurando la VPC y el Security Group creados (webitgal, sg-webitgal).

Figura 24: Instancia EC2 para gestión Docker.

CREAR INSTANCIAS CON DOCKER MACHINE

Las instancias EC2 utilizas serán del tipo T2.micro Ubuntu Server 18.04 LTS 64bits, que forman parte del plan “Free tier”. Se crea una nueva instancia EC2 con Docker Engine para gestionar el resto de instancias, instalar los nodos a través de Docker Machine, etc.

8.3.1 IAM: Identity and Access Management

IAM (Identity and Access Management) Permite administrar el acceso a los servicios y recursos de AWS de manera segura. Se pueden crear y administrar usuarios y grupos de AWS, así como utilizar permisos para conceder o denegar el acceso de estos a los recursos de AWS.



8.3.2 Configurar las credenciales de AWS en el sistema local

Será necesario configurar las credenciales a la cuenta AWS en el sistema local (instancia EC2 de gestión de Docker creada anteriormente). Esto permite autenticarse en la cuenta de AWS para crear nuevas instancias (nodos Docker) usando Docker Machine.

Se crea un nuevo usuario en este caso llamado “adryanaws”, en su creación se generan las claves de acceso a la cuenta de AWS (Access Key ID y Secret Access Key).

Figura 25: IAM - “Access Key ID” y “Secret Access Key” del usuario de acceso a la cuenta AWS.

En la instancia EC2 de gestión de Docker se crea el fichero ~/.aws/credentials, con el siguiente contenido.

https://docs.docker.com/machine/examples/aws

[default]

aws_access_key_id = AKIAJND... ...

aws_secret_access_key = 2kUyLCrHM/H53Z9Or... ...

Se establecen también las variables de entorno para las claves de acceso.

export AWS_ACCESS_KEY_ID=AKIAJND... ...

export AWS_SECRET_ACCESS_KEY=2kUyLCrHM/H53Z9Or... ...

8.3.3 Instalación de Docker Machine

Se instala Docker Machine en la instancia de gestión creada anteriormente, con esto se van poder crear nuevas instancias (nodos Docker) con características específicas (región, zona de disponibilidad, etc.) dentro de la cuenta AWS.

https://docs.docker.com/machine/install-machine

base=https://github.com/docker/machine/releases/download/v0.14.0 &&

curl -L $base/docker-machine-$(uname -s)-$(uname -m) >/tmp/docker-machine &&

sudo install /tmp/docker-machine /usr/local/bin/docker-machine

root@docker:~# base=https://github.com/docker/machine/releases/download/v0.14.0 &&

> curl -L $base/docker-machine-$(uname -s)-$(uname -m) >/tmp/docker-machine &&

https://docs.docker.com/machine/examples/aws

https://docs.docker.com/machine/install-machine



> sudo install /tmp/docker-machine /usr/local/bin/docker-machine

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 617 0 617 0 0 3716 0 --:--:-- --:--:-- --:--:-- 3716

100 26.7M 100 26.7M 0 0 24.8M 0 0:00:01 0:00:01 --:--:-- 37.4M

root@docker:~# docker-machine version

docker-machine version 0.14.0, build 89b8332

8.3.4 Crear los nodos Manager y Worker para Docker Swarm

Se crea un nodo con Docker Machine. Se le establece como driver amazonec2, la región, zona de disponibilidad, la VPC ID de la red webitgal y como tag name “manager”.

root@docker:~# docker-machine create --driver amazonec2 --amazonec2-region "us-east-2" --amazonec2-zone "a" --amazonec2-vpc-id vpc-0d1dd38b31455299f manager

Running pre-create checks...

Creating machine...

(manager) Launching instance...

Waiting for machine to be running, this may take a few minutes...

Detecting operating system of created instance...

Waiting for SSH to be available...

Detecting the provisioner...

Provisioning with ubuntu(systemd)...

Installing Docker...

Copying certs to the local machine directory...

Copying certs to the remote machine...

Setting Docker configuration on the remote daemon...

Checking connection to Docker...

Docker is up and running!

To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env manager

Se crea un nuevo nodo con los mismos parámetros pero esta vez con tag name “worker”.

root@docker:~# docker-machine create --driver amazonec2 --amazonec2-region "us-east-2" --amazonec2-zone "b" --amazonec2-vpc-id vpc-0d1dd38b31455299f worker

Running pre-create checks...

Creating machine...

(worker) Launching instance...

Waiting for machine to be running, this may take a few minutes...

Detecting operating system of created instance...

Waiting for SSH to be available...

Detecting the provisioner...

Provisioning with ubuntu(systemd)...

Installing Docker...

Copying certs to the local machine directory...

Copying certs to the remote machine...

Setting Docker configuration on the remote daemon...

Checking connection to Docker...

Docker is up and running!

To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env worker



A nivel de Docker, se comprueba el estado de las instancias creadas con Docker Machine (manager y worker).

root@docker:~# docker-machine ls

NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS

manager - amazonec2 Running tcp://18.222.164.92:2376 v18.06.1-ce

worker - amazonec2 Running tcp://18.224.18.232:2376 v18.06.1-ce

A nivel de AWS dentro de la consola EC2 también se crearon correctamente.

Figura 26: Instancias Manager y Worker creadas con Docker Machine.

8.3.5 Establecer variables de entorno para máquinas creadas con Docker Machine

Establecer variables de entorno para que Docker ejecute comandos en una máquina en particular, en este caso para la máquina “manager”.

https://docs.docker.com/machine/reference/env

root@docker:~# docker-machine env manager

export DOCKER_TLS_VERIFY="1"

export DOCKER_HOST="tcp://18.222.164.92:2376"

export DOCKER_CERT_PATH="/root/.docker/machine/machines/manager"

export DOCKER_MACHINE_NAME="manager"

# Run this command to configure your shell:

# eval $(docker-machine env manager)

root@docker:~# eval $(docker-machine env manager)

root@docker:~# docker-machine ls

NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS

manager * amazonec2 Running tcp://18.222.164.92:2376 v18.06.1-ce

worker - amazonec2 Running tcp://18.224.18.232:2376 v18.06.1-ce

https://docs.docker.com/machine/reference/env



CREAR ROL MANAGER DE UN SWARM

Se establece una conexión SSH hacia el nodo manager usando Docker Machine y se crea un nuevo swarm desde este nodo, en ese momento este nodo será el manager del swarm.

Cuando se crea el swarm este genera un “token join” para que otros nodos se unan a este cluster swarm. Posteriormente se usará para unir los nodos worker al swarm.

Una vez se crea el swarm se listan los nodos para comprobar que hay un cluster swarm creado. Aunque en este punto solo se verá un único nodo, que será el manager.

root@docker:~# docker-machine ssh manager

Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-1020-aws x86_64)

* Documentation: https://help.ubuntu.com

* Management: https://landscape.canonical.com

* Support: https://ubuntu.com/advantage

Get cloud support with Ubuntu Advantage Cloud Guest:

http://www.ubuntu.com/business/services/cloud

199 packages can be updated.

106 updates are security updates.

New release '18.04.1 LTS' available.

Run 'do-release-upgrade' to upgrade to it.

ubuntu@manager:~$ sudo su

root@manager:/home/ubuntu# docker swarm init

Swarm initialized: current node (b5mm1cmv2d2jr1dgh5rlr3oqk) is now a manager.

To add a worker to this swarm, run the following command:

docker swarm join --token SWMTKN-1-0g0ss3acs0b2rbw5hdw1lqkasz7zlmkkc9y2ptvuq48wu0rlqz-9ba6zu6xi4d7n79tommkt40t8 192.168.10.251:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

root@manager:~# hostname -I

192.168.10.251 172.17.0.1 172.18.0.1

root@manager:~# docker node ls

ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION

b5mm1cmv2d2jr1dgh5rlr3oqk * manager Ready Active Leader 18.06.1-ce



8.4.1 Security Group Docker Machine

Cuando se crean nodos a través de Docker Machine usando el driver de AWS. Se crea un Security Group por defecto con las siguientes reglas de entrada.

▪ SSH puerto 22/tcp. ▪ Docker (docker daemon) puerto 2376/tcp. ▪ Swarm puerto 3376/tcp (solo para los nodos manager de swarm). ▪ Escucha de nodos Manager, por defecto puerto 2376/tcp. ▪ Escucha de nodos Worker, por defecto puerto 2377/tcp.

Este Security Group se asociará por defecto a los nodos creados con Docker Machine, aunque ya incluye los puertos necesarios para trabajar con Docker Swarm será necesario añadir una regla para permitir todo el tráfico pero no desde cualquier red, sino que solamente desde la red VPC “webitgal”.

Para hacer esto simplemente se establece como origen el ID del Security Group asociado a la VPC de webitgal.

Figura 27: Reglas para Security Group creado por Docker Machine.



CREAR AMI (AMAZON MACHINE IMAGE) DE UN NODO WORKER

Será necesario crear una AMI del nodo “worker” creado anteriormente con la finalidad de tener una imagen de esa instancia para posteriormente usarla en un Launch Configuration de Auto Scaling Group.

Este nodo es usuado de base como referencia para el lanzamiento de nuevas instancias usando Auto Scaling Group.

Figura 28: Crear una AMI del nodo worker.

Figura 29: Imagen base de un nodo worker para lanzar nuevas instancias con ASG.



9 AUTO SCALING GROUPS PARA DOCKER SWARM

SECURITY GROUP PARA NUEVAS INSTANCIAS LANZADAS CON ASG

Antes de configurar Auto Scaling Groups, se pueden establecer nuevas reglas de entrada para el Security Group que se asociará a nuevas instancias lanzadas desde ASG.

Permitiendo ya el tráfico HTTP (80) y HTTPS (443) para la web de Wordpress que se ejecutarán en los contenedores de cada instancia. Así como una regla “Custom TCP” para los puertos 8000 y 9000 que serán usados para ejecutar un par de aplicaciones en contenedores que se mencionarán más adelante (Docker Visualizer y Portainer).

Figura 30: Añadir nuevas reglas al Security Group asociado a las nuevas instancias que se lanzarán con ASG.



¿QUÉ ES CLOUD-INIT?

Cloud-init es la forma estándar para configurar e inicializar servidores en la nube. Con Cloud-init se pueden realizar tareas fácilmente en el arranque del sistema, usa una sintaxis de lenguaje de serialización tipo YAML (Yet Another Markup Language).

Existe gran variedad de configuraciones de ejemplo que se pueden encontrar.

https://cloudinit.readthedocs.io/en/latest/index.html

https://cloud-init.io

En este caso se usará Cloud-init como “User data Script” para la creación de instancias EC2. Para este caso se podría utilizar bash scripting sin problema, pero con el fin de dar a conocer nuevas alternativas a soluciones se optó por usar cloud-init.

En el siguiente código se hará una actualización de los repostirios, se instalará el paquete curl y se ejecutarán:

▪ Docker join, para unir esta nueva instancia al cluster de nodos de Swarm. ▪ Creará un script con el contenido para dejar el cluster de nodos cuando se termine la

instancia de forma automática por ASG. ▪ Para que este script se ejecute en el apagado del sistema se crea un enlace simbólico

al directorio /etc/rc0.d/K99salir-nodo.sh. ▪ Finalmente se le otorgan permisos de ejecución al script.

Se mostrará más adelante que esto no es suficiente para que un nodo Manager actualice su cluster de nodos y poder eliminar aquellos nodos que ya no estén disponibles o en estado “Down” (se verá más adelante).

#cloud-config

package_update: true

packages:

- curl

runcmd:

- docker swarm join --token SWMTKN-1-0g0ss3acs0b2rbw5hdw1lqkasz7zlmkkc9y2ptvuq48wu0rlqz-9ba6zu6xi4d7n79tommkt40t8 192.168.10.251:2377

- echo -e "#! /bin/bash \ndocker swarm leave" > /salir-nodo.sh

- ln -s /salir-nodo.sh /etc/rc0.d/K99salir-nodo.sh

- chmod +x /etc/rc0.d/K99salir-nodo.sh

https://cloudinit.readthedocs.io/en/latest/index.html

https://cloud-init.io/



CICLO DE VIDA DE INSTANCIAS EC2 EN AUTO SCALING

Las instancias EC2 de un grupo de Auto Scaling tienen una ruta o ciclo de vida que difiere de las de otras instancias EC2. El ciclo de vida comienza cuando el grupo de Auto Scaling lanza una instancia y la pone en servicio. El ciclo de vida finaliza cuando el usuario termina la instancia o el grupo de Auto Scaling retira la instancia del servicio y la termina.

El siguiente diagrama muestra las transiciones entre los estados de la instancia y el ciclo de vida de Amazon EC2 Auto Scaling.

Figura 31: Ciclo de vida de instancias EC2 en ASG.

9.3.1 Política de terminación de instancias

▪ Si hay instancias en varias zonas de disponibilidad, se selecciona la zona de disponibilidad que tenga más instancias y al menos una instancia que no esté protegida para el escalado descendente. Si hay más de una zona de disponibilidad con este número de instancias, se selecciona la zona de disponibilidad con las instancias que utilizan la configuración de lanzamiento más antigua.

▪ Se determina qué instancias desprotegidas de la zona de disponibilidad seleccionada utilizan la configuración de lanzamiento más antigua. Si hay una instancia de este tipo, se termina.

▪ Si hay varias instancias que utilizan la configuración de lanzamiento más antigua, se determina qué instancias desprotegidas están más próximas al siguiente minuto de facturación. (Esto le ayuda a maximizar el uso de las instancias EC2 y administrar los costos de uso de Amazon EC2). Si hay una instancia de este tipo, se termina.

▪ Si hay varias instancias desprotegidas más próximas a la siguiente hora de facturación, se selecciona una de estas instancias aleatoriamente.



Diagrama de flujo del funcionamiento de la política de terminación predeterminada.

Figura 32: Política de terminación de instancias EC2 en ASG.

Nota: Actualmente se factura por minuto y no por hora como se muestra en el diagrama de la figura 32.

9.3.2 Conceptos: Scale-Up, Scale-In y Scale-Out

▪ Scale-Up: Sería ampliar el tamaño en características hardware de las instancias EC2 (por ejemplo, cambiando su tipo t3.micro, t2.large, m4.10xlarge, etc.).

▪ Scale-Out (escalado de salida): Escalar instancias de forma horizontal, es decir añadir más instancias EC2, aplicado a ASG esto hará que se creen nuevas instancias.

▪ Scale-In (escalado de entrada): Lo contrario que Scale-Out, aplicado a ASG sería decrementar las instancias EC2 creadas.



CREAR UN LAUNCH CONFIGURATION

Un Launch Configuration no es más que una templete que usará ASG para el despliegue de instancias EC2. Se selecciona la AMI creada, esta será la instancia “base” de referencia en las que se basarán el resto de instancias lanzadas en ASG.

Figura 33: Launch Configuration ASG - Selecionar la AMI base worker.

Se le asigna un nombre y se indica el cloud-init mencionado anteriormente, como contenido del campo “User data”.

Figura 34: Usando “cloud-init” para establecer el User data de las instancias ASG.



Se asocia el Security Group con el que se fue trabajando hasta este punto.

Figura 35: Asociar Security Group a las instancias de ASG.

Finalmente se asociada la Keypair que ya se tenía creada, esto será útil para conectarse a las instancias más fácilmente, sin necesidad de usar la instancia “docker-gestion” para acceder de forma pivotante a los nodos creados con ASG.

Figura 36: Establecer la Keypair para las nuevas instancias ASG.

La configuración del Launch Configuration está lista.

Figura 37: Launch Configuration creado.

Nota: Los launch configurations no se pueden editar, se tendrá que hacer una copia de un launch configuration existente y en el nuevo asistente cambiar los parámetros deseados, volver a crearlo como un nuevo launch configuration eliminando después el anterior.



CREAR Y CONFIGURAR: AUTO SCALING GROUP

Se crea un Auto Scaling Group basándose en el Launch configuration creado anteriormente. En principio con cero instancias y para realizar las pruebas más rápidamente con un “Health Check Grace Period” de 100 segundos (por defecto serían 300 segundos).

Se agregan la red VPC webitgal con las tres subredes asociadas en las tres zonas de disponibilidad dentro de la región “us-east-2”. Mediante un algoritmo Round Robin ASG decidirá en que zona de disponibilidad lanzará las instancias.

Figura 38: Crear un ASG definiendo una VPC y sus subredes.

Se añade un Name tag, de modo que cada vez que Auto Scaling cree un nueva instancia esta se le asigne el nombre de “worker-asg” para poder distinguirla del resto de instancias en el panel de instancias de EC2.

Figura 39: Asignar un Name tag a todas las nuevas instancias creadas por ASG.



Finalmente estará configurado el Auto Scaling Group.

Figura 40: ASG creado y configurado.

OPCIONES DEL SERVICIO DE AUTO SCALING GROUPS

Auto Scaling Group se compone de varias opciones que se pueden configurar y personalizar según nuestras necesidades.

9.6.1 ASG: Details

En la sección Details se muestra la información relevante para la configuración de los grupos de auto escalado. De todas las opciones existentes, para este proyecto se centrará en:

▪ Desired Capacity: Capacidad deseada de instancias actuales levantadas para este ASG. ▪ Min: Capacidad mínima de instancias levantadas para este ASG. ▪ Max: Capacidad máxima de instancias levantadas para este ASG. ▪ Classic Load Balancers: Será donde se defina el ELB que balanceará las solicitudes

HTTP/HTTPS entre las instancias disponibles de ASG.

Figura 41: ASG - Details.



9.6.2 ASG: Activity History

Mostrará y mantendrá un registro de actividad del estado de las instancias pasadas y actuales.

Figura 42: ASG - Activy History.

9.6.3 ASG: Scaling Policies (Alertas CloudWatch)

Se trata de uno de los aspectos más interesantes. Permite levantar o terminar instancias de forma automática con ASG en base a unas condiciones o criterios establecidos.

Para configurar las políticas de escalado primero se crearía una alarma, estaría gestionada por CloudWatch que es el servicio de AWS encargado del monitoreo de métricas y alertas de la gran mayoría de servicios que ofrece AWS (no el objetivo de este proyecto trabajar con CloudWatch).

En las alertas o alarmas se puede configurar un e-mail para notificaciones, que avise cuando una alerta cumpla lo que se define en ellas. En el siguiente ejemplo se puede ver como si la cantidad máxima de consumo de CPU durante cinco minutos es mayor o igual que el 85% genere una alerta, esta alerta será el desencadenante que se asociará a la política de auto escalado.

Figura 43: Crear alarma como trigger para una Scaling Policies de ASG.



Las alarmas se gestionan desde el servicio de CloudWatch de AWS. Se podrían crear previamente las alarmas desde el panel CloudWatch o directamente desde la sección Scaling Polices de ASG.

Figura 44: CloudWatch - Alarmas definidas.

Una vez asociada la condición de la alarma creada a la política de auto escalado, se definen el número de instancias que se levantarán (add).

Figura 45: Añadir 2 nuevas instancias cuando se cumplen las condiciones de una alarma definida.



En el siguiente ejemplo se muestra como si la política scale-out es mayor o igual de 1000 bytes de lectura de disco durante 300 segundos levante una nueva instancia. Así como la política de scale-in el consumo de CPU es menor que 75% durante 300 segundos termine una instancia ya levantada.

Figura 46: Ejemplo de Scaling Polices (Scale-In y Scale-Out) en ASG.

9.6.4 ASG: Instances

Muestra el estado actual de las instancias gestionadas por ASG. Se muestra el estado de salud, zona de disponibilidad y el punto del ciclo de vida actual (OutOfService o InService).

Figura 47: ASG - Instances.



9.6.5 ASG: Monitoring

Mostrará un monitoreo de métricas de estado de los recursos de rendimiento representados en gráficas de las instancias gestionadas por ASG.

Figura 48: ASG - Monitoring.

9.6.6 ASG: Notifications

Permite enviar notificaciones por e-mail cuando se inicia, termina, falla en el inicio o falla cuando termina una instancia levantada o terminada con ASG.

Figura 49: ASG - Notifications.



9.6.7 ASG: Tags

Mostrará y se podrán editar nuevos Tags que se asignarán a las instancias gestionadas por ASG.

Figura 50: ASG - Tags.

9.6.8 ASG: Scheduled Actions

Permite establecer acciones programadas. Se pueden definir de forma opciones predeterminadas o mediante una sintaxis tipo cron. El número mínimo, máximo y deseado de instancias que se levantarán y terminarán en un día y hora concretos.

Figura 51: Scheduled Action.



9.6.9 ASG: Lifecycle Hooks

Permiten realizar acciones personalizadas en los momentos en los que ASG lanza o termina instancias, de modo que se puedan ejecutar scripts o expresiones/funciones Lambda para instalar o configurar software o realizar alguna acción en el sistema operativo de la instancia.

Figura 52: ASG - Lifecycle Hooks.

En el siguiente diagrama se muestra el flujo de trabajo del ciclo de vida de los Lifecycle Hooks de ASG.

Figura 53: Ciclo de vida - Lifecycle Hooks de ASG.



10 ASG CON ELASTIC LOAD BALANCING

TIPOS DE ELASTIC LOAD BALANCER (ELB)

Actualmente AWS ofrece tres tipos de balanceadores de carga.

▪ Application Load Balancer (HTTP/HTTPS)

Cuando se necesite un conjunto de características flexibles para aplicaciones web con tráfico HTTP y HTTPS. Operando a nivel de solicitud, los equilibradores de carga de aplicaciones proporcionan funciones avanzadas de enrutamiento y visibilidad dirigidas a arquitecturas de aplicaciones, incluidos microservicios y contenedores.

▪ Network Load Balancer (TCP)

Cuando se necesite un alto rendimiento y direcciones IP estáticas para una aplicación. Opera a nivel de conexión, son capaces de manejar millones de solicitudes por segundo mientras mantienen latencias ultra bajas.

▪ Classic Load Balancer (HTTP/HTTPS/TCP)

Cuando exista una aplicación ejecutándose en la red EC2-Classic.

Se puede pensar que para la implementación de este proyecto el apropiado sería “Application Load Balancer” y la respuesta sería: si o no, depende.

ELB Application Load Balancer ofrece características avanzadas y más personalizadas como la definición de reglas de cabeceras y redireccionamientos web, que para este caso no serán de utilidad ya que simplemente la finalidad es desplegar una web bajo Wordpress sin ninguna de estas opciones.

AWS CERTIFICATE MANAGER

Cuando se crea un Elastic Load Balancer para gestionar tráfico HTTPS/443, es necesario importar un certificado para el dominio en el que ELB gestionará dicho tráfico.

El registrar o registrador que proporciona el dominio, en este caso 1&1, tras la solicitud de certificados SSL para este dominio se obtienen los ficheros de certificados con la clave privada, pública e intermediate.

Se importan estos certificados a través del asistente de AWS Certificate Manager. Para tener este certificado ya agregado a la lista de certificados y posteriormente establecerlo en el asistente de creación y configuración del Elastic Load Balancer.

https://docs.aws.amazon.com/es_es/acm/latest/userguide/acm-services.html

https://docs.aws.amazon.com/es_es/acm/latest/userguide/import-certificate-prerequisites.html

https://docs.aws.amazon.com/es_es/acm/latest/userguide/acm-services.html

https://docs.aws.amazon.com/es_es/acm/latest/userguide/import-certificate-prerequisites.html



Figura 54: AWS Certificate Manager - Importar certificado SSL "itgal.es".

CREAR Y CONFIGURAR: ELASCTIC LOAD BALANCER

Se definen las opciones para ELB. Establecer un nombre, añadir la VPC y las diferentes subredes en distintas zona de disponibilidad, establecer los protocolos HTTP/80 y HTTPS/443.

Figura 55: Definición de protocolos, VPC y subredes al ELB.



Asociar los Security Groups.

Figura 56: Asignación de Security Groups al ELB.

Seleccionar y establecer los tipos de versiones de SSL/TLS admitidas por el certificado del dominio “itgal.es” importado previamente a través de AWS Certificate Manager.

Figura 57: Configurar las opciones de seguridad certificado SSL *.itgal.es para ELB.

La configuración del Health Check, esto será fundamental para que ELB detecte un estado de salud “InService” en las instancias balanceadas. Si las instancias no pasan las comprobaciones de salud ELB no funcionará porque entenderá que la instancia no está lista para ofrecer el servicio.

Debido a fallos de comprobación de un health check usando como protocolo de ping HTTPS/443 y establecer como path la ráiz “/”. ELB detectaba que las instancias no estaban listas y las establecía como “OutOfService”. Estableciendo como protocolo ping TCP/443, simplemente comprobará que el puerto 443 TCP esté abierto y no analizará una respuesta HTTP/HTTPS 200 Ok.



Figura 58: Configuración de comprobación de salud de ELB.

Se asocian las instancias que ELB balanceará, la instancia manager del Swarm no forma parte del grupo de Auto Scaling. Como en este caso el nodo manager será también worker (manager+worker) será necesario que ELB lo tenga en cuenta como una instancia más a balancear, por lo que la instancia del nodo manager estará siempre asociada al ELB.

Posteriormente se mostrará como vincular este ELB al ASG creado anteriormente.

Figura 59: Selección de instancias utilizadas para ELB.

10.3.1 Balanceo de carga entre zonas en el Classic Load Balancer

Classic Load Balancer distribuye las solicitudes equitativamente entre todas las instancias registradas en todas las zonas de disponibilidad habilitadas. Si cross-zone load balancing está inhabilitado, cada nodo del balanceador de carga distribuye las solicitudes equitativamente entre todas las instancias registradas solo en su zona de disponibilidad.

Para conseguir lo contrario, se habilita el cross-zone load balancing de modo que el balanceador de carga distribuya las solicitudes entre todas las instancias de todas las zonas de disponibilidad registradas.



https://docs.aws.amazon.com/es_es/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html

Figura 60: Habilitar Cross-zone Load Balancing en Classic ELB.

VINCULAR ELASTIC LOAD BALANCER CON AUTO SCALING GROUPS

Para vincular ELB con ASG. Se edita la sección “Details” de ASG y se asocia el ELB. De modo que cuando se levanten instancias en ese ASG se usará como balanceador de las instancias el ELB creado anteriormente con nombre “webitgal-elb”.

Figura 61: Asociar el ELB "webitgal-elb" al Auto Scaling Group "webitgal-asg".





ELB: CREAR REGISTRO DNS TIPO CNAME PARA EL DOMINIO WEB.ITGAL.ES

El problema que surge ahora es que cuando se levantan nuevas instancias con ASG, AWS asigna IPs públicas efímeras estas instancias EC2. De modo que sería insostenible crear registros DNS tipo A para que el nombre de dominio usando en este caso que sería “web.itgal.es” apunte a las IPs públicas de cada instancia lanzada a través de ASG.

Esto se soluciona gracias al ELB, ya que este se crea con un registro tipo CNAME único y que se usará para acceder a los servicios de las instancias EC2 de la infraestructura.

Se creará entonces un registro tipo CNAME en cPanel DNS del proveedor de este dominio que en este caso se trata de 1&1.

Nota: Otra opción sería usar Amazon Route 53, el servicio DNS que ofrece AWS. Por ahorro de costes para la elaboración de este proyecto este servicio no se utilizó.

Se copia el DNS Name creado por el ELB.

Figura 62: Copiar DNS Name proporcionado por ELB.



Se crea un nuevo registro DNS tipo CNAME que apunte al DNS Name del ELB y como nombre de host el subdominio “web.itgal.es”.

Figura 63: Crear registro tipo CNAME en la gestión DNS de 1&1 del dominio "itgal.es".

Se espera a que los servidores DNS propaguen el nuevo registro y se comprueba que web.itgal.es resuelve a la IP pública asociada en ese momento al DNS Name del ELB.

Figura 64: Comprobación de la resolución del registro CNAME para el subdominio con nombre "web.itgal.es".

Se crea también un registro DNS tipo A que apunte a la IP pública de la instancia EC2 del nodo Manager de Docker Swarm. El nombre DNS será el subdominio “swarm.itgal.es”.

Figura 65: Comprobar IPv4 Pública de la instancia EC2 del nodo Manager.

Comprobar que el subdominio swarm.itgal.es resuelve a la dirección IPv4 Pública de la instancia del nodo Manager.

Figura 66: Comprobación de la resolución del registro A para el subdominio con nombre "swarm.itgal.es".



11 CREAR SERVICIOS EN DOCKER SWARM

DOCKER VISUALIZER

Antes de comenzar a lanzar el servicio de la web de Wordpress que administrará el nodo Manager al resto de nodos Worker. Se implementará un contenedor que facilitará la visualización a tiempo real del estado de los nodos unidos al Swarm, viendo así la forma de funcionamiento y el balanceo de contenedores entre los nodos que forman parte del cluster Swarm.

Se usa una aplicación desarrollada por Docker, pero en la que contribuyen públicamente otros desarrolladores de forma personal, llamada Docker Visualizer.

https://github.com/dockersamples/docker-swarm-visualizer

A través de docker-machine se accede vía SSH al nodo Manager y se ejecuta el docker run que lanzará la aplicación de Docker Visualizer.

Esta aplicación establecerá la conexión de redirección en un puerto publish 8000:8080, de ahí la razón de habilitar una regla de entrada para este puerto en el Security Group utilizado a lo largo del proyecto.

root@manager:~# docker run -it -d -p 8000:8080 -v /var/run/docker.sock:/var/run/docker.sock dockersamples/visualizer

Unable to find image 'dockersamples/visualizer:latest' locally

latest: Pulling from dockersamples/visualizer

88286f41530e: Pull complete

6a722742375f: Pull complete

... ...

38c27673b825: Pull complete

fc01495d48ca: Pull complete

Digest: sha256:f1e6af29c436410dfa1c9a6bae4bf035152cbea251eec149c53b7a681a783d5c

Status: Downloaded newer image for dockersamples/visualizer:latest

de9fb2abf3c9bc2a226d054e6e2d64fabdd2e4f0afa969fa362c45e180181d35

root@manager:~# docker images


dockersamples/visualizer latest 179717024287 2 months ago 158MB

root@manager:~# docker ps


5111d9a8d75f dockersamples/visualizer "npm start" 15 seconds ago Up 15 seconds (health: starting) 0.0.0.0:8000->8080/tcp objective_williams

https://github.com/dockersamples/docker-swarm-visualizer



Figura 67: Docker Visualizer - Estado del Swarm (nodo Manager).

De forma manual y como prueba de concepto se levantan dos instancias usando ASG. Una vez iniciadas se unirán al cluster de nodos del Swarm y se podrán ver en la aplicación web de Docker Visualizer accediendo a través de un navegador web.

Se comprueba a través del nodo Manager el resto de nodos y como existen dos nuevos nodos con rol Worker unidos al Swarm.



eyxf2pqhfbprckm6db44761zj ip-192-168-10-64 Ready Active 18.06.1-ce

qw84n3ev09yhc30vlmddrwpzb ip-192-168-20-133 Ready Active 18.06.1-ce




A través de la IP pública de la instancia de EC2 del nodo Manager haciendo la petición al puerto 8000 se accede a la interfaz web de Docker Visualizer. En la que se muestra el estado de los nodos que forman parte del Swarm.

Figura 68: Docker Visualizer - Estado del Swarm de todos los nodos incluidos los lanzados por ASG.

Se comprueba el estado de instancias EC2 lanzadas con ASG (webitgal-asg) correspondientes a los nodos worker (worker-asg) que serían los “Name tag” definidos en la creación de ASG.

Figura 69: Instancias EC2 de los nodos worker lanzadas con ASG.



CREAR UN SERVICIO DE LA IMAGEN DE WORDPRESS PERSONALIZADA

Se crea un nuevo servicio el cual hace tres réplicas, con un paralelismo de uno entre los diferentes nodos/instancias y lanzará la imagen del repositorio de Docker Hub.

Se listan los servicios disponibles, los nodos y los procesos del servicio para saber que tareas de réplicas se están ejecutando en cada nodo.

root@manager:~# docker service create \

> --name webitgal \

> --publish 80:80 \

> --publish 443:443 \

> --replicas 3 \

> --update-parallelism 1 \

> --update-delay 5s \

> --restart-condition on-failure \

> adryanaws/webitgal

8eoqdtcmx20mne3iepo2074px

overall progress: 3 out of 3 tasks

1/3: running [==================================================>]

2/3: running [==================================================>]

3/3: running [==================================================>]

verify: Service converged

root@manager:~# docker service ls

ID NAME MODE REPLICAS IMAGE PORTS

moz3dk6gdrkt webitgal replicated 3/3 adryanaws/webitgal:latest *:80->80/tcp, *:443->443/tcp



p6pixqmt2xthxwbgn68aaz6tp ip-192-168-10-53 Ready Active 18.06.1-ce

llw0v9m1j9icg9mllqkdxyyws ip-192-168-20-43 Ready Active 18.06.1-ce


root@manager:~# docker node ps manager ip-192-168-10-53 ip-192-168-20-43

ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS

z71mc1wa9gyd \_ webitgal.1 adryanaws/webitgal:latest manager Running Running 27 minutes ago



zdeekb0zij6e \_ webitgal.2 adryanaws/webitgal:latest ip-192-168-10-53 Running Running about a minute ago

zdeekb0zij6e \_ webitgal.2 adryanaws/webitgal:latest ip-192-168-10-53 Running Running about a minute ago

29p740v2kt81 webitgal.3 adryanaws/webitgal:latest ip-192-168-20-43 Running Running about a minute ago



Docker Visualizer se actualiza en tiempo real por lo que los cambios se verán reflejados en el mismo instante. Se pueden ver las tres instancias, los tres nodos del Swarm cada uno con una tarea que será la réplica del contenedor, como se le indicó un paralelismo con valor de uno se ejecutará una tarea por nodo, en este caso equivaldría a un contenedor por nodo. Recordar que el nodo Manager también tiene el rol de Worker.

Figura 70: Servicio webitgal en ejecución - Tres réplicas con paralelismo de uno entre los tres nodos.



12 TESTING DE BALANCEOS ENTRE ELB Y DOCKER SWARM

BALANCEO DE ELB ENTRE INSTANCIAS Y EL BALANCEO DE DOCKER SWARM

EN EL ACCESO AL SERVICIO WEB.ITGAL.ES

Con todo lo anterior visto, desplegado e implementado. Se comprueba el balanceo con ELB entre las distintas instancias de la infraestructura desplegada con ASG y el balanceo entre contenedores de Docker Swarm entre los distintos nodos.

En este caso solo se desplegó un contenedor por instancia, es decir una tarea de réplica ejecutándose en cada nodo desplagada a través de un servicio (webitgal) que gestiona el nodo Manager del Swarm, más adelante se mostrará como Swarm hace balanceo entre diferentes instancias con varios contenedores ejecutándose dentro de una misma instancia.

Figura 71: Instancia de un nodo Swarm.





Se comprueba también que el certificado SSL para el dominio “*.webitgal.es”. Configurado en uno de los Virtualhost de apache del propio contenedor e importado en AWS Certificate Manager para añadirlo al ELB el protocolo HTTPS en el puerto 443.

Figura 74: Certificado SSL implementado para el “https://web.itgal.es”.

Figura 75: Certificado SSL implementado en el ELB.



12.1.1 Metadatos de instancia y datos de usuario

Los metadatos de instancia son datos sobre una instancia que se pueden utilizar para configurar o administrar la instancia en ejecución. Haciendo uso de la utilidad de comandos “curl” se pueden realizar peticiones obteniendo así dichos metadatos establecidos.

https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

Por ejemplo para obtener el ID de una instancia. (La IP 169.254.169.254 está definida por AWS).

http://169.254.169.254/latest/meta-data/instance-id

En el ejemplo anterior se veía el ID de instancia y la dirección IP interna de la instancia actual. Para conseguir visualizar esta información. Se modificaron los ficheros:

/var/www/html/wp-content/themes/mi-theme/header.php

/var/www/html/wp-admin/admin-header.php

El fichero header.php del theme corresponde a la cabecera de la plantilla personalizada. El fichero admin-header.php corresponde a la cabecera del backoffice administrativo de Wordpress.

En ambos ficheros se añaden en las líneas que corresponderían visualmente a su colocación, el siguiente código PHP. La función “file_get_contents” devolverá todo el contenido del valor que se le pase, en este caso la URI de la metada a mostrar. Para dar un aspecto visual más notable, se establecen unos estilos dentro de la propia etiqueta HTML “<div>”.

<div style="background-color:black;color:white;font-size:1.5em;text-align:center;padding:5px;width:100%">

<?php echo file_get_contents("http://169.254.169.254/latest/meta-data/local-ipv4"); ?>

<br />

<?php echo file_get_contents("http://169.254.169.254/latest/meta-data/instance-id"); ?>

</div>

12.1.2 Habilitar “Stickiness” en Elastic Load Balancer

De forma predeterminada, un Classic Load Balancer direcciona cada solicitud de manera independiente a la instancia registrada con menor carga. Sin embargo, se puede utilizar la característica de sesión sticky (también denominada afinidad de sesión) que permite que el balanceador de carga vincule una sesión de usuario a una instancia concreta. Con ello se garantiza que todas las solicitudes de ese usuario durante la sesión se envían a la misma instancia.

De modo que si no se usa una aplicación que gestione la propia cookie de sesión, Elastic Load Balancing gestionará una cookie de sesión especificando su propia duración de persistencia.

https://docs.aws.amazon.com/es_es/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

https://docs.aws.amazon.com/es_es/elasticloadbalancing/latest/classic/elb-sticky-sessions.html



Figura 76: Stickness en Elastic Load Balancer.

Basándose en el ejemplo de las instancias anteriores, dentro de la sesión de usuario del backoffice de Wordpres en las siguientes capturas se puede ver como ELB usa la cookie de sesión para las diferentes instancias en distintas zonas de disponibilidad.

Nota: Después de las pruebas realizadas sobre esta funcionalidad, se comprueba que no siempre funciona y de las ocasiones que llegó a funcionar correctamente solamente ocurrió cuando se ha iniciado sesión en todas las instancias existentes.

Figura 77: Instancia de un nodo Swarm con Stickiness habilitado en ELB





ACTUALIZACIÓN DE RÉPLICAS: BALANCEO ENTRE CONTENEDORES CON

DOCKER SWARM Y ENTRE INSTANCIAS CON ELB

Se actualiza el servicio lanzando seis tareas de réplicas del servicio para las tres instancias actuales y comprobar su compartimiento.

Al haber tres instancias en ejecución con un paralelismo de uno cada tarea se ejecutaba en una instancia. Con la actualización de réplicas a seis y conservando el mismo paralelismo, se deberá añadir una nueva tarea (contenedor del sitio web “web.itgal.es”) a cada una de las instancias.

Nota: Los IDs e IPs no correspondan con las capturas anteriores debido a cambios en las pruebas realizadas. Igualmente se mantiene el mismo escenario continuando el ejemplo anterior visto hasta ahora.

root@manager:~# docker service update --replicas=6 webitgal

webitgal


1/6: running [==================================================>]

2/6: running [==================================================>]

3/6: running [==================================================>]

4/6: running [==================================================>]

5/6: running [==================================================>]

6/6: running [==================================================>]


root@manager:~# docker node ps manager ip-192-168-20-133 ip-192-168-10-64

ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS

a8t5mb5oodg5 webitgal.1 adryanaws/webitgal:latest ip-192-168-10-64 Running Running 16 minutes ago

iscl4sji10o9 \_ webitgal.2 adryanaws/webitgal:latest ip-192-168-20-133 Running Running 16 minutes ago

iscl4sji10o9 \_ webitgal.2 adryanaws/webitgal:latest ip-192-168-20-133 Running Running 16 minutes ago

n2badzw9o27s \_ webitgal.3 adryanaws/webitgal:latest manager Running Running 16 minutes ago



rhojgz6d7bg4 \_ webitgal.4 adryanaws/webitgal:latest ip-192-168-20-133 Running Running 17 seconds ago

rhojgz6d7bg4 \_ webitgal.4 adryanaws/webitgal:latest ip-192-168-20-133 Running Running 17 seconds ago

5udvxa423k8f \_ webitgal.5 adryanaws/webitgal:latest manager Running Running 17 seconds ago



xq6dnuwwwu46 webitgal.6 adryanaws/webitgal:latest ip-192-168-10-64 Running Running 17 seconds ago



Se puede observar como se actualizaron los cambios. De este modo Docker Swarm está balanceando la carga entre diferentes contenedores de cada nodo y ELB balancea la carga entre todas las instancias que forman parte de distintas de zonas de disponibilidad.

Figura 80: Balanceo Docker Swarm y ELB - Actualización de réplicas a seis para las tres instancias.

BALANCEO ENTRE ELB Y DOCKER SWARM EN NUEVAS INSTANCIAS

LANZADAS CON ASG (SCALE-OUT)

Se listarán los nodos actuales, un total de tres nodos (dos worker lanzados con ASG y un manager).








Con ASG se lanza una nueva instancia aumentando un valor a la capacidad deseada, de modo que ASG gestione un total de tres instancias, que serán los nodos worker.

Figura 81: Lanzar de forma manual una nueva instancia con ASG que se unirá al Swarm de nodos.

Se puede ver como en el estado de instancias de ASG se ha añadido una nueva instancia estando las tres instancias en estado “InService”.

Figura 82: Estado InService de las instancias gestionadas por ASG.



Las instancias gestionadas por ASG y la instancia añadida de forma fija correspondiente al nodo manager forman parte del grupo de instancias de ELB.

Figura 83: Estado InService de las instancias gestionadas por ELB.

En la vista de general de instancias EC2 de AWS se pueden ver las tres instancias desplegadas por ASG (worker-asg) y la instancia del nodo manager, todas en estado “running”.

Figura 84: Estado running de todas las instancias de desplegadas.

Con la nueva instancia ya desplegada por ASG, se listan nuevamente los nodos disponibles del Swarm comprobando así que el nuevo nodo se unió al Swarm gracias al la instrucción “docker swarm init” establecida en el cloud-init del “User data” cuando se reo el Launch Configuration de ASG.

Con el nuevo nodo se actualiza la tarea de réplicas a seis en el servicio webitgal para balancear la carga de tareas al nuevo nodo.







togf7g1cv22rol9c9jowj1ioh ip-192-168-30-222 Ready Active 18.06.1-ce


root@manager:~# docker service update --force webitgal

webitgal


1/6: running [==================================================>]

2/6: running [==================================================>]

3/6: running [==================================================>]

4/6: running [==================================================>]

5/6: running [==================================================>]

6/6: running [==================================================>]


Con un total de cuatro instancias, tres nodos worker desplegadas por ASG y un nodo manager independiente.

Recordar que ELB está gestionando el nodo manager independiente y el grupo de instancias que lance o termine ASG.

El número total de tareas son seis, con un paralelismo de uno. Como no hay seis nodos Docker Swarm decidirá a que nodos distribuye el resto de tareas, provocando así un apilamiento de tareas en dos de los nodos existentes. Siendo en este caso el nodo manager y un nodo worker aleatorio.

En este escenario ELB estará balanceando las peticiones HTTP/HTTPS entre las instancias disponibles, mientras que Docker Swarm balanceará la carga del servicio entre todos los nodos, y en los nodos donde hay más de un contenedor replicado balanceará las peticiones entre los contenedores de ese mismo nodo.

Con esto se consigue alta disponibilidad gracias al ELB, con Docker Swarm balanceo de carga para los recursos de cada instancia/nodo y escalado horizontal elástico (scale-in o scale-out) con ASG.

En este caso se trata de un único servicio que sirve una única aplicación en base a una imagen. Para sacar un máximo partido de estos balanceos lo ideal sería trabajar con varios servicios que desplieguen varias aplicaciones.



Figura 85: Despliegue de una nueva instancia con ASG y actualización de réplicas en el Swarm.

REDUCIR LAS RÉPLICAS EN LOS NODOS DEL SWARM

Manteniendo el mismo escenario se actualiza el servicio webitgal para que reduzca las réplicas a uno.


webitgal


1/1: running [==================================================>]




Esto ejecutará una única tarea que Swarm balanceará dejando esa tarea réplica a uno asignada al nodo Manager.

Figura 86: Reducir las réplicas del servicio a uno.

TERMINAR LAS INSTANCIAS DESPLEGADAS POR ASG (SCALE-IN)

En el caso de que la demanda de peticiones al sitio web disminuya y por lo tanto la carga de trabajo sería menor, se reduciría (scale-in) el número de instancias. En este caso, como prueba y para no esperar a que esto ocurra a través de las Scaling Policies, se reduce a cero el número de instancias terminando así con todas las instancias gestionadas por ASG.

Figura 87: Scale-in de ASG para las instancias correspondientes a los nodos worker del Swarm.



Una vez las instancias estén en estado “terminated”, visualizando el estado de nodos del Swarm en Docker Visualizer se pueden ver como las tres instancias terminadas por ASG ya no están disponibles, pero siguen formando parte del cluster de nodos del Swarm.

Figura 88: ASG - Instancias en estado terminated (down), igualmente siguen vinculadas al cluster de nodos del Swarm.

Que las instancias estén en estado terminated, es decir que ya no existan en AWS, para un nodo Swarm indican que están en un estado “Down” pero igualmente siguen vinculadas al cluster de nodos de Swarm.



eyxf2pqhfbprckm6db44761zj ip-192-168-10-64 Down Active 18.06.1-ce

qw84n3ev09yhc30vlmddrwpzb ip-192-168-20-133 Down Active 18.06.1-ce

togf7g1cv22rol9c9jowj1ioh ip-192-168-30-222 Down Active 18.06.1-ce




SCRIPT PARA ELIMINAR NODOS EN ESTADO “DOWN” DEL SWARM

Recordar que se había creado un cloud-init en el user data del Launch Configuration en el que se creaba un script que se ejecutaría en el apagado del sistema para las instancias gestionadas por ASG. Ese script contenía el comando “docker swarm leave” eso implica que el nodo que ejecuta esta instrucción se desvincula o deja el cluster de nodos del Swarm del que formaba parte.

Pero igualmente el nodo manager sigue gestionando los nodos que estén en estado Down, no le asigna tareas debido a que no están disponibles pero seguirían formando parte del cluster de nodos del Swarm.

Como solución a esto se crea un script que buscará los nodos en estado Down del Swarm y los eliminará, este script se añade a una tarea programada en cron para que se ejecute cada diez minutos (aunque el tiempo de ejecución de la tarea sería conveniente adaptarlo para cada caso concreto).

El script realiza un bucle mientras se cumple la condición de si la variable “nodo_down” es distinta a vacía, quiere decir que no existe ningún nodo Down en ese momento, no hará nada. De lo contrario, eliminaría los nodos en estado Down.

Para encontrar los nodos Down se lista el conjunto de nodos, con grep se busca la palabra Down, con sed se obtiene la solo la primera línea y con awk la primera columna de la línea anterior. De ese modo se obtiene el ID de nodo, que se almacena en la variable “nodo_down” y que posteriormente se ejecuta el comando de eliminación de ese nodo pasándole el valor de la variable, que sería el ID del nodo.

root@manager:~# mkdir scripts

root@manager:~# nano scripts/eliminar-nodos-down.sh

root@manager:~# chmod +x scripts/eliminar-nodos-down.sh

root@manager:~# ls -laht scripts

total 12K

drwxr-xr-x 2 root root 4.0K Nov 4 23:06 .

-rwxr-xr-x 1 root root 236 Nov 4 23:06 eliminar-nodos-down.sh

drwx------ 5 root root 4.0K Nov 4 23:06 ..

root@manager:~# cat scripts/eliminar-nodos-down.sh

#!/bin/bash

nodo_down=$(docker node ls | grep Down | sed -n '1p' | awk '{print $1}')

while [ "$nodo_down" != "" ];

do

nodo_down=$(docker node ls | grep Down | sed -n '1p' | awk '{print $1}')

docker node rm --force "$nodo_down"

done

Se añade el script a una tarea programa que ejecutará cron cada diez minutos.

root@manager:~# nano /etc/crontab

root@manager:~# tail -n 1 /etc/crontab

*/10 * * * * root /root/eliminar-nodos-down.sh



Siguiendo el escenario anterior, de forma manual se ejecuta el script para comprobar su funcionamiento, pudiendo ver como solamente eliminó aquellos nodos en estado Down.



eyxf2pqhfbprckm6db44761zj ip-192-168-10-64 Down Active 18.06.1-ce

qw84n3ev09yhc30vlmddrwpzb ip-192-168-20-133 Down Active 18.06.1-ce

togf7g1cv22rol9c9jowj1ioh ip-192-168-30-222 Down Active 18.06.1-ce


root@manager:~# ./scripts/eliminar-nodos-down.sh

eyxf2pqhfbprckm6db44761zj

qw84n3ev09yhc30vlmddrwpzb

togf7g1cv22rol9c9jowj1ioh

Error: No such node:




Finalmente se comprueba la actualización de nodos del Swarm, quedando únicamente el nodo manager activo y con el servicio en ejecución del sitio web.

Figura 89: Eliminar nodos Down del Swarm a través de un script añadido a cron.



13 INSTALACIÓN Y ADMINISTRACIÓN USANDO PORTAINER.IO, RANCHER Y GRAFANA

Portainer.io se trata de una interfaz web que facilita la gestión de Docker o Docker Swarm.

Otras alternativas podrían ser Shipyard o Panamax, aunque estas disponen de menos funcionalidades.

https://portainer.io/install.html

https://portainer.readthedocs.io/en/stable

INSTALACIÓN DE PORTAINER CON DOCKER COMPOSE

A modo de ejemplo se despliega Portainer a través de Docker Compose. (Docker compose para hacer una idea sería como el “Dockerfile” de Docker Swarm).

Para poder usar Docker Compose es necesario instalarlo a parte en el nodo manager del Swarm.

https://docs.docker.com/compose/install

root@manager:~# sudo curl -L "https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 617 0 617 0 0 1799 0 --:--:-- --:--:-- --:--:-- 1804

100 11.2M 100 11.2M 0 0 9054k 0 0:00:01 0:00:01 --:--:-- 14.6M

root@manager:~# sudo chmod +x /usr/local/bin/docker-compose

root@manager:~# docker-compose --version

docker-compose version 1.22.0, build f46880fe

root@manager:~#

Se crea un fichero en formata YAML con el nombre “docker-compose.yml”. El cual crearía los servicios con sus tareas y volúmenes necesarios. Una vez creado el fichero anterior se despliega su contenido. Se establece el puerto publish 9000, previamente este puerto ya estaba como regla de entrada en el Security Group para la instancia del nodo manager, permitiendo así su acceso desde redes externas.

root@manager:~/compose# ls

docker-compose.yml

root@manager:~/compose# cat docker-compose.yml

version: '3'

services:

portainer:

image: portainer/portainer

https://portainer.io/

https://github.com/shipyard/shipyard

http://panamax.io/

https://portainer.io/install.html

https://portainer.readthedocs.io/en/stable

https://docs.docker.com/compose/install



ports:

- "9000:9000"

command: -H unix:///var/run/docker.sock

volumes:

- /var/run/docker.sock:/var/run/docker.sock

- portainer_data:/data

volumes:

portainer_data:

root@manager:~/compose# docker stack deploy -c docker-compose.yml portainer

Creating network portainer_default

Creating service portainer_portainer

root@manager:~/compose# docker stack ls

NAME SERVICES ORCHESTRATOR

portainer 1 Swarm

root@manager:~/compose# docker service ls

ID NAME MODE REPLICAS IMAGE PORTS

hyjecqtxjo0m portainer_portainer replicated 1/1 portainer/portainer:latest *:9000->9000/tcp

dyxy6d9twh1j webitgal replicated 1/1 adryanaws/webitgal:latest *:80->80/tcp, *:443->443/tcp

INSTALACIÓN DE PORTAINER CON “DOCKER RUN”

Otra forma de ejecutar Portainer es crear el volumen y lanzarlo como un cotenedor más en el nodo manager del Swarm.

root@manager:~# docker volume create portainer_data

portainer_data

root@manager:~# docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

Unable to find image 'portainer/portainer:latest' locally

latest: Pulling from portainer/portainer

d1e017099d17: Pull complete

d4e5419541f5: Pull complete

Digest: sha256:07c0e19e28e18414dd02c313c36b293758acf197d5af45077e3dd69c630e25cc

Status: Downloaded newer image for portainer/portainer:latest

f7529370fa3e8e7cee1d8f2948a5b453b2e8a2913c97258b54da5743196db7e5

root@manager:~# docker ps


f7529370fa3e portainer/portainer "/portainer" 8 seconds ago Up 7 seconds 0.0.0.0:9000->9000/tcp vibrant_elion



b988715ea778 adryanaws/webitgal:latest "/usr/bin/supervisord" About an hour ago Up About an hour 22/tcp, 80/tcp, 443/tcp webitgal.1.3kvtt2gcdu42nm6tzqntyutf4

5111d9a8d75f dockersamples/visualizer "npm start" 2 hours ago Up 2 hours (healthy) 0.0.0.0:8000->8080/tcp objective_williams

Para poder gestionar Portainer se accede a la IPv4 pública por el puerto 9000 del nodo manager, recordar que esta IP resolvía con el subdominio “swarm.itgal.es:9000”.

Se crean las credenciales del usuario para trabajar con Portainer.

Figura 90: Creación de usuario y contraseña de Portainer.io.

Se selecciona el modo en el que se gestionará, en este caso se había creado un volumen y un despliege como un contenedor en local.

Figura 91: Tipo de conexión para la administración de Docker en Portainer.io.



En el dahsboard de Portainer.io se muestra una vista general de las tareas, servicios, contenedores, imágenes, volúmenes y redes creados.

Figura 92: Dashboard de Portainer.io.

Para comparar la gestión de Docker Swarm a través de Portainer.io, a parte de la actual instancia del nodo manager, con ASG se desplegarán cuatro instancias worker a modo de ejemplo. Actualizando también a cinco las tareas de réplicas del servicio webitgal.


webitgal


1/5: running [==================================================>]

2/5: running [==================================================>]

3/5: running [==================================================>]

4/5: running [==================================================>]

5/5: running [==================================================>]




Se comprueba que la actualización de réplicas y las nuevas instancias.

Figura 93: Nuevo escenario de ejemplo para la gestión de Docker Swarm.

Se compara la forma de visualizar lo mismo con Portainer, el reparto de las tareas en ejecución en cada uno de los nodos de Swarm.

Figura 94: Portainer.io - Administración de Docker Swarm.



Gestión de redes.

Figura 95: Portainer.io - Gestión de redes.

Gestión de contenedores.

Figura 96: Portainer.io - Gestión de contenedores.

Gestión de servicios.

Figura 97: Portainer.io - Gestión de Servicios.



Instalación de plantillas.

Figura 98: Portainer.io - Instalación de plantillas.

RANCHER

Rancher es una plataforma (PaaS, Platform as a Service) open source que corre en Docker. Permite desplegar aplicaciones en contenedores en cualquier infraestructura en producción, apoyándose en herramientas open source.

La plataforma cuenta con un apartado Hosts para gestionar de forma visual las máquinas o instancias de diferentes clouds ya sea Amazon Web Services, Microsoft Azure, Digitalocean, etc. Se puede decir que es una consola visual para la administración de instancias.

En las siguientes figuras de imágenes se muestra un ejemplo visual de su entorno web y algunas de sus funcionalidades.

Integración con AWS.

Figura 99: Rancher - Gestión de instancias EC2 en AWS.

https://rancher.com/



Administración de hosts tanto de AWS como Google Cloud Platform.

Figura 100: Rancher - Gestión de hosts.

Administración de Docker Swarm.

Figura 101: Rancher - Gestión de contenedores Docker Swarm.



GRAFANA - MONITORIZACIÓN DE RECURSOS

Grafana es una aplicación web de código abierto y construída por la comunicadad que permite consultar, visualizar, alertar y analizar las métricas de una forma elegante los datos de la infraestructura y aplicaciones.

Se puede desplegar un contenedor e integrar Grafana en CloudWatch de AWS.

http://docs.grafana.org/installation/docker

Figura 102: Grafana - Ejemplo de visualización.

http://docs.grafana.org/installation/docker



14 DOCKER CLOUD, DOCKER DATACENTER Y AWS CONTAINERS

DOCKER CLOUD

A parte de la integración de repositorios de Docker Hub en Docker Cloud.

Docker Cloud ofrece integración con Amazon Web Services, Microsoft Azure, Digital Ocean o SoftLayer (IaaS de IBM).

https://docs.docker.com/docker-cloud/cloud-swarm/link-aws-swarm

DOCKER DATACENTER

Docker Datacenter (DCC) se trata de un proyecto para la administración de contenedores y servicios de implementación de Docker. Como una plataforma integrada de extremo a extremo para el desarrollo y la gestión ágil de aplicaciones a cualquier escala.

Combina herramientas propietarias y proyectos de contenedores Open Source.

https://www.docker.com/products/docker-enterprise

AWS CONTAINERS

Servicios de administración y registro de contenedores fáciles de usar y con un alto nivel de escalabilidad. Introduciendo el concepto “Contenedores como servicio” (CaaS).

AWS ofrece diferentes tipos de contenedores para implementar, administrar y escalar contenedores en producción.

https://aws.amazon.com/es/containers

14.3.1 Amazon Elastic Container Service

Amazon Elastic Container Service (Amazon ECS) es un servicio de control de contenedores totalmente administrado para implementar, administrar y escalar aplicaciones con contenedores en AWS.

https://aws.amazon.com/es/ecs

14.3.2 Amazon Elastic Container Service for Kubernetes

Amazon Elastic Container Service for Kubernetes (Amazon EKS) es un servicio administrado que facilita que ejecute Kubernetes en AWS sin necesitar convertirse en un experto en operar Kurbenetes. Amazon EKS administra completamente la escabilidad de Kurbenetes para cada clúster.

https://aws.amazon.com/es/eks

https://docs.docker.com/docker-cloud/cloud-swarm/link-aws-swarm

https://www.docker.com/products/docker-enterprise

https://aws.amazon.com/es/containers

https://aws.amazon.com/es/ecs

https://aws.amazon.com/es/eks



14.3.3 Amazon Elastic Container Registry

Amazon Elastic Container Registry (Amazon ECR) es un registro de contenedores de Docker completamente administrado y que gestionará las tareas de almacenamiento, administración e implementación de imágenes de contenedores de Docker.

https://aws.amazon.com/es/ecr

14.3.4 AWS Fargate

AWS Fargate es una tecnología para implementar y administrar contenedores sin tener que administrar la infraestructura subyacente. No es necesario aprovisionar, configurar y escalar clústeres para las máquinas virtuales para ejecutar los contenedores. Simplemente se sube una imagen del contenedor, se especifica los

requisitos de los recursos y AWS Fargate lanzará los contenedores en cuestión de segundos.

https://aws.amazon.com/es/fargate

https://aws.amazon.com/es/ecr

https://aws.amazon.com/es/fargate



15 COSTES Y PRESUPUESTO DE SERVICIOS E IMPLANTACIÓN

▪ Auto Scaling Groups, gratis: https://aws.amazon.com/es/autoscaling/pricing ▪ Network VPC (Virtual Private Cloud), gratis: https://aws.amazon.com/es/vpc/pricing ▪ Cloudwatch, las diez primeras alarmas simples son gratis (en este caso serían necesarias

dos alarmas para las Scaling): https://aws.amazon.com/es/cloudwatch/pricing ▪ Elastic Load Balancer Classic, tiene un precio fijo y después un pago por GB de datos

procesados: https://aws.amazon.com/es/elasticloadbalancing/pricing

Calcular precios de AWS: https://calculator.s3.amazonaws.com/index.html?lng=es_ES

Presupuesto estimado de ejemplo:

https://calculator.s3.amazonaws.com/index.html?lng=es_ES#r=CMH&key=calc-89AD1F78-C1B3-4968-8824-3CF0FDB7402F

▪ 3 instancias EC2. ▪ Elastic Load Balancer Classic

con 20GB/mes de datos procesados.

Servicio Catidad / Unid. Cantidad /

Tiempo Precio € / Hora

Precio € / Total

Dominio DNS (1and1) 1 1 año - 9

Certificado SSL (1and1) 1 1 año - 40

* Instancias EC2 (fijas) 1 720 horas /

1 mes 0,01 7,2

* Instancias EC2 (Auto Scaling Groups)

Dependiendo de las instancias

existentes 1 mes 0,01 -

Elastic Load Balancer Classic (Región Ohio)

1 1 mes 0,022 15,84

Elastic Load Balancer Classic (Región Ohio)

1 1 mes 0,007 € por GB de datos procesados

-

Implantación (Mano de obra)

1 50 horas 40 2.000 €

(* Tipo de instancias EC2: t2.micro)

(** IVA no incluído en

el precio total **)

TOTAL:

2.072,04 €

https://aws.amazon.com/es/autoscaling/pricing

https://aws.amazon.com/es/vpc/pricing

https://aws.amazon.com/es/cloudwatch/pricing

https://aws.amazon.com/es/elasticloadbalancing/pricing

https://calculator.s3.amazonaws.com/index.html?lng=es_ES





AWS - My Billing Dashboard

Figura 103: AWS - My Billing Dashboard.

Figura 104: AWS - My Billing Dashboard Details.



16 MEJORAS DEL PROYECTO

CENTRALIZACIÓN BBDD WORDPRESS

Según el plantemiento del escenario expuesto, una de las principales mejoras es la centralización de la BBDD de Wordpress. Esto no se llegó a implementar para no extender más este proyecto.

La idea de usar contenedores es sobretodo la indepencia de cada servicio, sería más apropiado que Apache2 y MySQL fueran en dos contenedores independientes. Crear un espacio de almacenamiento donde poder alojar la BBDD de Wordpress como por un ejemplo en un bucket S3 de Amazon S3 (el servicio de alamacenamiento en la nube de AWS) y trabajar con este bucket en Docker, en el momento de crear el servicio se puede parametrizar el volumen a montar. De ese modo si algún administrador accede a la web y publica una nueva entrada en una sección tipo blog esta se actualizaría para todas las instancias y/o contenedores que monten dicha unidad.

AUTOMATIZACIÓN DE RÉPLICAS DEL SWARM

Crear la automatización de replicas según las instancias/nodos actuales del Swarm. En el proceso de Auto Scaling Groups de AWS se mostró como automatizar el scale-out y scale-in de instancias mediante alertas gestionadas por CloudWatch y asignadas a unas Scaling Polices.

Lo interesante sería crear un script que consulte el estado de los nodos disponibles del Swarm (en estado “Ready”), sea el número de nodos que sea e independiemente de los cambios de escalado horizontal y elástico. Este script haría un bucle al cluster de nodos del Swarm (docker node ls, algo similar al script mostrado “eliminar-nodo-down.sh”) cuando se detecte un nuevo nodo, actualizar el servicio creando tareas de replicas para que se vayan distribuyendo según las instancias/nodos, para automatizar la ejecución del script se incluiría en el fichero de cron como una tarea programada ejecutándose cada 5 o 10 minutos comprobando los cambios del Swarm de nodos.

MEJORAR LA TOLERANCIA A FALLOS

A modo de prueba, en este proyecto se creó un nodo manager y múltiples workers escalables. Para

mejorar el failover sería recomdable crear un número impar de nodos manager en el Swarm,

asegurando que en el caso de un fallo de un nodo manager seguiría habiendo disponibilidad en el

cluster. En la web oficial de Docker se muestra una tabla más específica sobre esta buena práctica.

https://docs.docker.com/engine/swarm/admin_guide/#add-manager-nodes-for-fault-tolerance

USO DE KUBERNETES

Una buena mejora para el balanceo de Docker Swarm, es sustituir este sistema por Kubernetes. Kubernetes ofrece ciertas mejoras respecto a la gestión en cluster de Docker Swarm como por ejemplo la mejora de la aplicación de balanceo y el rollback, checkeo de salud, redimiento y escalabilidad. Más información sobre la comparación de Kubernetes y Docker Swarm.

https://platform9.com/blog/kubernetes-docker-swarm-compared

https://docs.docker.com/engine/swarm/admin_guide/#add-manager-nodes-for-fault-tolerance

https://platform9.com/blog/kubernetes-docker-swarm-compared



17 CONCLUSIONES

Después de todas las pruebas realizadas para llegar al resultado final obtenido se puede llegar a la conclusión de que no se trata de una tarea sencilla de implementar. La idea, el plantemiento de esquematicación, la implementación e integración de todos los servicios utilizados y la elaboración de la documentación, requiere de tiempo y esfuerzo de aprendizaje para llevar a cabo este proyecto.

Se pude resumir entonces que se trata de ofrecer un servicio, en este caso un sitio web, pero podría aplicarse a cualquier tipo de aplicación o aplicaciones gestionadas por contenedores, con un grado de disponibilidad muy alto tanto de balanceo de carga entre instancias y sus distintas zonas de disponibilidad como el balanceo de los recusos hardware de cada una de las máquinas virtualizadas.

La independización de los microservicios ofrecidos por contenedores y el balanceo entre ellos usando Docker Swarm es solo un pequeño ejemplo de lo que se podría llegar a conseguir implementando todos estos servicios de forma conjunta.

Gracias al bajo costo y flexibilidad de un pago por uso de los servicios de AWS, se pueden granularizar la optimización de costes de los recursos utilizados. Ahorrarnos el coste y mantenimiento hardware que conllevaría administrar y gestionar un propio CPD y la gestión física de cableado de comunicaciones.

En lo que respecta a las copias de seguridad de datos, estaría gestionada por AWS ofreciendo su garantía. Haciendo uso del servicio Amazon S3 Glacier Vaults o volúmenes de almacenamiento persistentes de instancias EC2 con Amazon EBS (Elastic Block Store) en Amazon S3 en los que cada volumen se replica en una nueva zona de disponibilidad y los backups incrementales de las instancias que se hacen por medio de instantáneas.

Considero que es una buena solución a implementar para garantizar una alta disponibilidad, optimización de recursos de toda la infraestructura virtual y una escalabilidad horizontal automatizada y elástica dependiendo la demanda.



VIDEO DEMO (POC) Y REPOSITORIO GITHUB DEL PROYECTO

Vídeo demo de la prueba de concepto de este proyecto. https://www.youtube.com/watch?v=HzsBiJjgrOo

Se puede encontrar toda la documentación utilizada en este proyecto así como la presentación de slides y este mismo documento en el siguiente repositorio público de Github.

https://github.com/adrianlois/Docker-Swarm-AWS-ASG-ELB

https://www.youtube.com/watch?v=HzsBiJjgrOo

https://github.com/adrianlois/Docker-Swarm-AWS-ASG-ELB



18 BIBLIOGRAFÍA

▪ https://docs.docker.com

(Documentación oficial Docker)

▪ https://www.youtube.com/watch?v=hrGUfQvaFQk&list=PLfW3im2fiA7WoyFLDxP8TtR8UmKdpu3A2 (Curso Docker: Miguel Arranz, 2017 - @mijack)

▪ https://github.com/EvaristoGZ/tutorial-Docker-Swarm/blob/master/Evaristo%20GZ%20-%20Docker%20y%20Docker%20Swarm.pdf (Docker y Docker Swarm: Evaristo García Zambrana, 2017 - @EvaristoGZ)

▪ https://docs.aws.amazon.com (Documentnación oficial AWS)

▪ https://www.youtube.com/watch?v=AR9grGcukPE&list=PLfW3im2fiA7W9F4DbjmRDIZgAHsea20ON (Curso AWS 2018: Miguel Arranz, 2015 - @mijack)

https://docs.docker.com/

https://www.youtube.com/watch?v=hrGUfQvaFQk&list=PLfW3im2fiA7WoyFLDxP8TtR8UmKdpu3A2

https://www.youtube.com/watch?v=hrGUfQvaFQk&list=PLfW3im2fiA7WoyFLDxP8TtR8UmKdpu3A2

https://github.com/EvaristoGZ/tutorial-Docker-Swarm/blob/master/Evaristo%20GZ%20-%20Docker%20y%20Docker%20Swarm.pdf

https://github.com/EvaristoGZ/tutorial-Docker-Swarm/blob/master/Evaristo%20GZ%20-%20Docker%20y%20Docker%20Swarm.pdf

https://docs.aws.amazon.com/

https://www.youtube.com/watch?v=AR9grGcukPE&list=PLfW3im2fiA7W9F4DbjmRDIZgAHsea20ON

https://www.youtube.com/watch?v=AR9grGcukPE&list=PLfW3im2fiA7W9F4DbjmRDIZgAHsea20ON



19 AUTOR Y LICENCIA

Adrián Gómez Lois

[email protected]

https://zonasystem.com

https://twitter.com/adrianlois_

https://t.me/adrianlois

https://github.com/adrianlois

Esta obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-

CompartirIgual 4.0 Internacional.

mailto:[email protected]

https://zonasystem.com/

https://twitter.com/adrianlois_

https://t.me/adrianlois

https://github.com/adrianlois

https://creativecommons.org/licenses/by-nc-sa/4.0/

https://creativecommons.org/licenses/by-nc-sa/4.0/

http://creativecommons.org/licenses/by-nc-sa/4.0/

Implementación Docker Swarm AWS ASG y ELB - …...diferencia es que uno se lanza en modo cliente y...

Documents

Transcript of Implementación Docker Swarm AWS ASG y ELB - …...diferencia es que uno se lanza en modo cliente y...