Docker en cluster

Initiation à Swarm

Historique de la présentation

ENSG, février 2018
IRD, juin 2018
ENSG, février 2019

Moi

Thibault Coupin

§fragment§icon:briefcase§; IngSys DevOps à l’IRD
§fragment§icon:gear§; Anciennement Chef division WebServices & DevOps au Géoportail
§fragment§icon:envelope-o§; thibault.coupin§icon:at§;gmail.com / §icon:at§;ird.fr
§fragment§icon:github§; tcoupin
§fragment§icon:twitter§; @thibbojunior

Ce cours est :

super intéressant
open-source sous licence GNU GPL
disponible sur
propulsé fièrement par reveal.js via Gh-reveal

Des outils pour déployer facilement un cluster swarm sur des VM sont dispo sur mon github : https://github.com/tcoupin/swarm-playground

Sommaire

§id:sommaire§;

Intro
Les noeuds
Les services
Les stacks
Les volumes
Les réseaux
Config & secret

Intro

§id:intro§;

Pourquoi un cluster ?

Docker et docker-compose contrôle un seul daemon/machine.

§fragmentPour avoir plus de ressources, 2 possibilités :

§fragmentUne grosse machine
§fragmentbeaucoup de machines normales

Pourquoi un cluster ?

Computer food chain §pelement: style=background:rgba(255,255,255,1)§;

Pourquoi un cluster ?

Nouvelles contraintes :

connaître la localisation des applications sur les différents noeuds
répartir la charge
gérer les pannes
…

Comment ?

Contrôler un ensemble de machines en faisant abstraction des machines, elles forment un tout, le cluster.

Fonction d’orchestration

Commander et surveiller les noeuds
Répartir au mieux les applications
Gérer les réseaux, les données, les logs*

* non abordé ici

Historique du clustering dans docker

Swarm standalone : un proxy qui réparti les commandes sur les noeuds.
Swarmkit/swarm mode : natif depuis Docker 1.12 (été 2016), fonction intégrée à Engine, nouveaux concepts de services/stack…

Autres façon

Docker Engine peut aussi être géré en mode cluster par d’autres solutions :

kubernetes (K8s) : solution Google de gestion d’applications conteneurisées
OpenStack : solution open-source de gestion de Cloud, gère majoritairement des VM, peut aussi gérer des containers
Amazon ECS : Elastic Container Service, basé sur des instances Amazon EC2 + docker
Rancher v1 …
…

et donc ?

Swarm : simple, pas très riche
(trop peu pour la production)
K8s : complexe mais très riche
(car pensé pour la production)

Un peu de lecture : Blog Octo.com : Docker en production : la bataille sanglante des orchestrateurs de conteneurs

Retour sommaire

Les noeuds

§id:nodes§;

2+1 typologies

Worker
- Héberge des containers : exécute les ordres donnés par les managers
- Accepte le trafic réseau et le réparti sur les noeuds hébergeant la ressource demandée (ingress)

2+1 typologies

Manager
- Héberge des containers (ou pas)
- Surveille l’ensemble des noeuds (état+containers)
- Accepte le trafic réseau et le réparti sur les noeuds hébergeant la ressource demandée

2+1 typologies

Leader
- Un manager en particulier
- Réparti les demandes en service de l’utilisateur sur les noeuds

Worker

Juste un porte-conteneur…

Manager

Accepte les commandes de gestion
- du cluster
- des réseaux
- des volumes
- des services

Contrainte sur les drivers réseaux et de volumes

Le réseau et les volumes doivent être disponibles sur l’ensemble des noeuds pour que les containers aient le même comportement quelque soit la machine où ils se trouvent.

Réseau : l’overlay network, macvlan… (voir Les réseaux)§fragment

Volume : Infinit, GlusterFS, NFS, HPE 3par, NetApp…(voir Les volumes)§fragment

Labels

Chaque noeud peut être associé à des labels.

Utile pour faire des placements de service en fonction :

de l’architecture matériel
de la salle serveur
du rack
de la zone réseau…

Voir Service/Placement

Retour sommaire

Les services

§id:service§;

Les services

Une couche d’abstraction par rapport au container.

Un service est la définition de l’état désiré :

image, ports, volumes…
nombre d’instances
préférence de placement sur les noeuds du cluster
détection de l’état applicatif
secret et configuration…

Les tasks

Les tasks permettent la réalisation du service

Ce sont les containers sur les noeuds

Service : création

docker service create --name web -p 80:80 emilevauge/whoami

nom du service : web
publication du port 80 sur l’ingress
utilisation de l’image emilevauge/whoami
un seul container

Service : création

Travail du leader :

Liste des noeuds répondant aux contraintes de placement
Choix d’un noeud (le moins chargé tant qu’à faire…)
Ordre de création d’un container sur ce noeud

En plus de ces étapes, l’état du cluster est mis à jour sur l’ensemble des managers.

