Docker Swarm & Portainer UI où l'orchestration à moindre frais.

Sommaire

• Introduction
• Docker swarm
  • Commandes pour gérer un cluster Swarm
• Portainer
  • Introduction à Portainer
  • Fonctionnalités utiles
• Conclusion

Introduction

De nos jours, il est courant et fortement recommandé de mettre en place de la "conteneurisation", souvent au travers de la technologie Docker qui a accéléré la tendance depuis 10 ans :

Dans une équipe de développements applicatifs, sur l'environnement de développement :

• avoir des images prêtes à l'emploi : par exemple une image du serveur d'applications, que toute l'équipe utilise, sur la même base de modules et versions, annuaire LDAP, base de données, etc
• facilité de mise en place d'images, facilement déployables sur chaque station de travail : une image est légère et son exécution sera rapide, pour tester ou effectuer des POC, cela s'avère plus accessible
• une gestion des dépendances (versions des packages, modules, ...) nettement améliorée et contrôlée

Dans un environnements de tests ou de production

Ces images pourront être packagées pour une utilisation sur une plateforme de tests et / ou la plateforme de prod, de façon rapide et efficace : déploiements facilités et mise en production efficiente.

Sur un environnement de production, il y aura régulièrement plusieurs instances d'applications sur plusieurs VM / serveurs, afin d'absorber la charge des accès utilisateurs (répartition de charge), il va donc falloir déployer toutes ces images applicatives sous forme de conteneurs légers vers ces différentes instances de machines, et ensuite, s'assurer d'orienter tel flux (https, accès base, etc) vers tels conteneurs : cette façon de faire se nomme de l'orchestration de conteneurs, qui va également gérer le cycle de vie des conteneurs : scaling, création, déploiement / rechargement pour aller vers du Zero downtime deployment, load-balancing, la communication entre les containers etc

Docker propose un orchestrateur natif à leur technologie, dans le moteur de conteneurs : Docker Swarm, où l'on va retrouver nos habitudes :

• avec le docker CLI
• le docker-compose Yaml, du déclaratif, qui servira aussi à la gestion des conteneurs dans Swarm (stack)

Docker swarm & Portainer

Vocabulaire

Worker = un nœud du cluster Swarm, une VM ou une machine physique

Manager = un nœud spécial du cluster Swarm qui aura pour charge d'orchestrer les services / containers du cluster (flux, déploiements, load balancing et haute disponibilité des services exposés), tel un chef d'orchestre ! Un manager peut aussi jouer le rôle de worker.

Stack = un "fichier" docker-compose dans lequel ait décrit les services avec les règles associées : d'images sources à utiliser, de déploiement, de ressources (volumes, networks, ...voire CPU & co)

Service = un élément d'une stack à déployer selon des règles

Task = un container déployé sur un / des noeuds

Registry docker

Dans un écosystème où l'orchestration demande des images pour les transformer en conteneurs ("instances" d'une image), il est nécessaire d'avoir un registry docker qui permettra de stocker ces images à déployer :

• le Docker Hub en est un

ou avoir une machine registry dédiée à cela :

• via une solution légère de type registry développé par Docker et disponible sur le Hub
• via une solution avec une interface Web de type harbor / github

Docker swarm

Docker swarm est inclus dans le moteur docker, c'est un orchestrateur de containers, qui permettra de gérer sur un ensemble de machines / VM, les containers sur chacune de ces instances (flux, déploiement, cycle de vie, répartitions et disponibilité), et, avouons-le, la mise en place reste accessible et rapide, une fois les concepts appréhendés.

Un cluster Swarm a plusieurs nœuds avec au moins 2 nœuds, selon 2 types :

• de type manager : aura la mission de diriger les flux entrants vers les nœuds (load balancer) et la gestion de l'orchestration des conteneurs : réplication dans le cluster, déploiement / rechargement des services, load-balancing. Il est conseillé d'avoir un nombre de manager impairs et au moins 3, selon l'algorithme Raft. Un manager peut aussi jouer le rôle de worker
• de type worker, on pourra avoir plusieurs nœuds de ce type, afin de répartir la charge, un noeud à différents état : Active, Drain et Pause. Le mode Drain permettra de dire au manager de ne plus déployer vers les nœuds worker les services et donc d'arrêter les flux vers celui-ci. Le Pause, que j'utilise rarement, permet de suspendre tous les processus dans les containers contenus sur le nœud, en revanche, les flux continuent à être dirigés vers ce dernier.

