Cours - Docker

La formation à 360°
Administration de Docker
Document reprenant les étapes de configurations et

administrations concernant Docker
Référence : EF-VIRTU-DOCKER
Auteur(s) : Destinataire(s) :
Dorian Manzanares Easyformer
Alex Falzon
Date de modification : 12/11/21 Version : 1
Easyformer - 12 rue des violettes - 95000 Cergy

Email : info@easyformer.fr Web : www.easyformer.fr
Document réservé aux formateurs EasyFormer
Référence : EF-VIRTU-
Administration de Docker Version : 1
DOCKER
Sommaire page
1 INTRODUCTION ....................................................................................................................................... 6
1.1 HISTORIQUE DE LA VIRTUALISATION ................................................................................................................ 6
1.2 TIME SHARING ........................................................................................................................................... 6
1.3 MULTI PROGRAMMING ................................................................................................................................ 7
2 LA VIRTUALISATION ................................................................................................................................. 8
2.1 LES TYPES DE VIRTUALISATIONS ...................................................................................................................... 8
2.1.1 Serveur .............................................................................................................................................. 8
2.1.2 Application ........................................................................................................................................ 8
2.1.3 Postes de travail ................................................................................................................................ 8
2.1.4 Stockage ............................................................................................................................................ 8
2.2 LES TECHNOLOGIES DE VIRTUALISATION ........................................................................................................... 9
2.2.1 Complète ........................................................................................................................................... 9
2.2.2 Hybride .............................................................................................................................................. 9
2.2.3 Applicative ......................................................................................................................................... 9
2.2.4 Para-virtualisation ........................................................................................................................... 10
2.2.5 HAL .................................................................................................................................................. 10
2.2.6 Virtualisation assistée par matériel ................................................................................................. 11
3 DOCKER ................................................................................................................................................. 12
3.1 INTRODUCTION ........................................................................................................................................ 12
3.1.1 Présentation de Docker ................................................................................................................... 12
3.1.2 Principe de Docker ........................................................................................................................... 12
3.2 INSTALLATIONS ET CONFIGURATIONS ............................................................................................................ 13
3.2.1 Prérequis ......................................................................................................................................... 13
3.2.2 Bonnes pratiques ............................................................................................................................. 13
3.2.3 Ubuntu............................................................................................................................................. 13
3.2.4 Installation sous Linux ..................................................................................................................... 14
3.2.5 Docker ............................................................................................................................................. 15
3.2.6 Docker-hub ...................................................................................................................................... 17
3.3 UTILISATION DE DOCKER ............................................................................................................................ 18
3.3.1 Les commandes informatives .......................................................................................................... 18
3.3.2 Les commandes gestion d’images ................................................................................................... 19
3.3.3 Les commande de gestion des conteneurs ...................................................................................... 19
Run ............................................................................................................................................................................. 19
Exec ............................................................................................................................................................................ 20
Log ............................................................................................................................................................................. 20
Commit ...................................................................................................................................................................... 21
Autres commandes de gestion des conteneurs ......................................................................................................... 22
3.4 INTERFACE GRAPHIQUE .............................................................................................................................. 23
3.4.1 Shipyard........................................................................................................................................... 23
Proxy .......................................................................................................................................................................... 24
Contrôleur.................................................................................................................................................................. 25
3.4.2 Portainer.......................................................................................................................................... 27
3.5 GESTION DES CONTENEURS ......................................................................................................................... 28
3.5.1 Images Docker ................................................................................................................................. 28
3.5.2 Conteneurs ...................................................................................................................................... 31
3.5.3 Gérer les conteneurs et images ....................................................................................................... 32
Validation des modifications ..................................................................................................................................... 34
3.5.4 Exporter une image dans le Docker hub .......................................................................................... 35
3.5.5 Communication entre conteneurs ................................................................................................... 36
3.5.6 Monter un répertoire hôte dans un conteneur ................................................................................ 36
3.5.7 Conteneur de données ..................................................................................................................... 37
Document reprenant les étapes de configurations et administrations
Page 2 sur 97
concernant Docker
© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

DOCKER
3.5.8 Swarm ............................................................................................................................................. 38

Swarm manager ......................................................................................................................................................... 39
Swarm Agent ............................................................................................................................................................. 40
3.5.9 Kubernetes ...................................................................................................................................... 41
3.6 INSTALLATION ET CONFIGURATION DE KUBERNETES ......................................................................................... 41
3.6.1 Introduction ..................................................................................................................................... 41
3.6.2 Préparation des hôtes ..................................................................................................................... 42
Désactiver la Swap ..................................................................................................................................................... 43
3.6.3 Installation des Kubeadm ................................................................................................................ 43
3.6.4 Initialisation du cluster .................................................................................................................... 44
Ajout des nœuds de travail au cluster ....................................................................................................................... 48
Réalisation des tests .................................................................................................................................................. 49
4 OUTILS DOCKER ..................................................................................................................................... 55

4.1 ORCHESTRATION ET ORDONNANCEUR ........................................................................................................... 55
4.1.1 Kubernetes ...................................................................................................................................... 55
4.1.2 Swarm ............................................................................................................................................. 56
4.1.3 Mesosphere DC/OS .......................................................................................................................... 56
4.1.4 Amazon ECS ..................................................................................................................................... 57
4.1.5 Service de conteneur Azure (AKS) .................................................................................................... 57
4.1.6 Google Contanier Engine (GKE) ....................................................................................................... 58
4.1.7 Cloud Foundry’s Diego ..................................................................................................................... 58
4.1.8 Marathon ........................................................................................................................................ 59
4.1.9 HashiCorp Nomad ........................................................................................................................... 59
4.1.10 Hélios .......................................................................................................................................... 60
4.1.11 Rancher ....................................................................................................................................... 60
4.1.12 Nebula ......................................................................................................................................... 60
4.2 INTEGRATION CONTINUE ............................................................................................................................ 61
4.2.1 Jenkins ............................................................................................................................................. 61
4.2.2 CircleCI ............................................................................................................................................. 61
4.2.3 Travis CI ........................................................................................................................................... 62
4.2.4 CodeShip .......................................................................................................................................... 62
4.2.5 GitLab CI .......................................................................................................................................... 63
4.2.6 Shippable ......................................................................................................................................... 63
4.2.7 CodeFresh ........................................................................................................................................ 64
4.2.8 Buddy............................................................................................................................................... 64
4.2.9 Drone ............................................................................................................................................... 65
4.2.10 Wercker ....................................................................................................................................... 65
4.3 SURVEILLANCE ......................................................................................................................................... 66
4.3.1 Sumo Logic ...................................................................................................................................... 66
4.3.2 Prometheus ..................................................................................................................................... 66
4.3.3 Sysdig .............................................................................................................................................. 67
4.3.4 Moniteur Sysdig............................................................................................................................... 67
4.3.5 Datadog........................................................................................................................................... 67
4.3.6 Nouvelle relique............................................................................................................................... 68
4.3.7 cAdvisor ........................................................................................................................................... 68
4.4 ENREGISTREMENT ..................................................................................................................................... 69
4.4.1 Logspout .......................................................................................................................................... 69
4.4.2 Fluentd ............................................................................................................................................ 69
4.4.3 Logstash .......................................................................................................................................... 69
4.4.4 Syslog-ng ......................................................................................................................................... 70
4.5 SÉCURITÉ ................................................................................................................................................ 71
4.5.1 Clair ................................................................................................................................................. 71
4.5.2 Aqua security ................................................................................................................................... 71
4.5.3 Twistlock.......................................................................................................................................... 72
4.5.4 Docker bench for security ................................................................................................................ 72

Page 3 sur 97
concernant Docker

DOCKER
4.5.5 Notary Docker ................................................................................................................................. 72

4.6 STOCKAGE ............................................................................................................................................... 73
4.6.1 Convoy ............................................................................................................................................. 73
4.6.2 Portworx .......................................................................................................................................... 73
4.6.3 Blockbridge ...................................................................................................................................... 73
4.7 MISE EN RESEAU....................................................................................................................................... 74
4.7.1 Flannel ............................................................................................................................................. 74
4.7.2 Weaveworks .................................................................................................................................... 74
4.7.3 Projet Calico .................................................................................................................................... 75
4.8 DECOUVERTE DE SERVICE ........................................................................................................................... 76
4.8.1 Consul .............................................................................................................................................. 76
4.8.2 Etcd.................................................................................................................................................. 76
4.8.3 Procuration ...................................................................................................................................... 76
4.9 BUILD..................................................................................................................................................... 77
4.9.1 Packer .............................................................................................................................................. 77
4.9.2 Whales............................................................................................................................................. 77
4.9.3 Gradle .............................................................................................................................................. 77
4.10 GESTION GRAPHIQUE ................................................................................................................................ 78
4.10.1 Portainer ..................................................................................................................................... 78
5 GLOSSAIRE ............................................................................................................................................. 79
6 WEBOGRAPHIE ...................................................................................................................................... 80
7 ANNEXE : COMPARATIF DES SOLUTIONS RESEAUX POUR KUBERNETES ................................................. 81
7.1 FONCTIONNEMENT DE KUBERNETES ............................................................................................................. 81
7.2 RESEAUX K8S PAR DEFAUT ......................................................................................................................... 81
7.3 SOLUTION UTILISANT CNI ET UN PLUGIN RESEAU............................................................................................. 82
7.4 A PROPOS DE CONTAINER NETWORK INTERFACE ............................................................................................. 82
7.5 K8S COMPARAISON DE DIFFERENTES SOLUTIONS CNI + PLUGIN ......................................................................... 82
7.6 CALICO ................................................................................................................................................... 83
7.6.1 Présentation .................................................................................................................................... 83
7.6.2 Fonctionnement .............................................................................................................................. 83
7.6.3 Utilisation ........................................................................................................................................ 83
7.6.4 Réseau Calico .................................................................................................................................. 84
7.6.5 Déploiement .................................................................................................................................... 85
7.7 CILIUM ................................................................................................................................................... 86
7.7.1 Présentation .................................................................................................................................... 86
7.8 BPF – BERKELEY PACKET FILTER .................................................................................................................. 86
7.8.1 Présentation .................................................................................................................................... 86
7.8.2 Fonctionnement .............................................................................................................................. 86
7.8.3 Utilisation ........................................................................................................................................ 87
7.8.4 Réseaux Cilium ................................................................................................................................ 88
7.8.5 Déploiement .................................................................................................................................... 89
7.9 CONTIV .................................................................................................................................................. 90
7.9.1 Fonctionnement .............................................................................................................................. 90
7.9.2 Utilisation ........................................................................................................................................ 90
7.9.3 Déploiement .................................................................................................................................... 92
7.10 FLANNEL................................................................................................................................................. 93
7.10.1 Présentation ................................................................................................................................ 93
7.10.2 Utilisation .................................................................................................................................... 93
7.10.3 Déploiement ................................................................................................................................ 94
7.11 WEAVENET ............................................................................................................................................. 95
7.11.1 Présentation ................................................................................................................................ 95
7.11.2 Fonctionnement .......................................................................................................................... 95
7.11.3 Utilisation .................................................................................................................................... 95
7.11.4 Réseau Weave............................................................................................................................. 95
Page 4 sur 97
concernant Docker

DOCKER
7.11.5 Déploiement ................................................................................................................................ 96

7.12 CONCLUSION ........................................................................................................................................... 96
7.13 RECAPITULATIF ......................................................................................................................................... 97

Page 5 sur 97
concernant Docker

DOCKER
1 Introduction
1.1 Historique de la virtualisation
Bien que la virtualisation soit très à la mode de nos jours et au cœur des préoccupations de
la majeure partie des services informatiques, ce n'est pas un concept nouveau.
A l'origine les premiers ordinateurs conçus ne permettaient l'exécution que d'une seule
application à la fois.
Dans les années 1960, IBM développe la première technologie de virtualisation permettant à
une plateforme mainframe (super-ordinateur) d'exécuter au sein de pseudo-machines
(machines virtuelles aujourd'hui) plusieurs instances d'application en parallèle, sous le
contrôle d'un programme (hyperviseur aujourd'hui) dont la fonction était d'allouer les
ressources et isoler ces instances.
Les notions suivantes voient le jour…
1.2 Time sharing
Le temps partagé ou pseudo-parallélisme1, est une approche permettant de simuler le

partage par plusieurs utilisateurs de temps processeur. Il ne faut pas le confondre avec le
terme de multitâche : un système peut être multitâche sans être à temps partagé (par
exemple s'il dispose de pilotes effectuant des tâches de fond asynchrones) ; il a également
existé quelques systèmes de temps partagé qui n'étaient pas multitâches : le processeur
divisait simplement son temps en tranches fixes.

Page 6 sur 97
concernant Docker

DOCKER
1.3 Multi programming
En 1978, l'architecture X86 qui désigne la famille de microprocesseurs utilisant les jeux
d'instructions du même nom fait son apparition et s'impose durant la décennie suivante
comme le modèle à suivre. De nos jours encore le X86 équipe la majorité des
microprocesseurs à destination des postes de travail et des serveurs.
X86 est un terme que l'on retrouve souvent dans les documents de virtualisation, ici il
désigne une famille de processeurs qui équipent un grand nombre de nos équipements
informatiques (postes de travail, serveurs, ...). Il s'est imposé comme un modèle à suivre et
on retrouve cette architecture de puces aujourd'hui dans la majorité des processeurs vendu
par les fabricants (Intel, AMD, Via).
Ce jeu d’instructions s'appuie à l’origine sur le CISC (Complex Instruction Set Computer) bien
qu’il tende à évoluer vers le RISC (Reduced Instruction Set Computer) sur les dernières
puces. On trouve du RISC dans la plupart des processeurs ARM de nos équipements
informatiques mobiles (téléphones, Tablettes, ...).
En 1999 VMWARE invente une solution de virtualisation pour les architectures X86 pour
répondre principalement aux contraintes de sous-utilisation des ressources matérielles et la
popularise via la sortie de son premier produit Vmware Workstation 1.0.
En 2005, Intel-VT puis en 2006, AMD-V) sont les 2 technologies de virtualisation matérielle
assistée, développées par Intel et AMD pour répondre aux contraintes de privilèges des
architectures X86.

Page 7 sur 97
concernant Docker

DOCKER
2 La virtualisation
2.1 Les types de virtualisations
La virtualisation est l'ensemble des techniques matérielles et logicielles permettant de

fournir un ensemble ou sous-ensemble de ressources informatiques de manière qu'elles
puissent être utilisées, avec avantages, de manière indépendante de la plateforme
matérielle.
Il existe différents types de virtualisation :
• La virtualisation de serveur
• La virtualisation d’application
• La virtualisation de postes de travails
• La virtualisation de stockage
2.1.1 Serveur
La virtualisation de serveur permet de regrouper plusieurs serveurs physiques sous-
employés sur un seul hôte qui exécute des systèmes virtuels. Il permet aussi de réduire la
consommation électrique et le nombre d’administrateurs. Il participe beaucoup à la
réalisation des économies (locaux, consommation électrique).
2.1.2 Application
Elle permet de séparer complètement l'application du système d'exploitation hôte et des
autres applications présentes afin d'éviter les conflits. En outre elle peut être définie comme
la technologie qui permet de séparer l'environnement du bureau et des applications
associées de la machine physique.
2.1.3 Postes de travail

La virtualisation des postes de travails facilite le travail des administrateurs systèmes et
réseaux. Un poste de travail virtualisé ou bureau virtuel peut être hébergé soit directement
sur l’ordinateur du client soit sur un serveur dans le centre de données.
2.1.4 Stockage
La virtualisation des stockages permet :
• D’exploiter au maximum les ressources,

• D’exploiter au mieux le stockage des disques durs,
• Centraliser et sécuriser les données
Le centre de donnée s’articule autour d'un SAN (Storage Area Network).
Un des plus grands défis de la virtualisation reste le stockage.
Dans les faits, c’est le plus souvent le stockage qui fait exploser les coûts, et crée des
engorgements et des pertes de performances.
Page 8 sur 97
concernant Docker

DOCKER
2.2 Les technologies de virtualisation

2.2.1 Complète
La virtualisation complète est une virtualisation dans laquelle le système d'exploitation invité ne sait
pas qu'il se trouve dans un environnement virtualisé et, par conséquent, le matériel est virtualisé par
le système d'exploitation hôte, de sorte que l'invité peut émettre des commandes sur ce qu'il
considère être du matériel réel, mais qu'il ne fait que simuler les périphériques matériels créés par
l'hôte.
2.2.2 Hybride
Il existe également une combinaison de virtualisation complète et de paravirtualisation
appelée virtualisation hybride, dans laquelle des parties du système d'exploitation invité
utilisent la paravirtualisation de certains pilotes matériels et l'hôte utilise la virtualisation
complète pour d'autres fonctionnalités. Cela produit souvent des performances supérieures
sur l'invité sans qu'il soit nécessaire de complètement paravirtualiser l'invité.
Par exemple l'invité utilise la virtualisation complète pour les instructions privilégiées dans le
noyau, mais la paravirtualisation pour les demandes d'E/S (Entrées/Sorties) utilisant un
pilote spécial dans l'invité. De cette façon, le système d'exploitation invité n'a pas besoin
d'être complètement paravirtualisée, car cela n'est parfois pas disponible, mais peut
toujours profiter de certaines fonctionnalités paravirtualisées en implémentant des pilotes
spéciaux pour l'invité.
2.2.3 Applicative
Le principe de la virtualisation applicative consiste à générer un exécutable à partir du
programme d'installation (par exemple Word). Celui-ci se lance alors physiquement en local
(et non pas depuis un autre point du réseau) sans que l'on installe quoi que soit.
Softgrid, Altiris, Thinstall, Citrix proposent différentes variantes de ce principe. La totalité des
programmes et fichiers nécessaires se trouvent sur un espace de stockage quelconque (clé
USB, mais aussi CD, email, unité disque locale ou réseau).
Le logiciel de virtualisation se positionne entre le système et l'application et fournit à cette
dernière la totalité des ressources d'environnement qui lui sont nécessaires pour
fonctionner, sans qu'elle n'accède jamais au système réel (donc sans impacter la stabilité du
poste hôte et sans altérer ses registres systèmes).
Par exemple OpenOffice virtualisé avec ThinStall n'occupe que la moitié d'une clé USB 256
Mo et fonctionne immédiatement sur n'importe quelle machine. L'application, bien qu'un
peu ralentie, reste parfaitement utilisable.
L'installation d'une nouvelle application sur un poste est considérablement raccourcie et
simplifiée. De plus, rien n'est modifié sur la machine et il ne restera aucune trace après le
travail.
Le système permet notamment d'utiliser les applications de l'entreprise à l'extérieur, en
bénéficiant des liaisons performantes locales sans menacer la sécurité de la machine utilisée
ni les données de l'entreprise.
Page 9 sur 97
concernant Docker