Service : options utiles

`--bind/--mount`	gestion des volumes
`-p/--publish`	gestion des ouvertures réseau
`--replicas`	nombre d’instances
`--reserve-cpu/--reserve-memory`	besoin en CPU/RAM
`--health-*`	configurer le health-check applicatif
`--update-/--rollback-`	gestion des phases de mise à jour du service

§pelement:style=font-size:80%;§;

Service et tasks

$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                             PORTS
hs40g5qxj3wy        ui                  replicated          2/2                 dockersamples/visualizer:latest   *:8080->8080/tcp

$ docker service ps ui
ID                  NAME                IMAGE                             NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
ticx39oiptf3        ui.1                dockersamples/visualizer:latest   nodeAZ1N1           Running             Running 8 minutes ago                        
l7m1coye9jfy        ui.2                dockersamples/visualizer:latest   nodeAZ2N1           Running             Running 38 seconds ago

Service : réplication

2 modes de déploiement :

replicated : autant d’instances que demandé (par défaut)
global : une instance par noeud répondant aux contraintes de placement

Service : mise à jour

docker service update ...

Quoi ?§fragment:1§;

changement de la configuration§fragment:2§;
changement de l’image (mise à jour applicative)§fragment:2§;

Comment ?§fragment:1§;

mise à jour instance après instance§fragment:3§;
les règles d’update définissent le déroulement§fragment:3§;

Service : mise à jour

… qui a tout cassé !§fragment:1§;

docker service rollback ...§fragment:2§;

En cas de soucis, on revient dans l’état précédent avec un rollback.§fragment:3§;

Il y a aussi des règles de rollback, comme pour l’update.§fragment:3§;

Service : placement constraint

§id:placement§;

Permet de restreindre la liste des machines où peut être déployé le service.

docker service create --constraint 'node.labels.arch == ARM' ...§fragment

Service : placement constraint

node.id	Node ID	node.id==2ivku8v2gvtg4
node.hostname	Node hostname	node.hostname!=node-2
node.role	Node role	node.role==manager
node.labels	user defined node labels	node.labels.security==high
engine.labels	Docker Engine’s labels	engine.labels.operatingsystem==ubuntu 14.04

§pelement:style=font-size:80%;§;

Service : placement preferences

Permet d’influer sur la méthode de répartition utilisée.

Une seule stratégie disponible : spread §fragment:1§;

docker service create --placement-pref 'spread=node.labels.datacenter' \§fragment:1§;
                      --placement-pref 'spread=node.labels.rack' ...

Service : placement preference

Ex : Répartir 12 instances sur les différents datacenters et racks.

Placement preference §pelement:width=70%§;

Source : Documentation Docker

Retour sommaire

Les stacks

§id:stack§;

Stack

Docker monoposte	Docker en swarm
Container	Service
docker-compose	Stack

Une pile…

De services seulement !§fragment

Une stack n’est pas l’équivalent d’un docker-compose.yml. §fragment

Une stack est un ensemble de service. §fragment

Déployer une stack

docker stack deploy ...

Nécessite un fichier de définition de stack :

DAB : Distributed Application Bundle file§fragment
docker-compose.yml… §fragment

Utilisation d’un docker-compose.yml

L’applicatif docker-compose n’est pas utilisé
Certaines options sont nouvelles/différentes/inutilisables
De nouveaux éléments : config, secret (voir les sections TODO)

Docker-compose.yml : les nouveautés

nouvelles sections : config et secret pour les déclarer
nouvelle option deploy pour un service :
- nombre de réplicas
- préférences de placement
- labels sur les services et bien d’autres…
lien entre service et config/secret

Docker-compose.yml : les non compatibles

La liste des options non compatibles avec le mode swarm sur la documentation
Notamment :
- link (voir la section réseau TODO)
- build
- restart

Retour sommaire

Les volumes

§id:volumes§;

Volume plugin

Une interface entre la logique des volumes de docker et le backend utilisé.

create/remove
mount/unmount
path
capabilities …

Documentation

Volume local : sous le capot

Stockage physique : /var/lib/docker/volumes/NOM_VOLUME/_data

Méthode	Action
create/remove	mkdir, rmdir
mount/unmount	pas grand chose
path	retourne `/var/lib/docker/volumes/NOM_VOLUME/_data`
capabilities	indique un scope local

Volume en cluster

Backend accessible depuis tous les noeuds : stockage réseau
Montage/Démontage des volumes réseau lors des créations/suppresion de conteneur
Le path est le point de montage sur le noeud
scope = swarm

Network volume §pelement:width=20%§;

Retour sommaire

Réseau

§id:network§;

Réseau interne §fragment §element:class=grow§;
Réseau externe

Un engine seul

§pelement:width=40%§;

Source: www.kaitoy.xyz

Un engine seul

