Docker (5) : Servicios

1. Introducción

Estamos siguiendo al pie de la letra docs-docker.

Recordamos los tres niveles

1. Stack (pila)
2. Services (servicios)
3. Containers (contenedores)

Nos vamos a centrar en el segundo nivel (services)

Entendemos como "service" cada una de las piezas de una aplicación distribuida. Los servicios son contenedores en producción. Si un servicio se "escala" (balancea), se le asigna mas recursos de máquina a aquellas contenedores ejecutando esa pieza de software.

Un servicio se escala mediante un fichero docker-compose.yml 

2. El fichero docker-compose.yml

Creamos el fichero docker-compose.yml en cualquier sitio y copiamos y pegamos estos datos:

version: "3"
services:
  web:
    # replace username/repo:tag with your name and image details
    image: ximodante/get-started:part2
    deploy:
      replicas: 5
      resources:
        limits:
          cpus: "0.1"
          memory: 50M
      restart_policy:
        condition: on-failure
    ports:
      - "80:80"
    networks:
      - webnet
networks:
  webnet:

Con ello:

1. Recogemos la imagen ximodante/get-started:part2 que guadamos en el post anterior
2. Ejecutamos 5 instancias de esa imagen como un servicio llamado web, limitando a cada una, un máximo del 10% de la CPU y 50MB de RAM.
3. Reiniciar el contenedor inmediatamente si falla.
4. Mapea el puerto 80 del host al puerto 80 de web.
5. Se le ordena al contenedor web, que comparta el puerto 80 a través de una red balanceada de cargas llamada webnet. Internamente los contenedores se publican a si mismos al puerto 80 de web, en un puerto efímero.
6. Se define la red webnet con los parametros por omisión (que es una red overlay (capa superior) con carga balanceada).

3. Ejecutar la nueva aplicación con carga balanceada

Para evitar el error; "this node is not a swarm manager", ejecutemos primero:

docker swarm init

Le damos a la aplicación el nombre: getstartedlab mediante el comando

docker stack deploy -c docker-compose.yml getstartedlab

Y nos contesta

Creating network getstartedlab_webnet
Creating service getstartedlab_web

Nuestra "stack" está ejecutando 5 instancias de "containers" de nuestra imagen despeglada en un host. Veamos la id del servicio

docker service ls

Y nos sale:

ID                  NAME                MODE                REPLICAS            IMAGE                         PORTS
vupp9jys8egi        getstartedlab_web   replicated          5/5                 ximodante/get-started:part2   *:80->80/tcp

Se puede ver  el servicio getstartedlab y sus 5 réplicas y su ID vupp9jys8egi

Un único contenedor ejecutándose en un servicio es una "task", que tienen IDs únicos que se incrementan numéricamente hasta el número de réplicas que hayamos definido. Para listar los "tasks"

docker service ps getstartedlab_web

Y nos sale

ID                  NAME                  IMAGE                         NODE                           DESIRED STATE       CURRENT STATE           ERROR               PORTS
pky3rokdocfa        getstartedlab_web.1   ximodante/get-started:part2   eduard-HP-ProDesk-600-G1-SFF   Running             Running 5 minutes ago                       
qdwszjdtqisk        getstartedlab_web.2   ximodante/get-started:part2   eduard-HP-ProDesk-600-G1-SFF   Running             Running 5 minutes ago                       
raamsw062xn5        getstartedlab_web.3   ximodante/get-started:part2   eduard-HP-ProDesk-600-G1-SFF   Running             Running 5 minutes ago                       
62hqh1yi00q5        getstartedlab_web.4   ximodante/get-started:part2   eduard-HP-ProDesk-600-G1-SFF   Running             Running 5 minutes ago                       
g8pdf2pk4f8j        getstartedlab_web.5   ximodante/get-started:part2   eduard-HP-ProDesk-600-G1-SFF   Running             Running 5 minutes ago  

Si pongo en hhtp://localhost en chrome no va, pero si en firefox (o ejecutando curl -4 hhtp://localhost . y si le damos varias, el hostname va cambiando, demostrando que se está blanceando la carga hasta mostrar 5 nombres distintos, correspondientes a los que nos muestra este comando

docker container ls -q

4. Escalar la aplicación

Se puede modificar el docker-compose.yml cambiando las réplicas y guardando el fichero. Si volvemos a ejecutar

docker stack deploy -c docker-compose.yml getstartedlab

Docker realiza una actualización "in-place" (en su sitio, en orden), sin necesidad de parar la "stack" o matar algún "container"

Si volvemos a ejecutar

docker container ls -q

veremos las nuevas instancias reconfiguradas

5. Parar la aplicación

Para desmantelar la aplicación:

docker stack rm getstartedlab

para desmontar el swarm

docker swarm leave --force

6. Resumen de comandos

docker stack ls                                            # List stacks or apps
docker stack deploy -c <composefile> <appname>  # Run the specified Compose file
docker service ls                 # List running services associated with an app
docker service ps <service>                  # List tasks associated with an app
docker inspect <task or container>                   # Inspect task or container
docker container ls -q                                      # List container IDs
docker stack rm <appname>                             # Tear down an application
docker swarm leave --force      # Take down a single node swarm from the manager