DOCKER
2.2.4 Para-virtualisation
La paravirtualisation est une virtualisation dans laquelle le système d’exploitation invité
(celui qui est virtualisé) sait qu’il s’agit d’un invité et possède donc des pilotes qui, au lieu
d’émettre des commandes matérielles, émettent simplement des commandes directement
au système d’exploitation hôte. Cela inclut également la gestion de la mémoire et des
threads, qui nécessitent généralement des instructions privilégiées non disponibles dans le
processeur.
2.2.5 HAL
La HAL pour Hardware Abstraction Layer, ou en français, Couche d'Abstraction Matérielle.
C'est grâce à cette couche que Windows NT est portable sur plusieurs types de machines.
Son rôle est de masquer complètement la partie matérielle au système d'exploitation lui-
même. Tout matériel va être représenté virtuellement au système d'exploitation. Le système
d'exploitation va utiliser le matériel via une interface unique, sans se soucier du matériel.
C'est à la couche d'abstraction matérielle de traduire les demandes au système physique. A
un type de machine correspond une couche HAL spécifique. Grâce à cette couche, Windows
NT peut tourner sur plusieurs types de microprocesseurs : Intel, MIPS, PowerPC, Alpha.
C'est encore la couche HAL qui gère les systèmes multi-processeurs, en intégrant l'interface
SMP (Symmetric Multi Processing). La couche HAL est différente suivant le nombre de
processeurs dans le système.
La couche HAL représente chaque processeur comme un processeur virtuel au noyau. Le
noyau, on le verra plus tard, dispatchera ses tâches sur ces différents processeurs. Que ce
soient des processeurs Alpha, Intel ou autre, le noyau voit toujours des processeurs virtuels.
La couche HAL n'est accessible que par le NT Executive. Pour accéder au matériel, les
programmes utilisateurs sont donc obligés de passer par les Native APIs (enfin presque).

Page 10 sur 97
concernant Docker

DOCKER
2.2.6 Virtualisation assistée par matériel

La virtualisation assistée par le matériel est un type de virtualisation complète dans laquelle
l’architecture du microprocesseur comporte des instructions spéciales pour faciliter la
virtualisation du matériel. Ces instructions peuvent permettre de configurer un contexte
virtuel afin que l'invité puisse exécuter des instructions privilégiées directement sur le
processeur sans affecter l'hôte. Un tel ensemble de fonctionnalités est souvent appelé un
hyperviseur. Si ces instructions n'existent pas, la virtualisation complète est toujours
possible. Toutefois, elle doit être effectuée à l'aide de techniques logicielles telles que la
recompilation dynamique (translation binaire), où l'hôte recompile à la volée des
instructions privilégiées de l'invité pour pouvoir s'exécuter de manière non privilégiée sur le
serveur hôte. Dans le cas de la virtualisation assistée par matériel, la virtualisation est
conçue dans le jeu d'instructions fournit des instructions pour partitionner l'hôte. Voir la
technologie Intel VT-x ou AMD-V à titre d'exemple. Pour que l'hyperviseur fonctionne
directement avec le matériel sans utiliser de système d'exploitation, il fournit une
virtualisation complète.

Page 11 sur 97
concernant Docker

DOCKER
3 Docker
3.1 Introduction
3.1.1 Présentation de Docker
Le développement de Docker a été lancé par Solomon Hykes en tant que projet interne chez
dotCloud, une entreprise en tant que PaaS (plate-forme en tant que service), mais le logiciel
est maintenant géré par la communauté des dockers et Docker Inc.
Docker est un projet open source qui fournit une plate-forme ouverte aux développeurs et
aux administrateurs système pour :
• La création,
• La mise en package
• Et l'exécution d'applications en tant que conteneur léger.
Docker automatise le déploiement d'applications à l'intérieur de conteneurs de logiciels.
3.1.2 Principe de Docker

Docker est une application qui simplifie le processus de gestion des processus d'application
dans les conteneurs. Les conteneurs vous permettent d'exécuter vos applications dans des
processus isolés des ressources. Ils sont similaires aux machines virtuelles, mais les
conteneurs sont plus portables, plus conviviaux et plus dépendants du système
d'exploitation hôte.

Page 12 sur 97
concernant Docker

DOCKER
3.2 Installations et configurations

3.2.1 Prérequis
Docker nécessite une architecture 64 bits pour l'installation et le noyau Linux doit être 3.10
ou plus récent. Je vais utiliser Ubuntu 18.04 LTS (Bionic Beaver) ici avec la version 4.15.0 du
noyau.
3.2.2 Bonnes pratiques