3 réseaux de base : none, host, bridge
possibilité de créer de nouveaux réseaux de type bridge§fragment
Lien inter-conteneurs :§fragment
- sur le même réseau donc lien IP ok§fragment
- résolution DNS :§fragment
  - native sur les réseaux créés
  - option --link pour le bridge par défaut

Dans un cluster

Lien entre les tasks des services liés
Abstraction de l’emplacement des tasks sur les noeuds

L’overlay network

L'overlay §pelement:width=40%§;

Un réseau présent sur tous les noeuds
Un réseau non dupliqué mais distribué
Créé lors de l’initialisation du swarm

Source : Article Demystifying Docker overlay networking

L’overlay : un tunnel

L'overlay vue physique §pelement:width=40%§;

Utilise un techonologie de VLAN (ici VXLAN)

Source : Article Demystifying Docker overlay networking

L’overlay : d’autres méthodes

D’autres méthodes incluses dans l’engine : IPVLAN, MACVLAN
L’engine est extensible avec des network plugins
- une interface entre l’engine et le backend de réseau
- ex : Contiv (by Cisco)… (voir plus)

DNS

Lorsqu’un service est connecté à un réseau, il bénéficie du service DNS.

`SERVICE`	VIP du service (voir LB juste après)
`tasks.SERVICE`	liste de toutes les ips des tasks

DNS : exemple

# dig httpd

;; ANSWER SECTION:
httpd.      600 IN  A 10.0.1.6

# dig tasks.httpd

;; ANSWER SECTION:
tasks.httpd.    600 IN  A 10.0.1.8
tasks.httpd.    600 IN  A 10.0.1.10
tasks.httpd.    600 IN  A 10.0.1.11
tasks.httpd.    600 IN  A 10.0.1.12
tasks.httpd.    600 IN  A 10.0.1.9
tasks.httpd.    600 IN  A 10.0.1.7

Réseau

Réseau interne
Réseau externe §fragment §element:class=grow§;

Le réseau ingress

Est sur tous les noeuds (overlay)
Gère les relations entre le cluster et le monde extérieur
- bound des ports publiés
- load-balancing IPVS

§pelement:width=40%§;

Source : docker.com

Load balancing

Tous les noeuds (manager ou worker) du cluster exposent les ports publiés par les services
La requête est transférée vers l’IPVS puis vers une des tasks du service
Possibilité d’utiliser un LB externe

§pelement:width=40%§;

Source : docs.docker.com

§icon:arrow-left§; Retour sommaire

Config & secret

§id:configsecret§;

Dissocier l’appication de la configuration

Gestion globale des configurations, en dehors des images
En parallèle//complément de la configuration par variables d’environnement
En finir avec les volumes “config” initialisés à la main…

Les configs

Objet de l’engine avec un workflow (create, inspect, rm, ls)
Encodé en base64 (texte, image, …) dans le swarm
- disponibilité par réplication
- cohérence grâce à l’algo raft du swarm
Monté dans les containers

Les secrets

Comme une config +

Encodage (non lisible avec la commande inspect)
Déployé dans l’espace mémoire du container et non dans l’espace stockage

Pour les données sensibles : mot de passe, clé SSL, certificat…

CLI

docker config create NOM FILE
ou
echo "ma config" | docker config create NOM -

docker config ls

docker config rm NOM

De même pour les secrets…

Utilisation dans un service

docker service create --config NAME IMAGE
# Sera accessible à /NAME

docker service create --config src=NAME,target=/path/to/file IMAGE
# Sera accessible à /path/to/file

Par défault un secret est accessible dans /run/secrets/NAME

Config et docker-compose.yml

version: "3.3"
services:
  redis:
    image: redis:latest
    deploy:
      replicas: 1
    configs:
      - my_config
      - my_other_config
configs:
  my_config:
    file: ./my_config.txt
  my_other_config:
    external: true

Config et docker-compose.yml

version: "3.3"
services:
  redis:
    image: redis:latest
    deploy:
      replicas: 1
    configs:
      - source: my_config
        target: /redis_config
        uid: '103'
        gid: '103'
        mode: 0440
configs:
  my_config:
    file: ./my_config.txt
  my_other_config:
    external: true

Secret et docker-compose.yml

version: "3.1"
services:
  redis:
    image: redis:latest
    deploy:
      replicas: 1
    secrets:
      - my_secret
      - my_other_secret
secrets:
  my_secret:
    file: ./my_secret.txt
  my_other_secret:
    external: true

Secret et docker-compose.yml

version: "3.1"
services:
  redis:
    image: redis:latest
    deploy:
      replicas: 1
    secrets:
      - source: my_secret
        target: redis_secret
        uid: '103'
        gid: '103'
        mode: 0440
secrets:
  my_secret:
    file: ./my_secret.txt
  my_other_secret:
    external: true

C’est déjà fini

§icon:arrow-left§; Retour sommaire