Schématiquement, un cluster composé de managers et de workers se représentera ainsi :

Source : https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/

Le cluster swarm se gère avec la commande docker (CLI), tout comme on le ferait habituellement avec des images / containers /... en local d'une machine, c'est le gros avantage, on ne perd pas ses habitudes :)

Quelques commande avec le docker CLI

Les commandes ont le plus souvent une aide, il suffit d'utiliser l'option --help pour avoir la liste des arguments possible.

Le docker CLI permet de gérer un cluster swarm, quelques commandes que j'utilise régulièrement, hormis l'initialisation :

Swarm

• initialisation d'un cluster swarm

$ docker swarm init --advertise-addr IP_MANAGER:2377

• informations sur le cluster

$ docker info

• obtenir un TOKEN worker / node à partir du manager

$ docker swarm join-token worker
docker swarm join --token SWMTKN-1-id1-id2 IP_MANAGER:2377

• faire rejoindre une machine sur le cluster en tant que worker

A partir de la commande donnée précédemment, il suffit de la recopier à partir d'une machine cluster

$ docker swarm join --token SWMTKN-1-id1-id2 IP_MANAGER:2377

• worker / noeud : faire quitter un noeud du cluster, à partir d'un noeud :

* docker swarm leave

Noeud(s)

• liste des noeuds

$ docker node ls

• liste des containers / tâches des noeuds ou d'un noeud

$ docker node ps
$ docker node ps <NODE_NAME>

• modifier l'état d'un noeud

$ docker node <ID_NODE> --availability "drain"
$ docker node <ID_NODE> --availability "active"

Stack(s)

• liste des stacks du cluster contenant, pour chacun, des services

$ docker stack ls 
NAME                SERVICES            ORCHESTRATOR
api-XYZ             7                   Swarm
ws                  1                   Swarm
fluend              3                   Swarm
ABC                 7                   Swarm
loki-grafana        3                   Swarm
portainer           2                   Swarm
prometheus          8                   Swarm

• liste des containers / tâches d'une stack

$  docker stack ps <STACK_NAME>

• liste des services d'une stack (un service correspond à une section du docker compose)

$ docker stack services fluend

Service(s)

• liste des services d'un noeud

$ docker service ls

• informations d'un service

$ docker service inspect --pretty <SERVICE_NAME>

• liste des containers d'un service avec répartition sur les noeuds

$ docker service ps <SERVICE_NAME>
$ # ou enlever le troncage du log de démarrage et la résolution DNS
$ docker service ps <SERVICE_NAME> --no-resolve --no-trunc

• rechargement d'un service

# forcer le redéploiement d'un service
$ docker service update --force <SERVICE_NAME>

• réplication d'un service

# réplication à 2 d'un service
$ docker service scale <SERVICE_NAME>=2

• logs d'un service

$ docker service logs <SERVICE_NAME> -f

• liste des configurations du cluster

$ docker config ls 

Config(s)

• lire une config

$ docker config inspect <CONFIG_NAME> --pretty

Portainer

Introduction

Portainer est une application qui propose une interface Web qui vous aidera à gérer votre cluster, à la place de la ligne de commande qui peut s'avérer rébarbative ou tout simplement pour simplifier la connaissance de toutes les options possible du CLI docker pour gérer le cluster ou tout simplement pour avoir une meilleure vue du cluster, sous forme de tableau de bord.

Comme vous avez pu le voir sur le docker CLI, il y a beaucoup d'options ou d'arguments à connaitre pour gérer son cluster, même s'il est bien de les savoir au cas où portainer venait à ne plus fonctionner, pour reprendre à la main le cluster.

Portainer prend en charge docker et docker swarm et à partir de la version 2.x, permet aussi de gérer en plus un cluster de type Kubernetes, K8s de son petit nom qui est un autre orchestrateur de containers très en vogue.

Portainer est livré sous forme d'images, soit à utiliser en "local" (sur une VM contenant des containers) pour gérer votre écosystème docker, soit à déployer en tant que stack dans le cluster (ie : fichier docker-compose YAML) qui contiendra le service portainer ("serveur") et agent ("client" pour portainer), ce dernier sera déployé sur l'ensemble des workers / noeuds, manager compris.