Il est préconisé :
- De prévoir un volume dédié pour le stockage de Docker.
- D’Interdire les communications entre les containers.
Pour de dernier point modifier la variable DOCKER_OPTS dans le fichier /etc/default/docker
comme ceci :
DOCKER_OPTS="--icc=false"
3.2.3 Ubuntu
Dans le cadre de cet ouvrage nous allons réaliser une installation sous Ubuntu.
Voici quelques rappels :
Taper pour connaitre le nom des interface réseau :
lshW -C network
Puis gérer l’adressage avec le « netplan » :
nano /etc/netplan/*.yaml
Voici un exemple de configuration réseau :

network:
version: 2
ethernets:
ens33:
dhcp4: no
# dhcp6: no
addresses: [192.168.8.253/24]
gateway4: 192.168.8.254
nameservers:
addresses: [8.8.8.8,8.8.4.4]
ens34:
dhcp4: no
addresses: [10.10.10.254/26]

Page 13 sur 97
concernant Docker

DOCKER
Appliquez avec :
netplan apply
Passons sur l’activation de l’utilisateur « root » avec « sudo su » puis « passwd root » et sur
l’activation de openssh et concentrons-nous maintenant sur Docker.
3.2.4 Installation sous Linux

Tout d'abord, mettez à jour votre liste de packages existante :
sudo apt update
Ensuite, installez quelques packages prérequis qui permettent d'utiliser des packages via
HTTPS:
sudo apt install apt-transport-https ca-certificates curl software-properties-
common
Ajoutez ensuite la clé GPG du référentiel officiel de Docker à votre système :

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
Ajoutez le référentiel Docker aux sources APT:

sudo add-apt-repository "deb [arch=amd64]
https://download.docker.com/linux/ubuntu bionic stable"
Ensuite, mettez à jour la base de données de packages avec les packages Docker du
référentiel nouvellement ajouté :
sudo apt update
Assurez-vous que vous êtes sur le point d'installer à partir du dépôt Docker au lieu du dépôt
Ubuntu par défaut :
apt-cache policy docker-ce
Vous verrez une sortie comme celle-ci, bien que le numéro de version de Docker puisse être
différent :
docker-ce:
Installed: (none)
Candidate: 18.03.1~ce~3-0~ubuntu
Version table:
18.03.1~ce~3-0~ubuntu 500
500 https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
Enfin, installez Docker :

sudo curl -sSL get.docker.com | sh
Docker devrait maintenant être installé, le démon démarré et le processus activé pour
démarrer au démarrage. Vérifiez qu'il fonctionne :
sudo systemctl status docker

Page 14 sur 97
concernant Docker

DOCKER
La sortie doit être similaire à la suivante, indiquant que le service est actif et en cours d'exécution :
docker.service - Docker Application Container Engine

Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset:
enabled)
Active: active (running) since Thu 2018-07-05 15:08:39 UTC; 2min 55s ago
Docs: https://docs.docker.com
Main PID: 10096 (dockerd)
Tasks: 16
CGroup: /system.slice/docker.service
├─10096 /usr/bin/dockerd -H fd://
└─10113 docker-containerd --config /var/run/docker/containerd/containerd.toml
3.2.5 Docker
La première étape consistera à mettre à jour notre système grâce aux commandes suivante
sudo apt update && apt upgrade
Ensuite nous allons installer docker, rendez-vous à la racine puis :

sudo curl -sSL get.docker.com | sh
Maintenant nous allons faire en sorte de démarrer automatiquement Docker à chaque

nouveau reboot ou démarrage du système
sudo systemctl enable docker
Enfin nous démarrons notre service

sudo systemctl start docker
Et nous vérifions que tout est bien démarré :

sudo systemctl status docker
La sortie doit être similaire à la suivante, indiquant que le service est actif et en cours d'exécution :
docker.service - Docker Application Container Engine

Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset:
enabled)
Active: active (running) since Thu 2018-07-05 15:08:39 UTC; 2min 55s ago
Docs: https://docs.docker.com
Main PID: 10096 (dockerd)
Tasks: 16
CGroup: /system.slice/docker.service
├─10096 /usr/bin/dockerd -H fd://
└─10113 docker-containerd --config /var/run/docker/containerd/containerd.toml

Page 15 sur 97
concernant Docker

DOCKER
Par défaut, la commande docker ne peut être exécutée que par l’utilisateur root ou par un utilisateur
du groupe docker, qui est automatiquement créé lors du processus d'installation de Docker. Si vous
essayez d'exécuter la commande docker sans la préfixer avec « sudo » ou sans être dans le groupe
docker, vous obtiendrez une sortie comme celle-ci :
docker: Cannot connect to the Docker daemon. Is the docker daemon running on
this host?.
See 'docker run --help'.
Si vous souhaitez éviter de taper « sudo » à chaque fois que vous exécutez la commande « docker »,
ajoutez votre nom d'utilisateur au groupe docker :
sudo usermod -aG docker ${USER}
Pour appliquer la nouvelle appartenance au groupe, déconnectez-vous du serveur et reconnectez-

vous ou tapez ce qui suit :
su - ${USER}
Vous serez invité à entrer le mot de passe de votre utilisateur pour continuer.
Confirmez que votre utilisateur est maintenant ajouté au groupe Docker en tapant :
id -nG
Ce qui retourne :
$USER sudo docker
Si vous devez ajouter un utilisateur au groupe docker avec lequel vous n'êtes pas connecté, déclarez-
le explicitement en utilisant :
sudo usermod -aG docker username

Page 16 sur 97
concernant Docker

DOCKER
3.2.6 Docker-hub
Afin de pouvoir pousser vos images dans le Dockerhub vous devez au préalable créer un compte sur
celui-ci. Rendez-vous au https://hub.docker.com/
Plus tard dans cet ouvrage nous utiliserons la commande suivante pour connecter Docker au dépôt :
Docker login -u <login-docker-hub> -p <password-docker-hub>

Page 17 sur 97
concernant Docker

DOCKER
3.3 Utilisation de Docker

Pourvoir la liste des commandes tapez simplement :
$ docker
Pour voir l’aide d’une sous-commande tapez :

$ docker <sous-commande> --help
Voici la liste des sous-commandes francisées et regroupées en 3 catégories :

• Informatives,
• Gestion d’images,
• Gestion de conteneurs
Celle-ci seront détaillées plus loin dans la mise en pratique de cet ouvrage
3.3.1 Les commandes informatives

event Obtenir des événements en temps réel à partir du serveur
info Afficher des informations à l'échelle du système
inspect Retourne les informations de bas niveau sur les objets Docker
logs Récupère les journaux d'un conteneur
stats Afficher un flux en direct de statistiques sur l'utilisation des ressources des conteneurs
port Liste des mappages ou un mappage spécifique pour le conteneur
version Afficher les informations de version de Docker
top Affiche les processus en cours d'exécution d'un conteneur
diff Inspecter les modifications apportées aux fichiers ou aux répertoires sur le système de
fichiers d'un conteneur
login ajoute ses identifiants du DHR (Docker Hub Registry) via ligne de commandes
search Recherche un conteneur sur le Docker Hub

Page 18 sur 97
concernant Docker

DOCKER
3.3.2 Les commandes gestion d’images
Images Liste d'images

history Afficher l'histoire d'une image
pull Tirez une image ou un référentiel d'un registre
commit Créer une nouvelle image à partir des modifications d'un conteneur
build Construire une image à partir d'un fichier Docker
tag Crée une balise TARGET_IMAGE faisant référence à SOURCE_IMAGE
rmi Supprimer une ou plusieurs images
export Exporter le système de fichiers d'un conteneur en tant qu'archive tar
import Importe le contenu d'une archive pour créer une image de système de fichiers
save Sauvegarde une ou plusieurs images dans une archive tar (diffusée par défaut sur
STDOUT)
load Charge une image depuis une archive tar ou STDIN
login Connectez-vous à un registre Docker
logout Déconnexion d'un registre Docker
push Poussez une image ou un référentiel dans un registre
search dans le Docker Hub pour les images
3.3.3 Les commande de gestion des conteneurs

Run
La commande « run » permet d'instancier un nouveau container à partir d'une image.
Exécuter directement une instruction dans un nouveau container :
docker run ubuntu:14.04 echo "hello world"
Affiche :
hello world
Utiliser un port aléatoire pour la redirection :

docker run -P zopnow/lamp-stack
Configurer la redirection de port entre le container et la machine hôte :

docker run -p 8080:80 zopnow/lamp-stack
Note : ici le port 80 correspond au port du container, le port 8080 correspond au port de
la machine hôte.
Certaines applications dans un container tournent en tâche de fond, or le container fini de
s'exécuter quand il n'y a plus d'application au premier plan. Pour résoudre ce problème, il
suffit d'exécuter le container en tant que service (deamon).

Page 19 sur 97
concernant Docker

DOCKER
Pour exécuter un container en tant que service, il faut utiliser l'option -d :

docker run -d ubuntu:14.04 /bin/sh -c "while true; do echo hello world; sleep
1; done"
Ici le contenerr affiche toutes les secondes "hello world" dans la sortie standard du container
Pour installer une application dans un conteneur il faut :
• soit exécuter l'installation directement (rapide mais limité),
• soit exécuter l'installation via un pseudo tty interactif.
Installer une application directement :

Note : -y permet d'éxécuter l'installation en mode « noninteractive ». Quand l'installation est
complexe, il faut utiliser la console interactive avec l’option « -t »
docker run ubuntu:14.04 apt-get install -y ping
Installer une application via un pseudo tty interactif
docker run -t -i ubuntu:14.04 /bin/bash
Puis dans l'invite de commande :

sudo apt-get install ping
Exec
La commande « exec » permet d'exécuter une commande dans un container en cours
d'execution :
docker exec 32a6485f apt-get install ping
Log
Afficher la sortie standard d'un « deamon » en cours d'exécution :

docker logs sharp_lalande
Note : ici "sharp_lalande" est le nom du container deamon, l'option -f permet d'afficher les retours
de la ligne de commande en temps réel (à la manière d'un « tail -f »).

Page 20 sur 97
concernant Docker

DOCKER
Commit
Prenons une image ubuntu de base à laquelle on ajoute le paquet "ping" :
docker run ubuntu:14.04 apt-get install ping
Si on souhaite sauvegarder cette image d'ubuntu avec le paquet "ping", il faut récupérer l'ID
du nouvel container :
docker ps -l
Affiche l'ID "6982a9948422..."

et commit du container :
docker commit 6982a9948422 webdown404/ping
Notes :
• -m permet d'ajouter un message au commit :
docker commit -m "mon premier commit" 6982a9948422 webdown404/ping
• -a permet de rajouter l'auteur d'un commit :
docker commit -a "Quentin BABAULT" 6982a9948422 webdown404/ping
Imaginons que nous souhaitons modifier webdown404/ping en pigant directement

"www.google.com" :
docker run webdown404/ping ping www.google.com
docker ps -l
Affiche l'ID "45af55fffzf..."

Une image est en lecture seule, donc si l'on souhaite apporter des modifications à notre
image, il faut ajouter un tag (ici le tag « google ») :
docker commit 45af55fffzf webdown404/ping:google

Page 21 sur 97
concernant Docker

DOCKER
Autres commandes de gestion des conteneurs

create Créer un nouveau conteneur
rm Supprimer un ou plusieurs conteneurs
rename Renommer un conteneur
start Démarrer un ou plusieurs conteneurs arrêtés
stop Arrête un ou plusieurs conteneurs en cours d'exécution
restart Redémarrer un ou plusieurs conteneurs
exec Exécuter une commande dans un conteneur en cours d'exécution
kill Tuer un ou plusieurs conteneurs en cours d'exécution
pause Pause tous les processus dans un ou plusieurs conteneurs
attach Attachez des flux d'entrée, de sortie et d'erreur locaux standard à un conteneur en cours
d'exécution
cp Copier des fichiers / dossiers entre un conteneur et le système de fichiers local
unpause Mettre en pause tous les processus dans un ou plusieurs conteneurs
update mettre à jour la configuration d'un ou plusieurs conteneurs
wait Attendez jusqu'à ce qu'un ou plusieurs conteneurs s'arrêtent, puis imprimez leurs codes de
sortie
ps Liste des conteneurs

Page 22 sur 97
concernant Docker

DOCKER
3.4 Interface graphique

3.4.1 Shipyard
Shipyard est une interface utilisateur graphique conviviale pour gérer vos conteneurs.
Shipyard utilise RethinkDB pour sa base de données. D’abord on va lancer un conteneur de
RethinkDB :
docker run -ti -d --restart=always --name shipyard-rethinkdb rethinkdb
Voici cette commande en version multiligne :
docker run \
-ti \
-d \
--restart=always \
--name shipyard-rethinkdb \
rethinkdb
Voici le retour attendu :
root@alexdocker01:~# docker run \

> -ti \
> -d \
> --restart=always \
> --name shipyard-rethinkdb \
> rethinkdb
Unable to find image 'rethinkdb:latest' locally
latest: Pulling from library/rethinkdb
e7a7e6031030: Pull complete
0ca7c739ad6e: Pull complete
c3237801dc54: Pull complete
5d6127e7f6f6: Pull complete
68af5fd8cef9: Pull complete
Digest: sha256:7af2b5a808176e9a83c6aae97f5c6e3437cef0d359e62693edda1cff5d364af4
Status: Downloaded newer image for rethinkdb:latest
8f6352bfd2424c374f0cfa13c6671c966d4ff9c969e9836eee88b563de9798b8
Comme vous pouvez le constater Docker n’a pas trouvé l’image en local. Celle-ci a donc été
téléchargée depuis le dépôt de dockerhub de façon automatique.

Page 23 sur 97
concernant Docker

DOCKER
Proxy
Par default, Docker écoute seulement des "sockets". On va utiliser un conteneur proxy. Il
s'agit d'un conteneur qui transmet simplement les requêtes TCP au socket Unix sur lequel
Docker écoute.
#docker run \
-ti \
-d \
-p 2375:2375 \
--hostname=$HOSTNAME \
--restart=always \
--name shipyard-proxy \
-v /var/run/docker.sock:/var/run/docker.sock \
-e PORT=2375 \
shipyard/docker-proxy:latest

> -ti \
> -d \
> -p 2375:2375 \
> --hostname=$HOSTNAME \
> --name shipyard-proxy \
> -v /var/run/docker.sock:/var/run/docker.sock \
> -e PORT=2375 \
> shipyard/docker-proxy:latest
Unable to find image 'shipyard/docker-proxy:latest' locally

latest: Pulling from shipyard/docker-proxy
Image docker.io/shipyard/docker-proxy:latest uses outdated schema1 manifest
format. Please upgrade to a schema2 image for better future compatibility. More
information at https://docs.docker.com/registry/spec/deprecated-schema-v1/
8f4ec95ceaee: Pull complete
ac77a345f217: Pull complete
43039e3ef672: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:da6bbd1a145581a940d44940cce0f43705d7f8ec552a4e97e77104ec1b6dc3d1
Status: Downloaded newer image for shipyard/docker-proxy:latest
42f6d4ac837b73bdf4c4b03cb2addec6112ec62e68ad1d1d00efe025a329e698

Page 24 sur 97
concernant Docker

DOCKER
Contrôleur
Cela lance le contrôleur de Shipyard :
#docker run \
-ti \
-d \
--restart=always \
--name shipyard-controller \
--link shipyard-rethinkdb:rethinkdb \
--link shipyard-swarm-manager:swarm \
-p 8080:8080 \
shipyard/shipyard:latest \
server \
-d tcp://swarm:3375
Voici le retour :
root@docker01:~# docker run \
> -ti \
> -d \
> --name shipyard-controller \
> --link shipyard-rethinkdb:rethinkdb \
> --link shipyard-swarm-manager:swarm \
> -p 8080:8080 \
> shipyard/shipyard:latest \
> server \
> -d tcp://swarm:3375
Unable to find image 'shipyard/shipyard:latest' locally

latest: Pulling from shipyard/shipyard
cb5507795515: Pull complete
fd711d385b34: Pull complete
9f2a509de079: Pull complete
a5251eb716bb: Pull complete
Digest: sha256:5f065362680fa4565dd150c8da3edd09b79a7a3010d3ceef20093c2a879187e0
Status: Downloaded newer image for shipyard/shipyard:latest
529f3504e339f5c1b496f813eba280ba7af26aedf38b44f7b855585a58438353
L’installation est maintenant finie. Vous pouvez vous connectez via :

http:// [IP-of-host]:8080

Page 25 sur 97
concernant Docker

DOCKER
Nous ne détaillerons pas l’utilisation de Shipyard. Les documentations ne manquent pas sur
la toile.
Il faut cependant retenir les éléments suivants :
- Nous avons privilégié une répartition des services par conteneur. Mais nous aurions pu
opter pour une simplicité d’installation en effectuant un « docker pull » de l’image complète
comme ceci :
curl -sSL https://shipyard-project.com/deploy | bash -s
Nous avons installé Shipyard à titre d’exemple mais celui-ci s’appuie sur SWARM qui sera
désactivé lorsque nous installerons Kubernetes.

Page 26 sur 97
concernant Docker

DOCKER
3.4.2 Portainer
Portainer est une interface utilisateur de gestion légère à source ouverte pour les
environnements Docker.
Il fonctionne au-dessus de l'API Docker et fournit une présentation détaillée de Docker, les
fonctionnalités incluent la capacité de gérer des conteneurs, des images, des réseaux et des
volumes.
Pour l’installation de portainer, nous allons grâce à Docker fraîchement installé, télécharger le
conteneur :
sudo docker pull portainer/portainer:linux-arm
Puis nous allons démarrer le conteneur :

sudo docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v
portainer_data:/data portainer/portainer
Vous pouvez maintenant accéder à l’interface Web de portainer via l’adresse suivante
http://IP_hôte:9000
Il ne manque plus qu’à créer votre mot de passe avec le login admin (il devra contenir 8
caractères minimum).

Page 27 sur 97
concernant Docker

DOCKER
3.5 Gestion des conteneurs

3.5.1 Images Docker
Les conteneurs Docker sont construits à partir d'images Docker. Par défaut, Docker extrait ces
images du dépôt « Docker Hub » (voir https://hub.docker.com ). Ce registre Docker est géré
par Docker (la société à l'origine du projet Docker). Tout le monde peut héberger leurs
images Docker sur Docker Hub. Les images des applications et les distributions Linux dont
vous aurez besoin y seront hébergées.
Pour vérifier si vous pouvez accéder aux images et les télécharger depuis Docker Hub, tapez
:
docker run hello-world
La sortie indiquera que Docker fonctionne correctement :

Unable to find image 'hello-world:latest' locally latest: Pulling from
library/hello-world 9bb5a5d4561a: Pull complete Digest:
sha256:3e1764d0f546ceac4565547df2ac4907fe46f007ea229fd7ef2718514bcec35d Status:
Downloaded newer image for hello-world:latest Hello from Docker! This message
shows that your installation appears to be working correctly. ...
Docker était initialement incapable de trouver l'image hello-world localement, il a donc

téléchargé l'image depuis Docker Hub, qui est le référentiel par défaut. Une fois l'image
téléchargée, Docker a créé un conteneur à partir de l'image et l'application dans le
conteneur a été exécutée, affichant le message.
Vous pouvez rechercher des images disponibles sur Docker Hub en utilisant la commande
docker avec la sous-commande « search ». Par exemple, pour rechercher l'image Ubuntu,
tapez :
docker search ubuntu

Page 28 sur 97
concernant Docker

DOCKER
La chaîne de caractères recherchée « ubuntu » est alors trouvé dans plusieurs résultats
ubuntu Ubuntu is a Debian-
based Linux operating sys… 12685 [OK]
dorowu/ubuntu-desktop-lxde-vnc Docker image to
provide HTML5 VNC interface … 560 [OK]
websphere-liberty WebSphere Liberty
multi-architecture images … 280 [OK]
rastasheep/ubuntu-sshd Dockerized SSH
service, built on top of offi… 255 [OK]
consol/ubuntu-xfce-vnc Ubuntu container with
"headless" VNC session… 241 [OK]
ubuntu-upstart DEPRECATED, as is
Upstart (find other proces… 113 [OK]
1and1internet/ubuntu-16-nginx-php-phpmyadmin-mysql-5 ubuntu-16-nginx-php-
phpmyadmin-mysql-5 50 [OK]
ubuntu-debootstrap DEPRECATED; use
"ubuntu" instead 44 [OK]
i386/ubuntu Ubuntu is a Debian-
based Linux operating sys… 25
solita/ubuntu-systemd Ubuntu + systemd
24 [OK]
nuagebec/ubuntu Simple always updated
Ubuntu docker images w… 24
[OK]
fnndsc/ubuntu-python3 A slim Ubuntu-based
Python3 image 24
[OK]
1and1internet/ubuntu-16-apache-php-5.6 ubuntu-16-apache-php-
5.6 14
[OK]
1and1internet/ubuntu-16-apache-php-7.0 ubuntu-16-apache-php-
7.0 13
[OK]
1and1internet/ubuntu-16-nginx-php-phpmyadmin-mariadb-10 ubuntu-16-nginx-php-
phpmyadmin-mariadb-10 11
[OK]
Le « [OK] » (Dans la colonne « OFFICIELLE ») indique une image créée et prise en charge par
l'entreprise à l'origine du projet. Une fois que vous avez identifié l'image que vous souhaitez
utiliser, vous pouvez la télécharger sur votre ordinateur à l'aide de la sous-commande « pull
».
Exécutez la commande suivante pour télécharger l'image ubuntu officielle sur votre
ordinateur :
docker pull ubuntu
Vous verrez la sortie suivante :

Using default tag: latest latest: Pulling from library/ubuntu
6b98dfc16071: Pull complete
4001a1209541: Pull complete
6319fc68c576: Pull complete
b24603670dc3: Pull complete
97f170c87c6f: Pull complete
Digest: sha256:5f4bdc3467537cbbe563e80db2c3ec95d548a9145d64453b06939c4592d67b6d
Status: Downloaded newer image for ubuntu:latest

Page 29 sur 97
concernant Docker

DOCKER
Une fois qu'une image a été téléchargée, vous pouvez exécuter un conteneur à l'aide de
l'image téléchargée avec la sous-commande « run ». Comme vous l'avez vu dans l'exemple
hello-world, si une image n'a pas été téléchargée lorsqu'elle docker est exécutée avec la
sous-commande « run », le client Docker télécharge d'abord l'image, puis exécute un
conteneur qui l'utilise.
Pour voir les images téléchargées sur votre ordinateur, tapez :

docker images
La sortie devrait ressembler à ce qui suit :

REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu latest 1318b700e415 4 weeks ago 72.8MB
hello-world latest d1165f221234 5 months ago 13.3kB
Les images que vous utilisez pour exécuter des conteneurs peuvent être modifiés et utilisés
pour générer de nouvelles images, qui peut ensuite être téléchargé (poussé est le terme
technique) à Docker Hub ou d'autres registres Docker.
Regardons comment exécuter des conteneurs plus en détail.

Page 30 sur 97
concernant Docker

DOCKER
3.5.2 Conteneurs
Le conteneur hello-world que vous avez exécuté à l'étape précédente est un exemple de
conteneur qui s'exécute et se ferme après avoir émis un message de test. Les conteneurs
peuvent être beaucoup plus utiles que cela et ils peuvent être interactifs. Après tout, ils sont
similaires aux machines virtuelles, mais plus faciles à utiliser.
À titre d'exemple, exécutons un conteneur à l'aide de la dernière image d'Ubuntu. La
combinaison des commutateurs -i et -t vous donne un accès interactif au shell dans le
conteneur :
docker run -it ubuntu
Votre invite de commande doit changer pour refléter le fait que vous travaillez maintenant
à l'intérieur du conteneur et que vous devez prendre cette forme : root@d9b100f2f636:/#
Notez l'ID du conteneur dans l'invite de commande. Dans cet exemple, c'est le cas
d9b100f2f636. Vous aurez besoin de cet ID de conteneur ultérieurement pour identifier le
conteneur lorsque vous souhaitez le supprimer.
Vous pouvez maintenant exécuter n'importe quelle commande à l'intérieur du conteneur.
Par exemple, mettons à jour la base de données de packages dans le conteneur. Vous n'avez
pas besoin de préfixer une commande avec sudo, car vous travaillez dans le conteneur en
tant qu'utilisateur root :
apt update
Ensuite, installez n'importe quelle application. Installons Node.js:

apt install nodejs
Cela installe Node.js dans le conteneur à partir du dépôt officiel Ubuntu. Une fois
l'installation terminée, vérifiez que Node.js est installé :
node -v
Vous verrez le numéro de version affiché dans votre terminal :

v8.10.0
Toute modification apportée à l'intérieur du conteneur ne s'applique qu'à ce conteneur.

Pour quitter le conteneur, tapez « exit » à l'invite.
Regardons maintenant la gestion des conteneurs sur notre système.

Page 31 sur 97
concernant Docker

DOCKER
3.5.3 Gérer les conteneurs et images

Après avoir utilisé Docker pendant un certain temps, vous aurez plusieurs conteneurs actifs
(en cours d'exécution) et inactifs sur votre ordinateur. Pour afficher les actifs, utilisez :
docker ps
Vous verrez une sortie similaire à la suivante :

CONTAINER ID IMAGE COMMAND CREATED
Dans ce tutoriel, vous avez démarré deux conteneurs ; un de l'image hello-world et un autre
de l'image ubuntu. Les deux conteneurs ne fonctionnent plus, mais ils existent toujours sur
votre système.
Pour afficher tous les conteneurs - actifs et inactifs, exécutez docker ps le commutateur -a :
docker ps -a
Vous verrez une sortie similaire à ceci :

CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS NAMES
3c4b70eeea3d hello-world "/hello" 11 seconds ago Exited (0) 11 seconds
ago dreamy_napier
6aa4d7c3a208 ubuntu "bash" 18 seconds ago Exited (0) 18 seconds
ago loving_ride
Pour afficher le dernier conteneur que vous avez créé, passez le commutateur -l :
docker ps -l
CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS NAMES
3c4b70eeea3d hello-world "/hello" About a minute ago Exited (0) About a
minute ago dreamy_napier

Page 32 sur 97
concernant Docker

DOCKER
Pour démarrer un conteneur arrêté, utilisez docker start, suivi de l'ID du conteneur ou du
nom du conteneur. Commençons le conteneur basé sur Ubuntu avec l'ID de d9b100f2f636:
docker start d9b100f2f636
Le conteneur démarrera et vous pourrez voir son statut docker ps.

Pour arrêter un conteneur en cours d'exécution, utilisez docker stop, suivi de l'ID ou du nom du
conteneur. Cette fois, nous utiliserons le nom que Docker a attribué au conteneur, à savoir «
sharp_volhard » :
docker stop sharp_volhard
Une fois que vous avez décidé de ne plus avoir besoin d'un conteneur, supprimez-le avec la
commande docker « rm », en utilisant à nouveau l'ID du conteneur ou le nom. Utilisez la commande
docker « ps -a » pour rechercher l'ID ou le nom du conteneur associé à l'image hello-world et
supprimez-le.
docker rm festive_williams
Vous pouvez démarrer un nouveau conteneur et lui donner un nom en utilisant le commutateur « --
name ». Vous pouvez également utiliser le commutateur « --rm » pour créer un conteneur qui se
supprime lorsqu'il est arrêté. Voir la commande docker run --help pour plus d'informations sur ces
options et autres.
Les conteneurs peuvent être transformés en images que vous pouvez utiliser pour créer de nouveaux
conteneurs. Regardons comment cela fonctionne.

Page 33 sur 97
concernant Docker

DOCKER
Validation des modifications

Lorsque vous démarrez une image Docker, vous pouvez créer, modifier et supprimer des fichiers
comme vous pouvez le faire avec une machine virtuelle. Les modifications que vous apportez ne
s'appliqueront qu'à ce conteneur. Vous pouvez le démarrer et l'arrêter, mais une fois que vous l'avez
détruit avec la commande docker rm, les modifications seront définitivement perdues.
Cette section vous montre comment enregistrer l'état d'un conteneur en tant que nouvelle image
Docker.
Après avoir installé Node.js dans le conteneur Ubuntu, vous avez maintenant un conteneur qui
exécute une image, mais le conteneur est différent de l'image que vous avez utilisée pour le créer.
Mais vous pourriez vouloir réutiliser ce conteneur Node.js comme base pour de nouvelles images
ultérieurement.
Puis validez les modifications sur une nouvelle instance d'image Docker à l'aide de la commande
suivante.
docker commit -m "What you did to the image" -a "Author Name" container_id
repository/new_image_name
Le commutateur -m est pour le message de validation qui vous aide, vous et les autres, à savoir
quelles modifications vous avez apportées, tandis que -a est utilisé pour spécifier l'auteur.
Le container_id est celui que vous avez noté précédemment dans le didacticiel lorsque vous avez
démarré la session interactive Docker. À moins que vous ayez créé des référentiels supplémentaires
sur Docker Hub, il s'agit généralement de votre nom d'utilisateur Docker Hub (c’est le même que
votre repository).
Par exemple, pour l'utilisateur afalzon, avec l'ID du conteneur de d9b100f2f636, la commande serait :
docker commit -m "added Node.js" -a "afalzon" d9b100f2f636 afalzon/ubuntu-nodejs
Lorsque vous validez une image, la nouvelle image est enregistrée localement sur votre ordinateur.
Plus loin dans ce didacticiel, vous apprendrez comment transférer une image vers un registre Docker
comme Docker Hub pour que d'autres puissent y accéder.
La liste des images Docker à nouveau affichera la nouvelle image, ainsi que l’ancienne image dérivée
:
docker images
Vous verrez le résultat suivant :

REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu-nodejs latest 7c1f35226ca6 7 seconds ago 179MB
ubuntu latest 1318b700e415 4 weeks ago 72.8MB
hello-world latest d1165f221234 5 months ago 13.3kB
Dans cet exemple, ubuntu-nodejs la nouvelle image est dérivée de l'image ubuntu existante de
Docker Hub. La différence de taille reflète les modifications apportées. Et dans cet exemple, le
changement était que NodeJS était installé. Donc, la prochaine fois que vous devez exécuter un
conteneur en utilisant Ubuntu avec NodeJS pré-installé, vous pouvez simplement utiliser la nouvelle
image.
Vous pouvez également créer des images à partir d'un Docker file fichier, ce qui vous permet
d'automatiser l'installation de logiciels dans une nouvelle image. Cependant, cela n'entre pas dans le
cadre de ce tutoriel.
Partageons maintenant la nouvelle image avec les autres afin qu'ils puissent en créer des conteneurs.
Page 34 sur 97
concernant Docker

DOCKER
3.5.4 Exporter une image dans le Docker hub

La prochaine étape logique après la création d'une nouvelle image à partir d'une image
existante consiste à la partager avec quelques-uns de vos amis, le monde entier sur Docker
Hub ou tout autre registre Docker auquel vous avez accès. Pour transférer une image vers
Docker Hub ou tout autre registre Docker, vous devez y avoir un compte.
Cette section vous montre comment transférer une image Docker vers Docker Hub. Pour
apprendre à créer votre propre registre Docker privé, consultez Comment configurer un
registre Docker privé.
Pour pousser votre image, connectez-vous d'abord à Docker Hub.
docker login -u docker-registry-username
Vous serez invité à vous authentifier à l'aide de votre mot de passe Docker Hub. Si vous avez
spécifié le mot de passe correct, l'authentification doit aboutir. Ensuite, vous pouvez
pousser votre propre image en utilisant :
docker push docker-registry-username/docker-image-name
Pour pousser l'image ubuntu-nodejs dans le référentiel afalzon , la commande serait:

docker push afalzon/ubuntu-nodejs
Le processus peut prendre un certain temps car il télécharge les images, mais une fois
terminé, la sortie ressemblera à ceci :
The push refers to a repository [docker.io/afalzon/ubuntu-nodejs]
e3fbbfb44187: Pushed
5f70bf18a086: Pushed
a3b5c80a4eba: Pushed
7f18b442972b: Pushed
3ce512daaf78: Pushed
7aae4540b42d: Pushed
Après avoir poussé une image dans un registre, elle doit être répertoriée sur le tableau de
bord de votre compte, comme le montre l'image ci-dessous.
Nouvelle liste d'images Docker sur Docker Hub
Si une tentative de poussée entraîne une erreur de ce type, vous ne vous êtes
probablement pas connecté :
The push refers to a repository [docker.io/afalzon/ubuntu-nodejs]
e3fbbfb44187: Preparing
5f70bf18a086: Preparing
a3b5c80a4eba: Preparing
7f18b442972b: Preparing
3ce512daaf78: Preparing
7aae4540b42d: Waiting
Connectez-vous avec le login docker et répétez la tentative de poussée. Ensuite, vérifiez

qu'il existe sur votre page de référentiel Docker Hub.
Vous pouvez maintenant utiliser l'image pour la transférer sur une nouvelle machine et
l'utiliser pour exécuter un nouveau conteneur.
docker pull afalzon/ubuntu-node

Page 35 sur 97
concernant Docker

DOCKER
3.5.5 Communication entre conteneurs

Pour pouvoir faire communiquer deux containers entre eux il existe deux possibilités :
1. Lier les containers via les ports réseaux
2. Lier les containers via une variable d'environnement (l'option --link)
L'option --link est généralement la meilleure solution. Elle s'utilise de la
manière suivante : docker run -d --name db training/postgres docker run -d -P -
-name web --link db:db training/webapp python app.py
Il est également possible d'utiliser l'ID à la place du nom.
3.5.6 Monter un répertoire hôte dans un conteneur

Pour monter un répertoire hôte dans un container, il faut utiliser l'option -v :
docker run -P -v /Users/webdown/www/sandbox/:/www python python /www/app.py
/Users/webdown/www/sandbox correspond au chemin absolu de la machine hôte qui ici

n'est pas le PC mais Boot2Docker. Virtualbox partage par défaut le dossier "/Users" en le
montant dans le dossier "/Users" de Boot2Docker.
:/www correspond à l'emplacement dans lequel sera monté le dossier partagé dans le
container
Il est également possible de limiter l'accès à un dossier en lecture seule en rajoutant :ro :
/Users/webdown/www/sandbox/:/www:ro

Page 36 sur 97
concernant Docker

DOCKER
3.5.7 Conteneur de données

Si on souhaite persister des données utilisables entre les différents containers, la meilleure
solution est d'utiliser un container de données.
Pour créer un container de données
docker create -v /dbdata --name dbdata training/postgres /bin/true
Pour monter le volume /dbdata du container de données dans plusieurs autres containers :
docker run -d --volumes-from dbdata --name db1 training/postgres docker run -d
--volumes-from dbdata --name db2 training/postgres
Si on souhaite supprimer un container de données, il faut utiliser l'option -v sinon on risque

de se retrouver avec des volumes fantômes (Dangling volumes)
Un avantage d'utiliser un container de données est pouvoir faire facilement des
backup/restaurations de données.
Pour réaliser une sauvegarde :
docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf
/backup/backup.tar /dbdata
Pour créer un nouveau container de données et y restaurer les données du container de

données précédent :
docker run -v /dbdata --name dbdata2 ubuntu /bin/bash docker run --volumes-from
dbdata2 -v /backup busybox tar xvf /backup/backup.tar

Page 37 sur 97
concernant Docker

DOCKER
3.5.8 Swarm
SWARM est l’orquestrateur natif de Docker. Bien que le monde entier se dirige vers
l’utilisation massive de Kubernetes (l’orquestrateur développé par Google). Nous allons
découvrir l’utilisation de SWARM au passage.
Par default, Docker écoute seulement des "sockets". On va utiliser un conteneur proxy. Il s'agit d'un
conteneur qui transmet simplement les requêtes TCP au socket Unix sur lequel Docker écoute.
Pour l’activation de SWARM, nous devons utiliser une clé externe du conteneur SWARM. Pour cet
exemple, nous utiliserons etcd :
docker run \
-ti \
-d \
-p 4001:4001 \
-p 7001:7001 \
--restart=always \
--name shipyard-discovery \
microbox/etcd -name discovery

root@docker01:~# docker run \
> -ti \
> -d \
> -p 4001:4001 \
> -p 7001:7001 \
> --name shipyard-discovery \
> microbox/etcd -name discovery
Unable to find image 'microbox/etcd:latest' locally
latest: Pulling from microbox/etcd
Image docker.io/microbox/etcd:latest uses outdated schema1 manifest format.
Please upgrade to a schema2 image for better future compatibility. More
information at https://docs.docker.com/registry/spec/deprecated-schema-v1/
8ded6e8ab3fd: Pull complete
bf8f85223d7a: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:941fd46b4eab265c65da9bfbf33397b853a7cef6c16df93a1e3fea7b4e47fc90
Status: Downloaded newer image for microbox/etcd:latest
daba8a5ff39cc76a8282cf7d564a460bfb5de7231f7932ec284d0a800fc593e0

Page 38 sur 97
concernant Docker

DOCKER
Swarm manager
Voici maintenant la création d’un conteneur SWARM préconfiguré :
#docker run \
-ti \
-d \
--restart=always \
--name shipyard-swarm-manager \
swarm:latest \
manage --host tcp://0.0.0.0:3375 etcd://<IP-OF-HOST>:4001
Il faut mettre l’IP de votre machine en lieu et place de <IP-OF-HOST>.

Voici le retour :
> -ti \
> -d \
> --name shipyard-swarm-manager \
> swarm:latest \
> manage --host tcp://0.0.0.0:3375 etcd://192.168.8.100:4001
Unable to find image 'swarm:latest' locally
latest: Pulling from library/swarm
d85c18077b82: Pull complete
1e6bb16f8cb1: Pull complete
85bac13497d7: Pull complete
Digest: sha256:b866583a3b8791bcd705b7bc0fd94c66b695a1a2dbaeb5f59ed29940e5015dc8
Status: Downloaded newer image for swarm:latest
71d19d4b96c8d65e704429a8953abc546792092510022e3407da4fead63fe4fe

Page 39 sur 97
concernant Docker

DOCKER
Swarm Agent
Ce conteneur exécute un agent SWARM qui permet au noeud de planifier les conteneurs.
#docker run \
-ti \
-d \
--restart=always \
--name shipyard-swarm-agent \
swarm:latest \
join --addr <ip-of-host>:2375 etcd://<ip-of-host>:4001
Il faut mettre l’IP de votre machine en lieu et place de <ip-of-host>.

Voici le retour :
> -ti \
> -d \
> --name shipyard-swarm-agent \
> swarm:latest \
> join --addr 192.168.8.100:2375 etcd://192.168.8.100:4001
2ed1cf334ba3d7f76a30e8d51db491c3d70c67d4c0da4b3b5da29b3802e661af

Page 40 sur 97
concernant Docker

DOCKER
3.5.9 Kubernetes
3.6 Installation et configuration de Kubernetes
3.6.1 Introduction
Kubernetes est une plateforme open source développée par Google pour la gestion des
applications conteneurisées. Il vous permet de gérer, de mettre à l'échelle et de déployer
automatiquement vos applications conteneurisées dans l'environnement en cluster.
Avec Kubernetes, vous pouvez :

• Orchestrer des conteneurs sur plusieurs hôtes,
• Mettre à l'échelle les applications conteneurisées avec toutes les ressources à la volée
• Et disposer d'un environnement de gestion de conteneur centralisé.
A titre d’exemple voici comment installer et configurer Kubernetes sur Ubuntu 18.04. Nous
utiliserons 3 serveurs Ubuntu 18.04LTS avec les privilèges « root »:
• « alexdockerk8smaster » avec l’IP 192.168.8.102 (Maître Kubernetes)
• « alexdocker01 » avec l’IP 192.168.8.100 (noeuds de travail Kubernetes)
• « alexdocker02 » avec l’IP 192.168.8.101 (noeuds de travail Kubernetes)
ATTENTION
Si vous souhaitez dupliquer une VM pour éviter des installations multiples de Ubuntu 18.04 server il
vous faudra changer les noms d’hôte des serveurs pour que les « Workers » puis être visible dans le «
master »
Pour cela éditer le fichier « /etc/cloud/cloud.cfg
root@dockerk8smaster:~#nano /etc/cloud/cloud.cfg
Puis modifier la ligne « preserve_hostname: false » en la remplaceant par « preserve_hostname: true
# This will cause the set+update hostname module to not operate (if true)
preserve_hostname: true
Renommer le nom d’hôte puis redémarrer le serveur :

root@dockerk8smaster:~# echo alexdockerk8smaster > /etc/hostname
root@dockerk8smaster:~# reboot
Voici les étapes à réaliser :

• Installation de Kubeadm
• Configuration des hôtes
• Installation de Docker
• Désactivation de la SWAP
• Installation des paquets Kubeadm
• Initialisation du cluster Kubernetes
Page 41 sur 97
concernant Docker

DOCKER
• Ajout de noeuds de travail au cluster Kubernetes

• Réalisation de tests
3.6.2 Préparation des hôtes
Dans cette première étape, nous allons préparer ces 3 serveurs pour l'installation de Kubernetes.
Exécutez donc toutes les commandes sur les noeuds maître et de travail.
Nous allons préparer tous les serveurs pour l'installation de Kubernetes en modifiant la configuration
existante sur les serveurs et en installant également certains packages, y compris docker et
kubernetes.
Editez le fichier hosts sur tous les serveurs à l'aide de l'éditeur nano ou vim :
sudo vim /etc/hosts
Collez la configuration des hôtes ci-dessous :

192.168.8.102 dockerk8smaster
192.168.8.100 docker01
192.168.8.101 docker02
Sauvegarder et quitter.
Maintenant testez le ping sur tous les serveurs nom d’hôte :

ping -c 3 alexdockerk8smaster
ping -c 3 alexdocker01
ping -c 3 alexdocker02
Assurez-vous que toutes les adresses IP sont résolues en tant que nom d’hôte.
root@dockerk8smaster:~# ping -c 3 dockerk8smaster
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.067
ms
ms
ms
--- localhost.localdomain ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2031ms
rtt min/avg/max/mdev = 0.038/0.050/0.067/0.012 ms
root@ dockerk8smaster:~# ping -c 3 docker01
PING docker01 (192.168.8.100) 56(84) bytes of data.
64 bytes from docker01 (192.168.8.100): icmp_seq=1 ttl=64 time=0.514 ms
--- alexdocker01 ping statistics ---
root@ dockerk8smaster:~# ping -c 3 docker02
PING docker02 (192.168.8.101) 56(84) bytes of data.
64 bytes from alexdocker02 (192.168.8.101): icmp_seq=1 ttl=64 time=1.92 ms
--- docker02 ping statistics ---

Page 42 sur 97
concernant Docker

DOCKER
Désactiver la Swap
Afin de configurer les serveurs Linux Kubernetes, nous devons désactiver le SWAP.
Vérifiez la liste de swap et désactivez-la.
sudo swapon -s
sudo swapoff -a
Pour désactiver le SWAP de manière permanente, nous devons éditer le fichier '/etc/fstab'.
sudo vim /etc/fstab
Faites un commentaire sur le type de partition SWAP.

#/dev/mapper/hakase--labs--vg-swap_1 none swap sw 0 0
Enregistrez et quittez, puis redémarrez le système.

sudo reboot
3.6.3 Installation des Kubeadm

Dans ce tutoriel, nous allons utiliser les packages Kubeadm pour configurer le cluster
Kubernetes. Nous installerons ceux-ci à partir du référentiel officiel Kubernetes.
Installez « apt-transport-https ».
sudo apt install -y apt-transport-https
Ajoutez la clé APT de Kubernetes

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key
add -
Et ajoutez le référentiel Kubernetes en créant un nouveau fichier kubernetes.list dans le

répertoire « /etc/apt/sources.list.d ».
cd /etc/apt/ sudo vim sources.list.d/kubernetes.list
Coller le référentiel Kubernetes ci-dessous.

deb http://apt.kubernetes.io/ kubernetes-xenial main
Maintenant, mettez à jour le référentiel et installez les paquets kubeadm en utilisant les
commandes « apt » ci-dessous.
sudo apt update sudo apt install -y kubeadm kubelet kubectl
Attendez l'installation des packages kubeadm.

root@dockerk8smaster:~# sudo apt install -y kubeadm kubelet kubectl
Reading package lists... Done
Building dependency tree Reading state information... Done
kubeadm is already the newest version (1.16.3-00).
kubectl is already the newest version (1.16.3-00).
kubelet is already the newest version (1.16.3-00).
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

Page 43 sur 97
concernant Docker

DOCKER
3.6.4 Initialisation du cluster

Dans cette étape, nous allons initialiser Kubernetes sur le noeud 'dockerk8smaster'.
ATTENTION
Exécutez toutes les commandes de cette étape uniquement sur le serveur 'alexdockerk8smaster'.
Initialisez le cluster Kubernetes à l'aide de la commande kubeadm ci-dessous.
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-
address=192.168.8.102 --kubernetes-version "1.16.0"
« --apiserver-advertise-address = » détermine l'adresse IP sur laquelle Kubernetes doit annoncer
son serveur d'API.
« --pod-network-cidr = » spécifie la plage d'adresses IP du réseau de pod. Nous utilisons le réseau
virtuel 'flannel'. Si vous souhaitez utiliser un autre réseau de pods tel que weave-net ou Calico,
modifiez l'adresse IP de la plage.
RAPPEL
En cas de problème vous avez la possibilité de recommencer cette étape en réalisant au préalable un
Kubeadm reset
Puis effacer le repertoire $HOME/.kube

mkdir -p $HOME/.kube

Page 44 sur 97
concernant Docker

DOCKER
Une fois l’initialisation de Kubernetes terminée, vous obtiendrez le résultat indiqué ci-dessous.
root@alexdocker01:~# sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --
apiser ver-advertise-address=192.168.8.102 --kubernetes-version "1.16.0"
[init] Using Kubernetes version: v1.16.0
[preflight] Running pre-flight checks
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup
driver. The recommended driver is "systemd". Please follow the guide at https:/
/kubernetes.io/docs/setup/cri/
[WARNING SystemVerification]: this Docker version is not on the list of
validated versions: 19.03.5. Latest validated version: 18.09
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your
inte rnet connection
[preflight] You can also perform this action in beforehand using 'kubeadm
config images pull'
[kubelet-start] Writing kubelet environment file with flags to file
"/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file
"/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [alexdocker01 kubernetes
kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
and IPs [10.96.0.1 192.168.8.102]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [alexdocker01
localhost] and IPs [192.168.8.102 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [alexdocker01 localhost]
and IPs [192.168.8.102 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in
"/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as
static Pods from directory "/etc/kubernetes/manifests". This can take up to
4m0s
[apiclient] All control plane components are healthy after 38.010235 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in
the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.16" in namespace kube-system
with the configuration for the kubelets in the cluster
Page 45 sur 97
concernant Docker

DOCKER
[upload-certs] Skipping phase. Please see --upload-certs

[mark-control-plane] Marking the node alexdocker01 as control-plane by adding
the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node alexdocker01 as control-plane by adding
the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: p3jsv8.9svqnv6rqrgxjqww
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC
Roles
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post
CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller
automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all
node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public"
namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
Then you can join any number of worker nodes by running the following on each
as root:
kubeadm join 192.168.8.102:6443 --token 9y7x5f.nrdvl5eilwsgyg9g \
--discovery-token-ca-cert-hash
sha256:8f3ce1b01c6c394d7297be499da9a52355cc350a3269e90326a7cbc124f3db80
ATTENTION : le Token ne sera plus retrouvable

Copiez donc la commande « kubeadm join » complète (avec le token) dans votre éditeur de texte.
La commande sera utilisée pour enregistrer de nouveaux noeuds de travail dans le cluster
Kubernetes.
Maintenant, pour utiliser Kubernetes, nous devons exécuter certaines commandes, comme indiqué
dans le résultat.

Page 46 sur 97
concernant Docker

DOCKER
Créez un nouveau répertoire de configuration ".kube" et copiez le répertoire de configuration

"admin.conf" à partir du répertoire "/etc/kubernetes".
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Ensuite, déployez le réseau de flanelles sur le cluster Kubernetes à l’aide de la commande « kubectl
».
kubectl apply -f
https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-
flannel.yml
root@alexdockerk8smaster:~# kubectl apply -f

https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-
flannel.yml
podsecuritypolicy.policy/psp.flannel.unprivileged created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds-amd64 created
daemonset.apps/kube-flannel-ds-arm64 created
daemonset.apps/kube-flannel-ds-arm created
daemonset.apps/kube-flannel-ds-ppc64le created
daemonset.apps/kube-flannel-ds-s390x created
Le réseau de flanelle a été déployé sur le cluster Kubernetes.
ATTENTION
Attendez une minute, avant de passer à la suite.
Vérifiez le noeud Kubernetes et les pods à l’aide des commandes ci-dessous.
kubectl get nodes
kubectl get pods --all-namespaces
Le noeud 'dockerk8smaster' s'exécute en tant que cluster 'maître' avec le statut 'prêt'
root@dockerk8smaster:~# kubectl get nodes
Tous les pods 'kube-system' nécessaires au cluster sont opérationnels.

root@dockerk8smaster:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
docker01 Ready master 72m v1.16.3
Tous les pods 'kube-system' nécessaires au cluster sont opérationnels.

root@dockerk8smaster:~# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-5644d7b6d9-cwf7j 1/1 Running 0 72m
kube-system coredns-5644d7b6d9-dptjc 1/1 Running 0 72m
kube-system etcd-alexdocker01 1/1 Running 0 72m
kube-system kube-apiserver-alexdocker01 1/1 Running 0 71m
kube-system kube-controller-manager-alexdocker01 1/1 Running 0 71m
kube-system kube-flannel-ds-amd64-qlbrv 1/1 Running 0 12m
kube-system kube-proxy-pzblk 1/1 Running 0 72m
kube-system kube-scheduler-alexdocker01 1/1 Running 0 72mTous les pods 'kube-system'
nécessaires au cluster sont opérationnels.
L'initialisation et la configuration du maître de cluster Kubernetes sont terminées

Page 47 sur 97
concernant Docker

DOCKER
Ajout des nœuds de travail au cluster
Dans cette étape, nous allons ajouter les deux travailleurs (ou slave ou worker) «
docker01 » et « docker02 » au noeud Kubernetes.
Connectez-vous au serveur 'docker01' et exécutez la commande kubeadm join obtenue
lors de l’initialisation du cluster.
kubeadm join 192.168.8.102:6443 --token 9y7x5f.nrdvl5eilwsgyg9g \

--discovery-token-ca-cert-hash
sha256:8f3ce1b01c6c394d7297be499da9a52355cc350a3269e90326a7cbc124f3db80
root@docker01:~# kubeadm join 192.168.8.102:6443 --token

9y7x5f.nrdvl5eilwsgyg9g \
> --discovery-token-ca-cert-hash sha256:
8f3ce1b01c6c394d7297be499da9a52355cc350a3269e90326a7cbc124f3db80
[preflight] Running pre-flight checks
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup
driver. The recommended driver is "systemd". Please follow the guide at
https://kubernetes.io/docs/setup/cri/
[WARNING SystemVerification]: this Docker version is not on the list of
validated versions: 19.03.5. Latest validated version: 18.09
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system
get cm kubeadm-config -oyaml'
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-
config-1.16" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file
"/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file
"/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Activating the kubelet service
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was
received.
* The Kubelet was informed of the new secure connection details.
Run 'kubectl get nodes' on the control-plane to see this node join the cluster.
Exécutez la même commande « kubeadm join » sur 'docker02' .

Page 48 sur 97
concernant Docker

DOCKER
ATTENTION
Attendez quelques minutes avant de retourner sur le maitre.
Revenez sur le maître de noeud « alexdockerk8smaster » et vérifiez l'état du noeud.

kubectl get nodes
Vous verrez que les noeuds de travail 'alexdocker01' et 'alexdocker02' font partie du cluster
Kubernetes :
root@alexdockerk8smaster:~# kubectl get node
NAME STATUS ROLES AGE VERSION
alexdocker01 Ready <none> 91s v1.16.3
alexdocker02 Ready <none> 80s v1.16.3
alexdockerk8smaster Ready master 5m44s v1.16.3
RAPPEL
Les noms d’hôte des serveurs doivent être uniques pour que les nodes apparaissent dans le master.
Si ce n’est pas le cas reportez-vous à l’avertissement de la page 50.
Dans ce cas il faut réinitialiser le master comme suit :
root@alexdockerk8smaster:~# kubeadm reset
...
The reset process does not reset or clean up iptables rules or IPVS tables.
If you wish to reset iptables, you must do so manually by using the "iptables"
command.
If your cluster was setup to utilize IPVS, run ipvsadm --clear (or similar)
to reset your system's IPVS tables.
The reset process does not clean your kubeconfig files and you must remove them
manually.
Please, check the contents of the $HOME/.kube/config file.
Et recommencer à partir de l’étape Initialisation du cluster Kubernetes.
Réalisation des tests

Dans cette étape, nous allons déployer le serveur Web Nginx dans le cluster. Nous
déploierons le serveur Web Nginx à l'aide du modèle YAML.
Effectuez les commandes suivantes uniquement sur le master.
Créez un nouveau répertoire nommé "nginx" et accédez à ce répertoire.
mkdir -p nginx/
cd nginx/
Créez maintenant le fichier Nginx Deployment YAML 'nginx-deployment.yaml' à l'aide de

l' éditeur vim
sudo vim nginx-deployment.yaml

Page 49 sur 97
concernant Docker

DOCKER
Coller les configurations ci-dessous.

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.0
ports:
- containerPort: 80
Créez maintenant le déploiement nommé "nginx-deployment" en exécutant la commande kubectl ci-
dessous.
kubectl create -f nginx-deployment.yaml
root@alexdockerk8smaster:~/nginx# kubectl create -f nginx-deployment.yaml
deployment.apps/nginx-deployment created

Page 50 sur 97
concernant Docker

DOCKER
Après avoir créé un nouveau "nginx-deployment", Vérifiez la liste des déploiements dans le cluster.
kubectl get deployments
kubectl describe deployment nginx-deployment
Voici le résultat :
root@alexdockerk8smaster:~/nginx# kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 118s
root@alexdockerk8smaster:~/nginx# kubectl describe deployment nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Fri, 22 Nov 2019 13:20:48 +0000
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.14.0
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-7f555c9b4b (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Le libellé de l'application est "nginx" et a 3 répliques.

Le "nginx-deployment" aura des conteneurs nommés "nginx", basés sur l'image du menu fixe "nginx:
1.14.0", et exposera le port HTTP 80 par défaut.
Maintenant, vérifiez les pods Kubernetes et vous verrez le pod 'nginx-deployment-xxx' :
kubectl get pods
Ce qui nous donne :
root@dockerk8smaster:~/nginx# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-7f555c9b4b-8lvw6 1/1 Running 0 6m54s
nginx-deployment-7f555c9b4b-8x8xl 1/1 Running 0 6m54s
nginx-deployment-7f555c9b4b-g9vrg 1/1 Running 0 6m54s
Vérifiez les détails du pod :
kubectl describe pods nginx-deployment-7f555c9b4b-8lvw6

Page 51 sur 97
concernant Docker

DOCKER
Vous obtiendrez des « pods » de déploiement nginx avec 3 réplicas sur les noeuds de travail :
root@dockerk8smaster:~/nginx# kubectl describe pods nginx-deployment-
7f555c9b4b-8lvw6
Name: nginx-deployment-7f555c9b4b-8lvw6
Namespace: default
Priority: 0
Node: alexdocker01/192.168.8.100
Start Time: Fri, 22 Nov 2019 13:20:48 +0000
Labels: app=nginx
pod-template-hash=7f555c9b4b
Annotations: <none>
Status: Running
IP: 10.244.1.64
IPs:
IP: 10.244.1.64
Controlled By: ReplicaSet/nginx-deployment-7f555c9b4b
Containers:
nginx:
Container ID:
docker://42d09e0b09bf860b98c357be2cc2dc8e187347b0d4f16e3146df857ef7339063
Image: nginx:1.14.0
Image ID: docker-
pullable://nginx@sha256:8b600a4d029481cc5b459f1380b30ff6cb98e27544fc02370de836e
397e34030
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Fri, 22 Nov 2019 13:21:07 +0000
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-2f46k (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-2f46k:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-2f46k
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
Normal Scheduled <unknown> default-scheduler Successfully assigned
default/nginx-deployment-7f555c9b4b-8lvw6 to alexdocker01
Normal Pulling 8m1s kubelet, alexdocker01 Pulling image "nginx:1.14.0"
Normal Pulled 7m45s kubelet, alexdocker01 Successfully pulled image
"nginx:1.14.0"
Normal Created 7m44s kubelet, alexdocker01 Created container nginx
Normal Started 7m44s kubelet, alexdocker01 Started container nginx

Page 52 sur 97
concernant Docker

DOCKER
Ensuite, nous devons créer un nouveau service pour notre déploiement de Nginx.
Créez un nouveau fichier YAML nommé 'nginx-service.yaml'.
vim nginx-service.yaml
Collez la configuration ci-dessous.

apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
run: nginx-service
spec:
type: NodePort
ports:
- port: 80
protocol: TCP
selector:
app: nginx
EXPLICATIONS :
Nous créons un nouveau service kubernetes nommé 'nginx-service'.
Le type de service est 'NodePort' avec le port 80 par défaut de TargetPort HTTP.
Le service appartient à l'application nommée 'nginx' en fonction de notre déploiement 'nginx-
deployment'.
Créez le service kubernetes à l'aide de la commande kubectl ci-dessous.
kubectl create -f nginx-service.yaml
Cela donne :
root@alexdockerk8smaster:~/nginx# kubectl create -f nginx-service.yaml
service/nginx-service created
Maintenant, vérifiez tous les services disponibles sur le cluster et vous obtiendrez le
service Nginx dans la liste, puis vérifiez les détails du service.
kubectl get service

Page 53 sur 97
concernant Docker

DOCKER
Cela donne :
root@dockerk8smaster:~/nginx# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 143m
nginx-service NodePort 10.104.7.130 <none> 80:30291/TCP 97s
Puis pour plus d’informations :
kubectl describe service nginx-service
Ce qui nous donne :
root@alexdockerk8smaster:~/nginx# kubectl describe service nginx-service
Name: nginx-service
Namespace: default
Labels: run=nginx-service
Annotations: <none>
Selector: app=nginx
Type: NodePort
IP: 10.104.7.130
Port: <unset> 80/TCP
TargetPort: 80/TCP
NodePort: <unset> 30291/TCP
Endpoints: 10.244.1.64:80,10.244.1.65:80,10.244.2.3:80
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>
Et vous verrez que le 'service nginx' NodePort est exécuté sur le port
'30291'.
Vérifiez en utilisant la commande curl sur tous les « workers ».
Sur le alexdocker01 et alexdocker02 :
Curl docker01:30291
Vous verrez la page par défaut de Nginx.

root@docker01:~# curl alexdocker01:30291
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
L'installation et la configuration de Kubernetes Cluster sur Ubuntu ont été effectuées avec succès.

Page 54 sur 97
concernant Docker

DOCKER
4 Outils Docker
L'écosystème des conteneurs grandit et se développe plus rapidement que jamais, et avec
autant d'outils et de services Docker, cela peut sembler une tâche ardue de simplement
comprendre les options disponibles. Que vous soyez débutant ou expert, développeur ou
ingénieur DevOps, SRE ou architecte de plate-forme, cette liste vous aidera à comprendre les
offres les plus populaires pour améliorer toutes les étapes de votre pipeline de développement
avec Docker.
Voici les catégories proposées :
- Orchestration et ordonnanceurs
- Intégration continue / Déploiement continu (CI / CD)
- Surveillance
- Enregistrement
- Sécurité
- Gestion du stockage / volume
- La mise en réseau
- Découverte de service
- Construit
- La gestion
4.1 Orchestration et ordonnanceur

4.1.1 Kubernetes
Kubernetes est le moteur d'orchestration de conteneurs le plus populaire disponible sur le
marché. Initialement lancé sous la forme d'un projet Google, des milliers d'équipes
l'utilisent pour déployer des conteneurs en production. Google affirme qu'il gère des
milliards de conteneurs utilisant Kubernetes chaque semaine. L'outil fonctionne en
regroupant les conteneurs qui composent une application dans des unités logiques pour
faciliter la gestion et la découverte.
Lien: https://kubernetes.io
Coût: gratuit

Page 55 sur 97
concernant Docker

DOCKER
4.1.2 Swarm
Swarm est la réponse de Docker au problème d'un développeur concernant la manière
d'orchestrer et de planifier des conteneurs sur plusieurs serveurs. Swarm est inclus dans
Docker Engine depuis la version 1.12.0 et offre des fonctionnalités avancées telles que la
découverte de services intégrés, l’équilibrage de charge, la mise à l’échelle et la sécurité.
Swarm continue dans la tradition de Docker de mettre l'accent sur la simplicité et
l'expérience de développeur. Il est sans doute plus facile à utiliser que Kubernetes hors de la
boîte.
Lien: https://www.docker.com
Coût: Free Community Edition
4.1.3 Mesosphere DC/OS

Le système d’exploitation de données (DC / OS) de Mesosphere est une plate-forme open
source intégrée pour les données et les conteneurs, construite sur le noyau des systèmes
distribués Apache Mesos. Il est conçu pour traiter plusieurs machines d'un centre de
données comme une ou plusieurs grappes, soit dans le cloud, soit à l'aide d'un logiciel sur
site. DC / OS peut déployer des conteneurs et gérer à la fois des applications sans état et
des charges de travail avec état dans le même environnement.
Fonctionne avec Docker Swarm et Kubernetes.
Lien: https://dcos.io/
Coût: les packages d'abonnement DC / OS de Mesosphere sont basés sur le nombre de
noeuds (physiques ou virtuels) de votre environnement.

Page 56 sur 97
concernant Docker

DOCKER
4.1.4 Amazon ECS

La réponse d'Amazon Web Services à l'orchestration du conteneur, Amazon ECS est un
service de gestion hautement évolutif qui permet aux développeurs d'exécuter des
applications conteneurisées sur des instances EC2. Il est composé de plusieurs composants
intégrés pour permettre la planification et le déploiement simples de clusters, tâches et
services Docker.
Bien qu'il n'y ait aucune prise en charge pour l'exécution de conteneurs en dehors de EC2,
les avantages incluent les avantages du service AWS tels que CloudTrail, CloudWatch, Elastic
Load Balancers, etc.
Coût: Amazon ECS n'entraîne aucun coût supplémentaire. Ne payez que pour les ressources
AWS (par exemple, instances EC2 ou volumes EBS) nécessaires au stockage et à l'exécution de
votre application
4.1.5 Service de conteneur Azure (AKS)

Récemment renommé ACS en AKS, le service Azure est un service de gestion à source
ouverte optimisé pour une utilisation sur les machines virtuelles Azure. Il fournit les outils
nécessaires pour créer, configurer et gérer une infrastructure de conteneur Docker ouverte.
AKS propose un développement et un déploiement simplifiés d'applications basées sur des
conteneurs, avec prise en charge de Kubernetes, Mesospere DC / OS ou Swarm pour
l'orchestration.
Mettez à l'échelle et orchestrez à l'aide des outils de gestion des applications de votre choix
et connectez-vous via des points de terminaison d'API standard.
Lien: https://azure.microsoft.com/en-us/services/container-service/
Coût: ne payez que pour les machines virtuelles et les ressources de stockage et de réseau
associées utilisées.

Page 57 sur 97
concernant Docker

DOCKER
4.1.6 Google Contanier Engine (GKE)

Propulsé par Kubernetes, GKE peut déployer, gérer et mettre à l'échelle des applications
conteneurisées sur Google Cloud. L'objectif de GKE est d'optimiser la productivité de
l'équipe informatique en améliorant la gestion des charges de travail basées sur des
conteneurs. Il cache des tâches de gestion complexes et simples, associées à une expérience
utilisateur conviviale et à des outils de ligne de commande simples.
Kubernetes est la colonne vertébrale de GKE. Bien que vous n'ayez pas besoin de
l'apprendre pour utiliser GKE, cela vous aidera si vous comprenez les bases.
Lien: https://cloud.google.com/container-engine/
Coût: Gratuit pour 0 à 5 noeuds, 6 noeuds et plus = 0,15 $ / heure (109,50 $ / mois) par
membre
4.1.7 Cloud Foundry’s Diego

Cloud Foundry utilise son architecture Diego pour gérer les conteneurs d'applications dans
l'environnement «de jardin». Garden suit les directives de la Open Container Initiative de
Linux concernant l'hébergement de conteneurs et est extrait des autres composants de
Diego. Les éléments Diego offrent des fonctionnalités de planification et de gestion des
applications via le contrôleur de cloud.
Lien: https://docs.cloudfoundry.org/concepts/diego
Coût: gratuit

Page 58 sur 97
concernant Docker

DOCKER
4.1.8 Marathon
Marathon est une plate-forme privée en tant que service (PaaS) de niveau production basée
sur Apache Mesos. La structure Marathon promet d’échelonner les applications dockerisées
et de s’étendre à davantage de noeuds si nécessaire pour augmenter le pool de ressources
disponible. Il peut également servir d'outil d'orchestration de conteneur pour permettre la
récupération après incident des charges de travail conteneurisées. Marathon gère
automatiquement les pannes matérielles ou logicielles et veille à ce qu'une application soit
"toujours active".
Lien: https://mesosphere.github.io/marathon/
Coût: gratuit
4.1.9 HashiCorp Nomad

Pris en charge par Linux, Mac et Windows, Nomad est un outil binaire unique capable de
planifier toutes les applications virtualisées, conteneurisées et autonomes. Nomade vous
permet de gérer 1million de conteneurs sur 5 000 hôtes en quelques minutes, d’un
conteneur à un essaim de milliers. Nomad contribue à améliorer la densité, tout en
réduisant les coûts, en allouant efficacement davantage d'applications sur moins de
serveurs.
Lien: https://www.nomadproject.io/
Coût: gratuit

Page 59 sur 97
concernant Docker

DOCKER
4.1.10 Hélios
Helios a d’abord été l’outil interne de Spotify pour garantir le fonctionnement efficace de
centaines de microservices sur plusieurs milliers de serveurs. Il est capable de déployer et
de gérer des conteneurs à grande échelle et est équipé d'une API basée sur HTTP ainsi que
d'un client en ligne de commande.
Helios n'a pas besoin d'une topologie de réseau spécifique; il nécessite simplement un
cluster ZooKeeper et une machine virtuelle Java sur les machines sur lesquelles l'outil sera
exécuté. Il est disponible en tant que projet open-source.
Lien: https://github.com/spotify/helios
Coût: gratuit
4.1.11 Rancher
Pas seulement un orchestrateur de conteneur, mais une plate-forme complète de gestion
de conteneur pour l'exploitation de Docker en production. RancherOS est un système
d'exploitation basé sur conteneur capable de gérer de nombreux services d'infrastructure,
tels que l'équilibrage de la charge globale et locale, la mise en réseau multi-hôtes et les
instantanés de volume. Rancher intègre des fonctionnalités de gestion Docker natives telles
que Docker Machine et Swarm.
Lien: http://rancher.com/
Coût: gratuit
4.1.12 Nebula
Nebula est un nouveau projet open source créé pour l'orchestration Docker et conçu pour
gérer des grappes massives à grande échelle. L'outil y parvient en dimensionnant chaque
composant du projet autant que nécessaire. L'objectif du projet est d'agir en tant
qu'orchestrateur Docker pour les périphériques IoT ainsi que pour les services distribués tels
que le CDN ou l'informatique de périphérie. Nebula est capable de mettre à jour
simultanément des dizaines de milliers d'appareils IdO dans le monde entier avec un seul
appel d'API. Nebula vise à aider les développeurs et les opérateurs à traiter les appareils IoT
de la même manière que les applications dockerisées distribuées.
Lien: http://nebula.readthedocs.io/en/latest/

Page 60 sur 97
concernant Docker

DOCKER
4.2 Intégration continue

4.2.1 Jenkins
Jenkins est un outil de CI de premier plan qui permet aux équipes de développement et
d’opération d’automatiser les cycles de construction et de test des applications. En tant que
tel, il est devenu un outil synonyme du mouvement DevOps. Jenkins est un programme
autonome basé sur Java qui fonctionne immédiatement et fournit des centaines de plug-ins
conçus pour s'intégrer à d'autres outils de votre pile. Cet outil vous permet de provisionner
rapidement des agents de construction, de déployer des artefacts, puis de les démanteler
rapidement.
Coût: gratuit
4.2.2 CircleCI
CircleCI promet d’aider les équipes logicielles à se concentrer sur la création de valeur pour
les clients plutôt que sur la maintenance de l’infrastructure CI. CircleCI améliore la
productivité de l'équipe informatique en rendant le processus de CI plus rapide et plus
simple. Il s’intègre rapidement et vous permet de construire et de déployer immédiatement
après l’inscription. Déboguer manuellement via SSH et mettre à l'échelle de manière
dynamique le nombre de conteneurs en même temps lorsque vous démarrez un projet.
Lien: https://circleci.com/
Coût: le premier conteneur est gratuit; projets open source +3 gratuits; conteneurs
supplémentaires 50 $ / mois (par conteneur)

Page 61 sur 97
concernant Docker

DOCKER
4.2.3 Travis CI
Travis CI est un projet CI gratuit et à code source ouvert qui améliore l'efficacité d'un
processus de développement en permettant la construction et le test automatiques des
modifications de code. La plateforme Saas (Software-as-a-Service) est alors capable de
fournir un retour immédiat sur le succès du changement de code. Travis CI est également
capable d'automatiser d'autres parties de votre processus de développement en gérant les
déploiements et les notifications.
Lien: https://travis-ci.org/
Coût: gratuit
4.2.4 CodeShip
CodeShip est une plate-forme CI entièrement personnalisable qui fournit une prise en
charge native de Docker en travaillant avec vos flux de travail Docker établis. La plate-forme
est dédiée à la vitesse et à la sécurité. Elle automatise vos tâches de test et de déploiement
et vous permet de contrôler totalement votre environnement de construction. Il offre une
prise en charge de nombreuses autres plates-formes de cloud et outils d’orchestration.
Lien: https://codeship.com/
Coût:
Basic: Gratuit pour 100 versions / mois, le prix commence à 49 $ / mois
Pro: commence à 75 $ / mois

Page 62 sur 97
concernant Docker

DOCKER
4.2.5 GitLab CI
GitLab combine la révision de CI, de CD et de code pour gérer le cycle de vie complet de
votre application. Il fonctionne avec GitLab Runner sur Docker Engine pour permettre des
tests automatisés et des versions d'applications. Les autres fonctionnalités comprennent les
flux d'activité, l'EDI, le suivi des problèmes et la gestion de référentiels. GitLab CI dispose
également d'un registre de conteneurs intégré pour analyser et stocker les référentiels
Docker.
Lien: https://about.gitlab.com/features/gitlab-ci-cd/
Coût:
Community Edition: Utilisateurs gratuits et illimités
Enterprise Edition Starter: 3,25 $ / utilisateur / mois
Enterprise Edition Premium: 16,59 $ / utilisateur / mois
4.2.6 Shippable
Accélérez la livraison de logiciels avec Shippable; une plate-forme SaaS pour les
développeurs qui réduit considérablement le temps nécessaire pour générer, tester et
déployer du code en production. Shippable est conçu pour être une plate-forme
d'automatisation centralisée permettant la pratique de DevOps et optimisant l'innovation
en offrant une visibilité complète du flux de travail. La simple interface plug-and-play
signifie que Shippable s’intègre facilement à de nombreuses autres architectures
d’application et piles technologiques.
Lien: https://www.shippable.com/
Coût:
Gratuit: noeud c4.large, constructions illimitées, 1 travail simultané
25/75/150 / mois: c4 noeuds de grande taille / xlarge / 2xlarge, chaque tâche simultanée
Module complémentaire Enterprise Support: commence à 500 USD / mois

Page 63 sur 97
concernant Docker

DOCKER
4.2.7 CodeFresh
CodeFresh fournit une chaîne d'outils complète avec laquelle les développeurs peuvent
créer et automatiser des pipelines de livraison. Construits sur Kubernetes, ces pipelines
Docker CI / CD natifs offrent une gestion des ressources rapide et efficace avec la mise en
cache. CodeFresh combine un registre adapté aux entreprises avec une connexion et un
déploiement transparent vers Kubernetes.
Lien: https://codefresh.io/
Coût:
Gratuit (repos public seulement)
Basic: commence à 99 $ / mois (pensions privées et publiques)
Pro: 299 $ / mois, noeuds dédiés avec SSH
4.2.8 Buddy
Créez, testez et déployez des applications en un rien de temps. Buddy est une plate-forme
CI / CD et de retour d’information avec une interface utilisateur conviviale, une intégration
rapide et des outils permettant de rendre le déploiement continu plus efficace et productif.
Il prend en charge tous les langages et infrastructures courants, notamment Angular, Ruby,
Python, PHP / Laravel, Node.js et .NET Core.
Lien: https://buddy.works/
Coût:
Pigiste: 49 $ / mois
Équipe: 99 $ / mois
Maison de logiciels: 199 $ / mois
Méga: 299 $ / mois

Page 64 sur 97
concernant Docker

DOCKER
4.2.9 Drone
Drone est une plate-forme open source pour les CI et le déploiement en tant que service. Il
repose sur la technologie de conteneur qui utilise Go et Docker. La plate-forme ne nécessite
aucune installation, configuration ou maintenance de serveur et s'intègre de manière
transparente à BitBucket, Heroku, GitHub, etc. pour automatiser la création, le test et le
déploiement de code à l'aide de conteneurs Docker.
Lien: https://drone.io/
Coût:
Nano: 125 $ / mois
Micro: 250 $ / mois
Méga: 500 $ / mois
4.2.10 Wercker
Une plate-forme d'automatisation CI et CD native à Docker conçue pour aider les
développeurs de logiciels à construire et à déployer leurs applications et architectures de
microservice complexes. Grâce à son intégration native à Kubernetes, Wercker automatise
vos flux de travail de déploiement afin que vous puissiez vous concentrer sur la création
d'applications.
Lien: http://www.wercker.com/
Coût: Édition communautaire: gratuit; Pipelines privés virtuels: à partir de 350 $ / mois

Page 65 sur 97
concernant Docker

DOCKER
4.3 Surveillance
4.3.1 Sumo Logic
Sumo Logic est un outil de révision de journal basé sur le cloud qui fournit des options
avancées d’analyse, de visualisation et d’alerte. La solution de surveillance des mesures
fournit des informations opérationnelles et de sécurité en temps réel, et vous permet de
diagnostiquer et de dépanner tous les problèmes d'application et d'infrastructure. L'analyse
d'apprentissage automatique signifie également la découverte rapide et la prévision future
des menaces et des anomalies avant qu'elles ne deviennent un problème et affectent les
utilisateurs finaux.
Lien: https://www.sumologic.com/
Coût:
Gratuit: jusqu'à 500 Mo / jour
Professionnel: Journaux et mesures: 90 $ / mois, 1 Go / jour
Enterprise: Logs & Metrics: 150 $ / mois, 1 Go / jour
4.3.2 Prometheus
Développé par SoundCloud, Prometheus est une boîte à outils open source de surveillance
du système et d’alerte. Il intègre de nombreux aspects de la surveillance, tels que la
génération et la collecte de mesures, la visualisation des résultats et les fonctionnalités
d'alerte en cas d'anomalie. Prometheus excelle dans l’enregistrement de séries
chronologiques numériques et complète à la fois la surveillance centrée sur la machine et
les architectures hautement dynamiques axées sur les services.
Lien: https://prometheus.io/
Coût: gratuit

Page 66 sur 97
concernant Docker

DOCKER
4.3.3 Sysdig
Sysdig Open Source est la technologie de base de tous les produits Sysdig. L'outil open
source est conçu pour fournir un dépannage détaillé d'un hôte unique et fonctionne comme
une interface basée sur une ligne de commande.
Lien: https://www.sysdig.org/
Coût:
Open-source: gratuit
Base: 20 $ / mois
Pro Cloud: 30 $ / mois
Logiciel Pro: Varie
4.3.4 Moniteur Sysdig

Sysdig Monitor (anciennement Sysdig Cloud) est la solution commerciale de Sysdig pour la
génération et l'analyse d'informations au niveau du système et de données en temps réel.
Conçu comme un outil de dépannage pour l'exploration de systèmes Linux, il offre une
visibilité approfondie sur les conteneurs, ce qui le rend incroyablement utile dans les
environnements Docker.
Lien: https://sysdig.com/product/how-it-works/
Coût: Tarification flexible pour les versions Cloud et Software
4.3.5 Datadog
Datadog est une plate-forme d'analyse de données SaaS pour les environnements cloud à
grande échelle qui génère et collecte des métriques / événements de données à partir de
serveurs, bases de données et applications. Le service de surveillance de pile complète
prend en charge Docker, Kubernetes et Mesos. Lien: https://www.datadoghq.com/
Coût:
Gratuit jusqu'à 5 hôtes
Pro: 15 $ / hôte / mois
Entreprise: 23 $ / hôte / mois

Page 67 sur 97
concernant Docker

DOCKER
4.3.6 Nouvelle relique

Chef de file de l'industrie, New Relic est une solution de gestion de la performance basée
sur SaaS qui permet aux développeurs de diagnostiquer et de résoudre les problèmes de
performance des applications en temps réel. Ses fonctionnalités de surveillance des
performances des applications (APM) offrent une visibilité instantanée et l'agent Linux de
son infrastructure collecte automatiquement les métriques de conteneur Docker qui
s'exécutent sur des hôtes instrumentés.
Lien: https://newrelic.com/
Coût:
Environnements auto-hébergés: 149 $ par mois; Essentials: 75 $ / mois
Options basées sur le cloud: en fonction de la taille du fournisseur et de l'instance, de
l'exécution et de la quantité
4.3.7 cAdvisor
CAdvisor (Container Advisor) de Google est une solution de surveillance qui analyse toutes
les caractéristiques de performance et l'utilisation des ressources des conteneurs exécutés
dans Docker. L'outil génère et collecte des métriques de conteneur, telles que des
statistiques réseau, des paramètres d'isolation de ressources et un historique complet de
l'utilisation des ressources.
Lien: https://github.com/google/cadvisor
Coût: gratuit

Page 68 sur 97
concernant Docker

DOCKER
4.4 Enregistrement
4.4.1 Logspout
Logspout est un excellent outil pour aider à gérer les journaux générés par les programmes
exécutés dans les conteneurs Docker. Il achemine les journaux du conteneur-application
vers un emplacement unique (par exemple, vers un objet JSON ou un noeud final diffusé
disponible sur HTTP). Logspout a également un système de module extensible.
Lien: https://github.com/gliderlabs/logspout
Coût: gratuit
4.4.2 Fluentd
Fluentd fonctionne comme un collecteur de données open source, un conteneur
permettant d'unifier et de consigner les journaux de tous les autres conteneurs. Avec plus
de 500 plugins, Fluentd se connecte à de nombreuses sources de données et sorties de
données pour collecter des événements. Ceux-ci sont étiquetés pour les acheminer au
besoin. Ce routage basé sur les balises permet d’exprimer proprement le routage complexe.
Lien: https://www.fluentd.org/
Coût: gratuit
4.4.3 Logstash
Une partie de Elastic Stack, Logstash fonctionne bien aux côtés de Beats, Elasticsearch et
Kibana. Il s'agit d'un pipeline de traitement côté source ouvert côté serveur qui transporte
et traite vos journaux, événements et autres données.
Lien: https://www.elastic.co/products/logstash
Coût: gratuit

Page 69 sur 97
concernant Docker

DOCKER
4.4.4 Syslog-ng
Utilisez syslog-ng pour collecter les journaux de différentes sources et les traiter en temps
quasi réel avant de les acheminer vers différentes destinations. Syslog-ng est une
infrastructure de gestion de journaux de confiance qui associe des fonctionnalités hautes
performances à de riches options d’analyse et de réécriture des messages.
Lien: https://syslog-ng.org/
Coût: gratuit (tarification pour syslog-ng Premium Edition disponible sur demande)

Page 70 sur 97
concernant Docker

DOCKER
4.5 Sécurité
4.5.1 Clair
Clair est un projet open source conçu pour identifier et analyser les vulnérabilités des
conteneurs d'applications Docker et appc. Clair ingère régulièrement des métadonnées de
vulnérabilité de conteneur à partir d'un groupe de sources personnalisé et configuré afin
d'identifier les menaces dans les images de conteneur, y compris celles en amont.
Lien: https://coreos.com/clair/docs/latest/
Coût: gratuit
4.5.2 Aqua security

Aqua Security fonctionne sur n’importe quelle plate-forme pour sécuriser les applications
basées sur les conteneurs en fournissant une sécurité complète. Aqua Security, une
plateforme spécialement conçue à cet effet, permet un contrôle strict de votre
environnement conteneur et de vos processus dès la phase de développement. C'est un
outil complet qui offre une visibilité et une gestion complètes.
Lien: https://www.aquasec.com/
Coût: La tarification est une combinaison de charges de forfait logiciel sélectionnées et de
coûts d'infrastructure Azure pour les machines virtuelles nécessaires.

Page 71 sur 97
concernant Docker

DOCKER
4.5.3 Twistlock
Twistlock Security Suite a pour objectif de résoudre le problème de la sécurité dans le
processus d’application par conteneur. Il s’agit d’une solution de sécurité de bout en bout
qui détecte les vulnérabilités en augmentant le nombre de couches de surveillance du
fonctionnement des conteneurs Docker. Twistlock durcit les images de conteneur et
applique les politiques de sécurité tout au long du cycle de vie d'une application.
Lien: https://www.twistlock.com/
Coût: La tarification des logiciels est basée sur les options d'abonnement et d'infrastructure
choisies
4.5.4 Docker bench for security

Docker Bench for Security est un conteneur pré-assemblé pouvant être exécuté sur
n’importe quel hôte Docker. C'est un groupe de scripts shell Bash qui doivent être exécutés
en tant qu'utilisateur root. Les tests vérifient les meilleures pratiques de sécurité communes
concernant le déploiement de conteneurs Docker en production.
Lien: https://hub.docker.com/r/docker/docker-bench-security/
Coût: gratuit
4.5.5 Notary Docker

Notary est un projet Docker à source ouverte qui assure la sécurité des collections de
données. Exécutez un service de notaire pour publier et gérer du contenu arbitraire. Signer
numériquement les collections publiées et permettre aux utilisateurs de vérifier l'intégrité
et l'origine du contenu.
Lien: https://github.com/docker/notary
Coût: gratuit

Page 72 sur 97
concernant Docker

DOCKER
4.6 Stockage
4.6.1 Convoy
Un plugin de volume Docker créé par Rancher pour gérer les volumes de conteneur
persistants. Convoy, un pilote de volume Docker à code source ouvert, peut effectuer des
instantanés, des sauvegardes et des restaurations de volumes Docker n’importe où. Créez
des volumes Docker sur AWS, pris en charge par toutes les fonctionnalités et performances
d'Elastic Block Store. Prenez également un volume EBS existant et utilisez-le pour générer
un volume attaché à un conteneur Docker.
Lien: https://github.com/rancher/convoy
Coût: gratuit
4.6.2 Portworx
Portworx est une solution de stockage décentralisée pour les volumes persistants, partagés
et répliqués. il automatise le déploiement et les opérations des services de données à
grande échelle.
Lien: https://portworx.com/
Coût: gratuit
4.6.3 Blockbridge
Blockbridge Volume Plugin fournit un stockage hautes performances pour les applications
conteneur avec des fonctionnalités avancées de sécurité, de mobilité, de sauvegarde et de
restauration. Avec le «plug-in Docker géré» pour Docker 1.13+, l'installation et la gestion du
cycle de vie sont gérées de manière native par Docker.
Lien: http://www.blockbridge.com/
Coût: gratuit

Page 73 sur 97
concernant Docker

DOCKER
4.7 Mise en réseau

4.7.1 Flannel
Conçu pour Kubernetes, flannel constitue un moyen simple et facile de configurer une
structure réseau sécurisée à l'aide d'un réseau IPv4 de couche 3 entre plusieurs noeuds d'un
cluster. Il ne contrôle pas la manière dont les conteneurs sont mis en réseau sur la plate-
forme hôte, mais simplement la manière dont le trafic est transporté entre les hôtes.
Lien: https://coreos.com/flannel/docs/latest/
Coût: gratuit
4.7.2 Weaveworks
Weaveworks offre aux développeurs un moyen productif de connecter, d’observer et de
contrôler les conteneurs Docker. Il crée une infrastructure de réseau virtuel flexible qui
connecte les conteneurs déployés sur plusieurs hôtes. Weaveworks étend l'efficacité des
orchestrateurs de conteneurs tels que Kubernetes et Docker Swarm et simplifie la gestion
des conteneurs en production.
Lien: https://www.weave.works/
Coût:
Standard: 30 $ par noeud / mois ou 300 $ par an
Entreprise: 150 USD par noeud / mois ou 1500 USD par an

Page 74 sur 97
concernant Docker

DOCKER
4.7.3 Projet Calico

Projet Open Source hautement évolutif, Calico propose une approche de couche 3 en
matière de réseau virtuel, capable de prendre en charge un grand nombre de clusters de
machines virtuelles sur d'innombrables hôtes de calcul. La conception simplifiée du modèle
de réseau de cet outil prend en charge la configuration de stratégies de connectivité
détaillées pour chacune de vos charges de travail et permet la gestion centralisée des
réseaux SDN.
Lien: https://www.projectcalico.org/getting-started/docker/
Coût: gratuit

Page 75 sur 97
concernant Docker

DOCKER
4.8 Découverte de service

4.8.1 Consul
Consul est une approche facile à utiliser, basée sur des standards ouverts, de découverte de
services et fonctionnant sous FreeBSD, Linux, Mac OS X, Solaris et Windows. Conçu pour
prendre en charge plusieurs centres de données, Consul prend en charge plusieurs régions
sans configuration complexe. Les fonctionnalités clés incluent : découverte de services,
vérification de l'intégrité, stockage de clés / valeurs, etc.
Lien: https://www.consul.io/
Coût: gratuit
4.8.2 Etcd
Créé par CoreOS, etcd est un magasin clé-valeur hautement disponible conçu pour la
configuration partagée et la découverte de services. L'outil fournit un moyen fiable de
stocker des données sur un cluster de machines. Il a été conçu spécialement pour les
clusters exécutant CoreOS, mais etcd fonctionne également sur d'autres systèmes
d'exploitation, notamment BSD, Linux et OS X.
Lien: https://coreos.com/etcd/
Coût: gratuit
4.8.3 Procuration
Factorish a créé un proxy sous la forme d’un conteneur léger et facile à utiliser (<30 Mo).
L'outil est basé sur alpine / gliderlabs avec nginx exécuté en tant qu'équilibreur de charge
HTTP.
Lien: https://hub.docker.com/r/factorish/proxy/
Coût: gratuit

Page 76 sur 97
concernant Docker

DOCKER
4.9 Build
4.9.1 Packer
Packer est un outil Hashicorp créé pour créer des images de machines, y compris Docker, et
pour intégrer des outils de gestion de la configuration tels que Ansible, Chef et Puppet. C'est
un outil léger qui fonctionne sur tous les principaux systèmes d'exploitation à partir d'une
configuration source unique.
Lien: https://www.packer.io/docs/builders/docker.html
Coût: gratuit
4.9.2 Whales
Dockerize automatiquement vos applications avec les baleines. La seule chose nécessaire
est que Docker soit installé et fonctionne sur la machine hôte. Whales fonctionne ensuite en
générant les fichiers nécessaires à l'exécution de vos applications avec Docker.
Coût: gratuit
4.9.3 Gradle
Le plugin Gradle simplifie la communication de tous vos scripts de construction avec un
démon Docker. Chaque tâche est déléguée au client Docker, qui se connecte ensuite à l'API
distante de Docker via HTTP. La plupart des paramètres de configuration sont facultatifs.
Coût: gratuit

Page 77 sur 97
concernant Docker

DOCKER
4.10 Gestion graphique

4.10.1 Portainer
Portainer est une interface utilisateur de gestion légère à source ouverte pour les
environnements Docker. Portainer fonctionne au-dessus de l'API Docker et fournit une
présentation détaillée de Docker. Les fonctionnalités incluent la capacité de gérer des
conteneurs, des images, des réseaux et des volumes.
Lien: https://portainer.io/
Coût: gratuit

Page 78 sur 97
concernant Docker

DOCKER
5 Glossaire
Image Docker
Une image Docker est le modèle de base d'un conteneur Docker. Une image contient
généralement le système d'exploitation et les applications facilement installées. L’image
Docker étant utilisée pour exécuter le conteneur, vous pouvez trouver de nombreuses
images avec divers systèmes d’exploitation et logiciels installés dans Docker Hub
https://hub.docker.com/ .
Container Docker
Docker Container est une image lisible et écrite qui s’exécute en haut de l’image Docker.
Docker utilise le système de fichiers union comme backend pour le conteneur ; toutes les
modifications apportées dans le conteneur seront enregistrées dans un nouveau calque
situé au-dessus de l'image de base. Le conteneur est la couche où nous installons des
applications. Chaque conteneur s'exécute de manière isolée sur la machine hôte et fournit
donc une plate-forme applicative sécurisée.
Registre Docker
Le registre Docker est un référentiel pour les images Docker. Il fournit des référentiels
publics et privés. Le registre public de Docker s'appelle Docker Hub. Ici, nous pouvons
pousser et tirer nos propres images.
SAN
(Storage Area Network).

Page 79 sur 97
concernant Docker

DOCKER
6 Webographie
How to Install and Use Docker on Ubuntu 18.04

https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-
ubuntu-18-04
Projets et tuto Docker
https://www.digitalocean.com/community/tags/docker?type=tutorials
Vidéo de vulgarisation de docker
https://www.youtube.com/watch?v=caXHwYC3tq8
Docker store
https://store.docker.com/
Commandes de Docker sur github
https://gist.github.com/freuds/c7ac848203320ebe3961ceffe8aef7f0
Docker – Les commandes utiles
https://www.jbnet.fr/systeme/docker/docker-les-commandes-utiles.html
Docker principe et fonctionnement
http://ordinatous.com/pdf/docker.pdf

Page 80 sur 97
concernant Docker

DOCKER
7 Annexe : Comparatif des solutions réseaux pour

Kubernetes
Source : https://www.objectif-libre.com/fr/blog/2018/07/05/comparatif-solutions-reseaux-
kubernetes/
7.1 Fonctionnement de Kubernetes
Kubernetes impose aux réseaux de suivre les règles suivantes :

Tous les pods peuvent communiquer entre eux sans NAT
Les noeuds peuvent communiquer avec les pods (et inversement) sans NAT
L’IP vue par le conteneur est la même que l’IP vue par les composants externes
Il existe deux types de mise en place réseaux :
• soit l’utilisation du réseau k8s proposé par défaut
• soit l’utilisation de CNI et de ses plugins – la solution la plus fréquente et sur laquelle
porte notre comparatif.
7.2 Réseaux K8s par défaut
La première solution pour configurer le réseau consiste à créer sur chaque hôte un bridge
virtuel avec une plage d’IP, puis à ajouter sur chaque hôte les routes vers les autres hôtes à
la main. En utilisant une solution Google ou Amazon, la configuration manuelle est possible,
mais lorsqu’on s’en éloigne, il devient plus difficile de gérer ces configurations. Ci-dessous
un exemple de configuration pour la création d’un bridge sur un seul noeud avec une seule
interface :
brctl addbr kubbr1
ip link add veth1kubbr1 type veth peer name kubbr
ip addr add 10.10.1.1/24 dev veth1kubbr1
ip link set veth1kubbr1 up
brctl addif kubbr1 veth1kubbr1
ip link set up kubbr1

Page 81 sur 97
concernant Docker

DOCKER
7.3 Solution utilisant CNI et un plugin réseau
La seconde option pour mettre en place le réseau dans Kubernetes est de passer par le
Container Network Interface (CNI) et un plugin réseau. Les configurations de base sont
faites automatiquement. La création et la gestion du réseau sont grandement facilitées.
Le réseau sous Linux peut être défini de deux façons différentes : l’underlay et l’overlay. Il
est possible avec Kubernetes d’utiliser les deux.
L’underlay est le réseau physique, matériel composé des switchs, routeurs…
L’overlay est le réseau virtuel composé de vlan, veth (interface virtuelle) et VxLAN, il
encapsule l’architecture réseau matériel. Le fonctionnement avec l’overlay est un peu plus
lent qu’en underlay, il crée des tunnels entre les hôtes ce qui réduit les MTU disponibles.
7.4 A propos de Container Network Interface
CNI est un ensemble de spécifications et librairies (en Go) ayant pour but de faciliter
l’intégration de plugins réseau. Un plugin CNI doit être exécutable par le système de
management de conteneur utilisé. Il gère la mise en place de l’interface (ainsi que son IP)
dans un namespace, et sa configuration avec l’hôte (connexion avec un bridge, gestion des
routes). La configuration du type de réseau utilisé se fait dans un fichier /etc/cni/net.d/xx-
mynet.conf. On y spécifie généralement le nom du réseau, son type (bridge, vlan, ipvlan,
loopback, macvlan, ptp) ainsi que son IPam (IP address management : dhcp, host-local) avec
un type, le sous-réseau et les routes rattachées. Les plugins réseaux créent des types qui
leur sont propres en se basant sur ces informations.
7.5 K8s comparaison de différentes solutions CNI + plugin
Les solutions de réseaux compatibles avec Kubernetes sont nombreuses, et toutes utilisent
ou créent un plugin CNI.
Les trois solutions les plus utilisées sont Calico, Flannel et WeaveNet. Deux autres, Cilium et
Contiv, proposent aussi des fonctionnalités intéressantes. Dans cet article, nous allons
détailler les différentes solutions existantes et leur fonctionnement avec Kubernetes.

Page 82 sur 97
concernant Docker

DOCKER
7.6 Calico
7.6.1 Présentation
Calico est une solution réseau pour Kubernetes qui se veut simple, scalable et sécurisée.
Côté réseau, elle supporte l’adressage ipv4 et ipv6. Elle utilise le composant de Kubernetes
kube-proxy pour gérer les règles de filtrage. Kube-proxy utilise les iptables Linux pour créer
des règles de filtrage sur les réseaux et ainsi isoler les conteneurs.
Pour rentrer dans le détail : Calico fonctionne par défaut en Ethernet (L2). Il peut se
configurer pour utiliser IPinIP (L3). IPinIP est un tunnel IP, un paquet IP encapsule un autre
paquet IP en ajoutant en header un champ « SourceIP » qui sert d’entrée pour le tunnel et
le champ « Destination » qui sert de point de sortie. Calico offre deux configurations pour
IPinIP :
l’option always avec laquelle tout le trafic est encapsulé
ou crossSubnet avec laquelle seul le trafic entre les sous-réseaux est encapsulé.
7.6.2 Fonctionnement
Calico utilise différents composants :
Felix : agent Calico, disposé sur chaque hôte fournissant des points de sortie (interface vers
l’extérieur), il partage les tables d’adressage ip et les routes entre les noeuds.
BIRD (bgp) : client (et route reflector) utilisé avec confd pour BGP. Border Gateway Protocol
(BGP) est un protocole de routage qui partage ses informations de routage (tables) avec des
systèmes autonomes (routeurs). BIRD est un daemon qui agit comme un routeur
dynamique utilisé par Calico avec BGP. Il est utilisé pour centraliser la distribution des
routes.
confd : monitore etcd pour les configurations et changements de configuration BGP. Il
génère automatiquement les configurations BIRD.
etcd ou API Kubernetes : etcd est un outil de sauvegarde de type clef-valeur utilisé pour
stocker les données.
7.6.3 Utilisation
Calico supporte les networkPolicies de Kubernetes, sa configuration se fait en yaml (dans un
fichier de configuration /etc/calico/calicoctl.cfg). La configuration est possible avec la
commande « calicoctl ».
Les différentes ressources utilisables pour la configuration sont : BGPPeer,
BGPConfiguration, HostEndpoint, NetworkPolicy, GlobalNetworkPolicy, IPPool : réseaux
utilisés pour les réseaux Kubernetes, Profile, FelixConfiguration et WorkloadEndpoint. Il
s’agit des différentes ressources de Calico, elles servent pour la configuration (et se place
dans le champ kind, voir l’exemple ci-dessous). Chacune à une fonction spécifique.

Page 83 sur 97
concernant Docker

DOCKER
7.6.4 Réseau Calico
Il est possible de créer des sous-réseaux ou nouveaux réseaux Calico avec la ligne de commande «
calicoctl ».
Voici un exemple de création d’un réseau avec Calico :
calicoctl create -f -<<EOF
- apiVersion: v1 # ou projectcalico/v3
kind: ipPool
metadata:
cidr: 10.12.13.0/24
spec:
ipip:
enabled: true
mode: always
nat-outgoing: true
EOF
Le réseau et les sous-réseaux Calico peuvent se représenter comme dans l’image ci-dessous.
Dans cet exemple, il y a deux sous-réseaux, et chaque sous-réseau est défini par rapport au
cluster entier et non par machine composant le cluster. Deux conteneurs peuvent faire partie
d’un même réseau et être hébergés sur deux machines différentes.
Le choix du réseau est possible et se fait avec l’annotation suivante dans la partie metadata
du template du pod lors du déploiement d’un yaml avec Kubernetes :
metadata:
annotations:
"cni.projectcalico.org/ipv4pools": "[\"10.112.12.0/24\"]" # ou ipv6pools si
ipv6 est utilisé

Page 84 sur 97
concernant Docker

DOCKER
7.6.5 Déploiement
Calico est installé en DaemonSet avec un conteneur sur chaque noeud et un « calico-
controller » sur le master. Chaque noeud du cluster a 3 composants de Calico installés :
Felix, BIRD et confd ; le master a en plus un contrôleur. Chaque envoi de données entre les
noeuds se fait avec les tunnels IPinIP vus précédemment.
Réseau Calico dans le cas d’un cluster 3 noeuds sur le même réseau
Retrouvez la documentation :
https://docs.projectcalico.org/v3.1/usage/

Page 85 sur 97
concernant Docker

DOCKER
7.7 Cilium
7.7.1 Présentation
Cilium est une solution réseau pour Kubernetes fonctionnant sur les couches L3/L4 pour la
partie réseaux et L7 pour la partie application. Le fonctionnement sur cette dernière couche
permet d’ajouter des règles de filtrage haut niveau pour les applications web par exemple.
Elle supporte IPv4 et IPv6. Cilium est actuellement la seule solution réseau à effectuer un
filtrage avec BPF.
7.8 BPF – Berkeley Packet Filter

7.8.1 Présentation
BPF est une solution de filtrage de paquets qui remplace la solution iptables. Le filtrage ne
s’effectue plus au niveau applicatif, mais au niveau du kernel, ce qui le rend plus rapide, plus
fonctionnel et plus sécurisé. Cilium utilise BPF pour créer et appliquer les règles de filtrage
sur les paquets, aucune règle iptable n’est créée. Les filtres sont plus efficaces et plus
flexibles.
Cilium fonctionne avec cilium-agent lancé sur chaque noeud. Cilium-agent gère les
opérations et les filtres pour les partager avec l’hôte. Il compile les règles BPF pour ensuite
les passer au kernel de l’hôte.

Page 86 sur 97
concernant Docker

DOCKER
7.8.3 Utilisation
Cilium peut fonctionner avec un réseau overlay (figure1) ou avec le routage natif (figure2).
L’ipv4 et l’ipv6 sont supportés dans les deux cas. Le mode overlay est le mode par défaut.
Comme on peut le voir sur l’image ci-dessous, un sous-réseau est attribué à chaque noeud.
Le routage natif est plus complexe d’utilisation. Chaque paquet sortant du réseau local est
envoyé sur le système de routage du kernel qui s’occupe de rediriger les paquets. Les règles
de sécurité sont gérées pour ipv6 ; en ce qui concerne ipv4, il faut utiliser les règles CIDR.
L’ip forwarding est activé par Cilium, mais les règles de redirection doivent être gérées
manuellement ou via un protocole de routage comme BGP.

Page 87 sur 97
concernant Docker

DOCKER
7.8.4 Réseaux Cilium

Cilium ajoute ses propres network policies utilisables avec kubectl get ciliumnetworkpolicy
(ou cnp) pour filtrer les paquets de couche L7 comme http et kafka. Il applique
automatiquement les networks policies de Kubernetes. Toutes ces configurations peuvent
se faire en yaml. L’exemple ci-dessous est une règle de filtrage L7 faite avec les
CiliumNetworkPolicy pour filtrer du http qui autorise l’accès à « / » aux pods ayant le label
‘access’ à true.
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
description: "Allow HTTP GET / from app=web to access=true"
metadata:
name: "rule1"
spec:
endpointSelector:
matchLabels:
app: web
ingress:
- fromEndpoints:
- matchLabels: # vérification des labels
access: "true"
toPorts:
- ports:
- port: "80"
protocol: TCP
rules:
http:
- method: "GET"
path: "/"
Une network policy créée par Kubernetes est visible avec la commande « cilium policy get ».
Le fichier est au format json. Ci-dessous un exemple d’une networkPolicy créée en yaml et
appliquée avec Kubernetes et son enregistrement au format json retourné par la commande
« cilium policy get ».

Page 88 sur 97
concernant Docker

DOCKER
Cilium network policy yaml et json (format de sauvegarde)

Plusieurs commandes permettent de voir l’état des données de Cilium. La liste est disponible
ici http://cilium.readthedocs.io/en/latest/cheatsheet/, quelques exemples ci-dessous :
kubectl exec -n kube-system cilium-qpxvw

-- ls -al /sys/fs/bpf/tc/globals/ # liste les entrées bpf
-- cilium bpf policy list -n 19898 # affiche la policy ayant ce numéro (version
type iptables)
-- cilium status # donne le status du noeud (ou --all-containers pour tous)
-- cilium policy get # liste toutes les policies reçue par cilium (format json)
Cilium propose un système d’identité permettant de mettre un niveau de priorité et des tags
utilisés sur des pods.
Cilium fonctionne avec kube-proxy. Mais lorsque ClusterIP (load balancing pour le trafic
entre pods) est implémenté, Cilium fonctionne comme proxy en ajoutant et supprimant des
règles BPF (sur chaque noeud) en fonction de l’évolution des machines sur le cluster.
Lorsqu’il est utilisé avec Istio, il utilise Envoy comme proxy.
7.8.5 Déploiement
Cilium se déploie en tant que pod dans Kubernetes avec un DaemonSet. Il crée un bridge sur
chaque noeud. Ces bridges communiquent avec des veth pour chaque pod.
Retrouvez la documentation : http://cilium.readthedocs.io/en/latest/

Page 89 sur 97
concernant Docker

DOCKER
7.9 Contiv
Contiv est une solution réseau pour Kubernetes proposée par Cisco et fonctionnant en
VxLAN ou sur la couche L3 avec BGP. Contiv supporte IPv4 et IPv6. Il propose aussi une
intégration des ACI (Application Centric Infrastructure) Cisco, mais Cisco propose une
solution réseau ACI pour Kubernetes spécialement conçue pour ce dernier. Il se base sur
OpenVSwitch pour les pipelines et utilise etcd pour la sauvegarde clef-valeur.
Contiv se lance avec deux composants :
- netplugin est installé sur chaque noeud. Il implémente les CNI utilisées, il gère aussi les
créations d’interfaces pour les conteneurs, les allocations d’IP…
- netmaster n’est installé que sur le(s) master(s) du cluster en DaemonSet. Il s’occupe de
gérer les requêtes en simultané, et des routes envoyées aux composants netplugin.
Les deux composants précédents utilisent les IP de leurs hôtes pour communiquer. Un vlan
« contiv » est créé par défaut, regroupant tous les noeuds du cluster.
7.9.2 Utilisation
Plusieurs réseaux peuvent être créés avec la commande « netctl ». Tous sont utilisables par
n’importe quel noeud. Les réseaux utilisables sont visibles avec la commande « netctl net ls
». Les ips sont récupérées dans les pools ayant le Nw Type à data.
La spécification du réseau se fait dans les labels lors de la création de yaml Kubernetes.
La spécification du réseau se fait dans les labels lors de la création de yaml Kubernetes.
labels:
io.contiv.tenant: default
io.contiv.network: contiv-net

Page 90 sur 97
concernant Docker

DOCKER
Contiv fonctionne avec de l’overlay pour définir les sous-réseaux, un sous-réseau n’est donc
pas uniquement sur un noeud, il est partagé dans tout le cluster ; ainsi, comme on peut le
voir sur la figure ci-dessous, plusieurs machines peuvent faire partie d’un même réseau en
étant sur différents hôtes.
Contiv ne supporte pas les network policies de Kubernetes, mais possède ses propres
network policies avec sa propre API pour les règles de filtrage.
Il propose deux types de règles :
Les règles réseaux de type Bandwith permettent de limiter la bande passante pour un
groupe.
Les règles réseaux de type Isolation permettent de créer une white-list ou black-list pour une
application, ainsi que les actions pouvant être effectuées par le groupe (création,
suppression, modification, vue).
La commande « netctl » permet de faire ces configurations, mais la création de ces règles est
aussi faisable avec l’API web proposée par Contiv.
Cette interface permet aussi la gestion des tenants / des utilisateurs (authentification ldap
possible) et des réseaux.
De plus Contiv est certifié plugin openshift.

Page 91 sur 97
concernant Docker

DOCKER
7.9.3 Déploiement
Contiv se déploie en suivant le lien suivant : https://github.com/contiv/install#kubernetes-
installation. Au final, ce sont des DaemonSet Kubernetes qui tournent sur le cluster.
Retrouvez la documentation : http://contiv.github.io/documents/gettingStarted/.

Page 92 sur 97
concernant Docker

DOCKER
7.10 FLannel
7.10.1 Présentation
Flannel est une solution réseau pour Kubernetes fonctionnant avec plusieurs backends,
VxLAN étant le backend recommandé (les autres sont plus expérimentaux) pour encapsuler
les paquets. Seul l’IPv4 est supporté.
Fonctionnement
Flannel fonctionne avec etcd, notamment pour lire ses configurations et stocker les
configurations réseaux. Il met en place des sous-réseaux sur chaque hôte grâce à un agent
nommé flanneld.
Flannel crée un seul réseau VxLAN. Chaque nouveau pod est rattaché à ce VxLAN avec une
veth. Flannel ne supporte pas le lancement de plusieurs réseaux sur un seul daemon, mais il
est possible de lancer plusieurs daemons sur un seul hôte avec des configurations
différentes.
7.10.2 Utilisation
Flannel créé un bridge cni0 sur chaque noeud et y attache des interfaces veth. Les pods ne
sont créés que sur les minions, le master ne contient aucune instance (sauf les instances
pour son fonctionnement qui utilisent l’ip rattaché au réseau externe). Chaque noeud a
donc son sous-réseau du pool flannel. La communication est possible grâce aux VxLAN
flannel créés sur tous les hôtes.
Il est possible d’activer avec VxLAN-GBP, le routage direct des paquets lorsque plusieurs
hôtes sont sur le même réseau. Les réseaux VxLAN sont alors utilisés uniquement si les
réseaux sont différents.
Flannel gère le trafic ipv4 uniquement entre les noeuds d’un cluster. Il se concentre sur le
réseau et ne supporte pas les network policies de Kubernetes.

Page 93 sur 97
concernant Docker

DOCKER
7.10.3 Déploiement
Flannel construit un DaemonSet par hôte. Avant de le déployer, il faut rajouter
--allocate-node-cidrs=true --cluster-cidr=10.32.0.0/16 dans le fichier
/etc/kubernetes/manifests/kube-controller-manager.manifest
puis redémarrer kubelet. L’installation est décrite ici

Retrouvez la documentation : https://github.com/coreos/flannel#flannel

Page 94 sur 97
concernant Docker

DOCKER
7.11 WeaveNet
7.11.1 Présentation
WeaveNet est une solution réseau proposant un plugin réseau (Weave CNI Plugin) pour
Kubernetes fonctionnant avec des VxLAN en L2. Il utilise kube-proxy et kube-dns (son
composant weave-DNS est désactivé dans le cas d’une intégration avec Kubernetes). Il
supporte IPv4 et IPv6.
Contrairement à la plupart des solutions réseaux qui utilisent etcd pour stocker les données,
WeaveNet les enregistre dans un fichier
/weavedb/weave-netdata.db
sur chaque pod créé par le DaemonSet. Chaque pod du DaemonSet possède l’adresse ip de
l’interface physique du noeud sur lequel il est placé. Chaque pod contient 2 conteneurs
weave et weave-npc (Network Policy Controller).
Le conteneur weave gère tout le fonctionnement de Weave sur le noeud. Le conteneur
weave-npc s’occupe uniquement de la partie filtrage mis en place avec les NetworkPolicies
de Kubernetes.
7.11.3 Utilisation
Les pods ne sont créés que sur les minions, le master ne contient aucune instance (sauf les
instances pour son fonctionnement). WeaveNet supporte les NetworkPolicies de
Kubernetes pour les règles de filtrage de type Ingress. Il propose une API web pour gérer le
réseau (weave scope).
7.11.4 Réseau Weave

Comme on peut le voir sur l’image ci-dessous, sur chaque noeud est crée un bridge « weave
». Les conteneurs créés sont connectés grâce à une interface virtuelle sur le bridge de
l’hôte. Tous ces bridges sont ensuite encapsulés en VxLAN pour communiquer avec le reste
du cluster.

Page 95 sur 97
concernant Docker

DOCKER
Il est possible de définir un mot de passe weave pour chiffrer la communication réseau
directement lors de la création du DaemonSet avec des surcharges sur l’url (documentation
: configuration options). Plus d’informations sur le chiffrement mis en place :
https://github.com/weaveworks/weave/issues/3086
Il est possible de définir plusieurs sous-réseaux. L’allocation de sous-réseau se fait avec
IPAM et peut se faire en mode :
• seed : il faut disposer d’un premier cluster avec un nombre fixe de machines. Chaque
machine va avoir un sous-réseau. Il est possible d’ajouter au cluster des machines,
qui peuvent soit faire partie intégrante du cluster (nouvelle machine fixe), soit être
intégrées dynamiquement selon les besoins (la machine peut donc être supprimée).
• consensus : détermine les réseaux avec un algorithme de consensus (par défaut).
Utilisé pour mettre en place weave en mode interactif ou pour un cluster fixe où
l’ajout et la suppression de machines est rare. Ce mode utilise la commande weave
prime qui met en place automatiquement l’allocation IP des noeuds.
• observer : permet d’ajouter un noeud en tant qu’observateur. Ce dernier
demandera un pool d’IP si besoin (en cas de surcharge d’un noeud) en demandant à
un noeud de diviser son pool d’IP. Il permet d’ajouter dynamiquement des noeuds
au cluster selon les besoins (auto-scaling).
7.11.5 Déploiement
Plusieurs installations sont possibles :
Chaque noeud lance WeaveNet directement sur la machine hôte.
WeaveNet peut être déployé directement en DaemonSet sur chaque noeud Kubernetes
depuis ce lien. Tout est créé avec un fichier yaml récupérable et personnalisable.
Retrouvez la documentation : https://www.weave.works/docs/net/latest/kubernetes/kube-
addon/
7.12 Conclusion
Les plugins réseaux sont un vrai atout et facilitent la gestion de celui-ci. Chacun correspond
à des besoins différents.
Pour la mise en place d’un POC, ou si on souhaite mettre en place le réseau d’un cluster
rapidement, il est préférable d’utiliser Flannel ou WeaveNet.
Calico, Contiv et Cilium proposent de faire directement de l’underlay (avec BGP
notamment), évitant une encapsulation VxLAN.
Plusieurs solutions (Calico, Contiv) proposent l’ajout de plusieurs réseaux virtuels communs
à tout le cluster, les pods créés peuvent ainsi être connectés à un même réseau et hébergés
sur différent noeuds.
Cilium est plus axé sécurité et offre un filtrage niveau applicatif. Il utilise BPF pour filtrer
niveau kernel. Le filtrage BPF offre de meilleures performances qu’un filtre avec iptables.
Page 96 sur 97
concernant Docker

DOCKER
7.13 Récapitulatif
Solutio Kubernete IPv Couches Réseau Déploiemen Ligne de Note

n s network 6 utilisées x t commande
Policies s
Calico Oui Oui L3 Plusieur DaemonSet calicoctl
(IPinIP, s
BGP) réseaux
sur le
cluster
Cilium Oui + Oui L3/L4 + Sous- DaemonSet cilium Peu
Cilium L7 réseaux (sur les remplacer
Network (filtrage par pods kube-proxy
Policies ) noeud DaemonSet (filtrage
) avec BPF)
Contiv Non Oui L2 Plusieur DaemonSet netctl
(VxLAN) s
/ L3 réseaux
(BGP) sur le
cluster
Flannel Non Non L2 Plusieur DaemonSet Non
(VxLAN) s
réseaux
sur le
cluster
avec
plusieur
s
daemon
Weave Oui Oui L2 Sous- DaemonSet Non chiffremen
net (VxLAN) réseaux t possible,
par n’utilise
noeud pas etc

Page 97 sur 97
concernant Docker

Cours - Docker

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours - Docker

Transféré par

Droits d'auteur :

Formats disponibles

La formation à 360°

Document reprenant les étapes de configurations et

Date de modification : 12/11/21 Version : 1

Easyformer - 12 rue des violettes - 95000 Cergy

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

3.5.8 Swarm ............................................................................................................................................. 38

4 OUTILS DOCKER ..................................................................................................................................... 55

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

4.5.5 Notary Docker ................................................................................................................................. 72

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

7.11.5 Déploiement ................................................................................................................................ 96

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

1.2 Time sharing

Le temps partagé ou pseudo-parallélisme1, est une approche permettant de simuler le

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

1.3 Multi programming

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

La virtualisation est l'ensemble des techniques matérielles et logicielles permettant de

2.1.3 Postes de travail

La virtualisation des stockages permet :

• D’exploiter au maximum les ressources,

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

2.2 Les technologies de virtualisation

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

2.2.6 Virtualisation assistée par matériel

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

3.1.2 Principe de Docker

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

3.2 Installations et configurations

3.2.2 Bonnes pratiques

Puis gérer l’adressage avec le « netplan » :

Voici un exemple de configuration réseau :

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

3.2.4 Installation sous Linux

Ajoutez ensuite la clé GPG du référentiel officiel de Docker à votre système :

Ajoutez le référentiel Docker aux sources APT:

Enfin, installez Docker :

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

docker.service - Docker Application Container Engine

sudo apt update && apt upgrade

Ensuite nous allons installer docker, rendez-vous à la racine puis :

Maintenant nous allons faire en sorte de démarrer automatiquement Docker à chaque

Enfin nous démarrons notre service

Et nous vérifions que tout est bien démarré :

docker.service - Docker Application Container Engine

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

Pour appliquer la nouvelle appartenance au groupe, déconnectez-vous du serveur et reconnectez-

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

Document reprenant les étapes de configurations et administrations

© EASYFORMER 2016 - Tous droits réservés Date : 12/11/21

3.3 Utilisation de Docker