La version mise en place est la version communautaire (CE), avec un fichier compose docker-compose.yml contenant

version: '3.2'

services:
  agent:
    image: portainer/agent:2.21.2
    environment:
      # REQUIRED: Should be equal to the service name prefixed by "tasks." when
      # deployed inside an overlay network
      AGENT_CLUSTER_ADDR: tasks.agent
      # AGENT_PORT: 9001
      LOG_LEVEL: debug
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    networks:
      - agent_network
    deploy:
      mode: global

  portainer:
    image: portainer/portainer-ce:2.21.2
    command: -H tcp://tasks.agent:9001 --tlsskipverify
    ports:
      - "9000:9000"
      - "9443:9443"
    volumes:
      - portainer_data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    networks:
      - agent_network
    deploy:
      mode: replicated
      replicas: 1
      placement:
        constraints: [node.role == manager]

networks:
  agent_network:
    driver: overlay

volumes:
  portainer_data:

Pour rappel : le mode global déploie le service (ici les agents portainer) sur tous les nœuds du cluster, pour le serveur portainer, il ne déploiera le service uniquement sur le manager swarm. Le type / driver docker utilisé est overlay, qui permet d'avoir un réseau "virtuel" entre les machines du cluster docker swarm.

Il suffit, sur notre cluster prêt (un manager / un worker) de déployer portainer avec un deploy, cela va créer la stack portainer en déploiement l'agent et le manager.

$ docker stack deploy -c docker-compose.yml portainer

Les services de la stack portainer ont bien été déployés :

$ docker stack services portainer
ID                  NAME                  MODE                REPLICAS            IMAGE                        PORTS
nno3g01x4vl2   portainer_agent       global       11/11      portainer/agent:2.21.2
o3uf3hajvbb4   portainer_portainer   replicated   1/1        portainer/portainer-ce:2.21.2   *:9000->9000/tcp, *:9443->9443/tcp

Vous pouvez alors accéder à l'interface Portainer via le port 9000 ou via un reverse proxy devant le cas échéant afin initialiser le compte admin

Fonctionnalités utiles

Portainer propose un ensemble de fonctionnalités qui va nous soulager dans la gestion de notre cluster swarm, parmi lesquelles :

1 : tableau de bord synthétique des stacks, images, volumes, containers, etc, avec la possibilité d'avoir une vue sur des containers actifs sur chacun des noeuds du cluster

2 : vous accéderez à l'ensemble de vos stacks afin d'en créer, en supprimer ou voir le détail des services déployés (containers / tasks) de la stack : redéployer une stack (pour une mise en production par exemple avec de nouvelles images), modifier le docker-compose associé qui décrit la stack avec, en plus du compose habituel docker, ses règles de déploiements, de loggin, etc

Par exemple, sur la stack prometheus, a 4 services, décrit dans le compose (cf. Editor) : prometheus_alertmanager, prometheus_caddy, prometheus_cadvisor, prometheus_dockerd-exporter, ...

Les noms des services sont nommés selon le motif : nom_de_la_stack_nom_du_service

Nous aurons 2 onglets :

• un général pour recharger / mettre à jour, entrer en mode console dans un container, avoir des logs ou l'information (inspect) d'un container, l'état des containers / tasks, le scaling / réplication opérées, et un onglet
• pour éditer le docker-compose de cette stack.

Sur une stack

1- onglet Stack :

3- : pouvoir filtrer les containers / tasks sur un service
4- : permet d'avoir dans l'ordre des icones : les logs du container (stdout / stderr des process du container, par ex. les logs nginx), les infos (inspect docker) de celui-ci : cela peut être utile pour avoir de l'informations sur d'éventuelles erreurs d'un container qui ne voudrait pas se lancer (en failed / shutdown), des stats (mémoire, CPU, flux réseau et les process lancés dans le container), accéder à la console du container
5- : permet de recharger les services de la stack, en cochant ceux souhaités : soit en recharge simple vers les noeuds (reploiement des services de la stack), soit en forçant le pull des images du compose (cf. Editor) pour redéploiement.

1- onglet "Editor" : permet d'écrire un compose (lors d'une création d'une stack ou sa mise à jour), en Yaml, qui reprend la syntaxe du docker-compose avec en plus des sections propres à Swarm (section deploy qui donnera les règles de déploiement /réplication / contraintes, ressources, section *configs les configurations à monter lorsqu'il y en a besoin)

Le bouton "Update the stack" permet de déployer toute la stack sur le cluster et ses services décrits dans le compose une fois modifié le compose

3 : les services déployés sur les nœuds du cluster et les containers / tasks associés et leur état, des actions seront possible : rechargement, suppression voire création de service (mais on passera plus volontiers par de la gestion de stack via un compose), indications de la répartition des containers (replicas)

4 : liste des containers du cluster swarm avec la possibilité de les filtrer selon leur état ("running", "stopped", "created", "healthy") et d'opération une action dessus : en supprimer (très utile pour effectuer un ménage de temps en temps), en relancer, voire en créer ou d'entrer en mode console dans un container

5 : liste des images du cluster : vous permettra de faire un peu le ménage de temps en temps afin de supprimer les images inutilisées

6 : volumes : les volumes dockers utilisés ou non sur les différents nœuds : cela peut être pratique de repérer les volumes inutilisés à supprimer. On peut aussi en créer mais je passe la plupart par les stacks et un docker-compose. Les volumes sont soient locaux à un noeud (par exemple, le volume portainer de portainer déployé uniquement sur un noeud manager, ou via des partages réseaux de NFS, Longhorn, ... qui permettra un accès de plusieurs noeuds sur ces partages)

7 : les configurations docker qui seront utilisées dans les services, où l'on peut en créer ou en cloner (à la place d'une modification qui n'est pas possible en état). Sur une instance isolée, nous utilisons les volumes pour monter un répertoire, un fichier dans le container. Dans un environnement distribué, un cluster de machines, ces fichiers doivent être centralisé (sur le manager) afin de le distribuer sur chacun des noeuds, ce à quoi servent les configurations sauf à les inclure lors de la création de l'image, mais cela rendra moins souple leur gestion, cela dépend.

Par exemple, la configuration fluent-elasticsearch-conf.v2 aura ce type de contenu

<source>
  @type  forward
  @id    input1
  @label @mainstream
  port  24224
</source>

<filter **>
  @type stdout
</filter>

<label @mainstream>
  <match api-prod>
    @type copy
    <store>
        @type file
        @id   output_docker1
        path         /fluentd/log/api-prod.*.log
        symlink_path /fluentd/log/api-prod.log
        append       true
        time_slice_format %Y%m%d
        time_slice_wait   1m
        time_format       %Y%m%dT%H%M%S%z
        compress gzip
        utc
       format json
    </store>
    </match>
</label>

La config fluent-elasticsearch-conf.v2 pour être utilisée dans une stack comme suit, grâce à la section configs :

version: "3.6"
configs: # déclaration de la config à prendre
  fluent-elasticsearch-conf.v2:
    external: true

services:
  fluentd:
    image: fluend:latest
    volumes:
      - /home/root/data/logs:/fluentd/log
    ports:
      - "24224:24224"
      - "24224:24224/udp"
    networks:
      - net
    deploy:
      mode: replicated
      replicas: 1
      placement:
        constraints: [node.labels.type == fluent]
    configs: # montage de la config vers la target
      - source: fluent-elasticsearch-conf.v2
        target: /fluentd/etc/fluent.conf

8 : vue synthétique des nœuds du cluster et de leur état, permettra de changer leur état ("Active" => "Drain" notamment) ou d'ajouter / modifier des labels sur les nœuds, ces labels pourront servir pour les règles de déploiement d'un service , sur ses contraintes (cf. deploy d'un service dans le compose)

Par exemple, le label nginx avec une valeur true pourra être une contrainte pour un service nginx pour son déploiement : déploie l'image nginx sur 3 noeuds ayant un label nginx avec une valeur à true

9 : gestion des dépôts d'images docker : soit DockerHub, soit le registry de votre écosystème : les images des stacks pourront alors être prise du registry paramétré

Conclusion

Docker swarm peut être mis en place relativement rapidement, bien entendu, charge à vous de construire vos images et les VM qui hébergeront manager et workers.

Pour sa gestion, portainer permet de gérer votre cluster directement en ligne, pour la majeure partie des fonctionnalités de swarm, et...c'est très appréciable.

Katacoda propose d'essayer Portainer directement en ligne, avec les VM provisionnées, un bac à sable pour découvrir ces technologies : https://www.katacoda.com/portainer/scenarios/deploying-to-swarm