Docker, créer et administrer

vos conteneurs virtuels

d'applications

Docker, créer et administrer vos conteneurs virtuels d'applications

• Objectifs :
– Comprendre le positionnement de Docker et des conteneurs
– Manipuler l'interface en ligne de commande de Docker pour créer des
conteneurs
– Mettre en œuvre et déployer des applications dans des conteneurs
– Administrer des conteneurs

• Prérequis :
– Connaissances de base de l'administration Linux.

1
Sommaire

De la virtualisation à Docker

Présentation de Docker
Mise en œuvre en ligne de commande

Création de conteneur personnalisé

Mettre en œuvre une application multiconteneur

Interfaces d'administration

Administrer des conteneurs en production

Orchestration et clustérisation

DE LA VIRTUALISATION
À DOCKER

2
De la virtualisation à Docker

● Les différents types de virtualisation.

● La petite histoire des conteneurs.
● Le positionnement de Docker.

Les différents types de virtualisation.

3
La virtualisation

● La virtualisation consiste à exécuter sur une machine hôte, dans un

environnement isolé des systèmes d’exploitation ou des applications.

● La virtualisation permet d’optimiser l’utilisation des machines physiques et

rend la gestion des serveursplus souple.
● Chaque outil de virtualisation peut mettre en œuvre :
● Couche d’abstraction matérielle

● Partitionnement, isolation et/ou partage des ressources

● Images systèmes manipulables : démarrage, arrêt, clonage, migration, sauvegarde…

● Réseau virtuel entre hôte et invités

Les différents types de virtualisation.

● Différentes approches de virtualisation existent :

● Hyperviseur de type 1

● Hyperviseur de type 2

● Noyau en espace utilisateur

● Isolateur

● La virtualisation peut être intégrée ou assistée par le processeur (ex:

virtualiser la mémoire, …). Cela permet de limiter la dégradation des
performances.
● Ex: AMD-v, Intel VT, hyperviseur IBM Power, Mainframes, …

4
Hyperviseur de type 2

● Logiciel qui tourne sur l’OS hôte, il permet de

lancer un ou plusieurs OS invités.
● Le matériel est virtualisé et/ou émulé pour les
OS invités (en virtualisation, le CPU, la RAM et le
stockage sont accessible directement).

● Isole bien les OS invités, mais a un coût en performance (surtout si le CPU est
émulé).
● On peut faire cohabiter des OS hétérogènes et les faires communiquer via le
réseau.
● Ex: Vmware Fusion, Oracle Virtualbox, Parallels Desktop, Microsoft VirtualPC, …

Hyperviseur de type 1

● Noyau système très léger et optimisé pour gérer

les accès des OS invités à l’architecture
matérielle hôte.
● On parle de « para-virtualisation » si les OS
invités ont conscience d’être virtualisés et sont
optimisés en conséquence.

● C’est la méthode de virtualisation d’infrastructure la plus performante mais elle

est onéreuse.
● Ex: Citrix Xen Server, Vmware vSphere, Microsoft Hyper-V Server, …

5
Noyau en espace utilisateur

● Un noyau en espace utilisateur tourne comme

une application sur l’OS hôte.
● Le noyau user- space a son propre espace
utilisateur dans lequel il contrôle ses applications.

● Solution très peu performante et l’isolation des environnements n’est pas gérée et
l’indépendance par rapport à l’OS hôte est inexistante.
● Surtout utilisé pour le développement du noyau Linux.
● Ex: User Mode Linux, coLinux, Adeos, L4Linux, …

Isolateur

● Logiciel permettant d’isoler des applications dans

des « contextes » ou « zones d’exécution ».
● Solution très performante car peu d’ « overhead »
mais les environnements ne sont pas
complétement isolés.

● Liés aux systèmes Linux, les isolateurs sont composés de plusieurs éléments et
peuvent prendre plusieurs formes.
● Ex: Linux-Vserver, chroot, BSD Jail, OpenVZ, LXC, Docker, …

6
 La petite histoire des conteneurs.

La petite histoire des conteneurs. (1/ 7)

● L’appel système « chroot » est introduit dans le développement d’Unix v7

en 1979 puis sous BSD en 1982.

● Il permet de redéfinir la racine d’un processus ( « / » sous les systèmes

Unix). Cela permet d’isoler ce dernier du reste du système.
● Ce mécanisme est assez rudimentaire, mais il peut préserver les librairies
systèmes de modifications non désirées lors de la compilation d’une
application par exemple.
● Ce n’est plus une pratique très répandue mais les gestionnaires de paquets
(apt/yum/…) l’utilisent encore.
● En 1991,un autre bénéfice de « chroot » est mis en avant : la sécurité avec la
création de « honeypots ».

7
La petite histoire des conteneurs. (2/ 7)

● Les « jails » ont été introduits dans FreeeBSD 4.0 en 2000.

● Ce sont une amélioration de « chroot » : en plus du système de fichier, ils
permettent également de séparer les processus, les utilisateurs et le réseau.
● Le « jail » est relativement simple d’utilisation et ne demande pas une
équipe de spécialiste pour leur mise en œuvre, d’où une certaine
popularité.
● Les avantages sont évidents : chaque « jail » est dans un environnement
virtuel propre dans lequel on peut déléguer le compte « root ».
● Mais cela à des limites : plusieurs techniques existent pour contourner
l’isolation en place, s’en échapper (jailbreak) et prendre la main sur l’OS
hôte.

La petite histoire des conteneurs. (3/ 7)

● En 2001, « VServer » permet sous Linux la virtualisation au niveau du

système d’exploitation et offre des mécanismes similaires aux « jails » de
BSD.
● Mais il y a un gros inconvénient : le noyau Linux doit être patché pour en
bénéficier. Cela a fortement compromis son adoption.
● Les « namespacesLinux », inspirés des namespaces de « Plan 9 » (Bell
Labs), ont été intégrés dans le noyau Linux 2.4.19 en 2002.
● C’est une fonctionnalité du noyau Linux qui partitionne les ressources du
noyau de sorte qu'un ensemble de processus voit un ensemble de
ressources, tandis qu'un autre ensemble de processus voit un ensemble de
ressources différent.

8
La petite histoire des conteneurs. (4/ 7)

● Si Solaris n’a pas eu la même popularité que les BSD auprès du grand
public, il disposait d’un budget de R&D important et a eu des
fonctionnalités innovantes.
● Parmi celles-ci, les « zones » ont été introduit dans Solaris 10 en 2005.
● Assez similaires aux « jails » BSD mais couplés au système de fichier ZFS, il
devient très simple de faire des snapshots et de cloner une zone.
● On pouvait avoir plusieurs OS Solaris (voir d’autres système comme Linux
avec les « Branded Zones ») sur le même hôte avec un « overhead » très
faible.
● Cela n’a toutefois pas permis à Solaris de s’imposer face aux autres
systèmes d’exploitation.

La petite histoire des conteneurs. (5/ 7)

● En 2005, « OpenVZ » est, comme « VServer », un projet open source.

● Il bénéficie de nombreuses fonctionnalités, mais à le même inconvénient
que ce dernier : il faut patcher le noyau pour en bénéficier.
● En 2006, Google lance les « Process Containers » conçus pour limiter les
ressources disponibles pour un processus (CPU, RAM, disque, réseau, …)
● Ils sont renommés « Control Groups» (cgroups) en 2007 et intégrés au
noyau Linux 2.6.24

9
La petite histoire des conteneurs. (6/ 7)

● En 2008, les « Linux Containers» (LXC) sont les premiers à combiner les
« cgroups » et les « namespaces ».
● Son point faible en 2008 : la sécurité. Il est en effet possible pour
l’utilisateur « root » de lancer un processus sur l’hôte… en « root ».
● La sécurité a été renforcée depuis la version 1.0 (02/2014).
● Son utilisation reste trop centrée sur les technologies et pas assez sur un
écosystème capable de le rendre attrayant.
● « Let Me ContainThat For You» (LMCTFY) a été lancé comme projet open
par Google en 2013 comme version open-source de leur outil interne.
● Malgré des fonctionnalités intéressantes, Google a considéré qu’il serait
mieux de se consacrer à un outil plus simple : libcontainer (Docker).

La petite histoire des conteneurs. (7/ 7)

● En 2013, l’arrivée de « Docker» popularise la conteneurisation.

● Les premières versions de Docker utilisaient « LXC » avant de passer à
« libcontainer ».
● Le succès très important de Docker par rapport aux technologies similaires
préexistantes s’explique par plusieurs points :
● Docker CLI : un démon s’exécutant sur l’hôte, proposant une API et un modèle client-serveur.

● Dockerfile : un fichier texte permettant de construire un nouveau conteneur facilement à partir

d’une image de base.
● Docker Registry: un dépôt permet de télécharger et de partager gratuitement des images.

● Docker-compose : permet de définir une application multi-conteneur en un seul fichier YAML.

10
 Le positionnement de Docker.

Le positionnement de Docker.

● Docker est devenu un des outils les plus en vue dans le paysage informatique.
● Docker est un ensemble d’outil facilitant la mise en œuvre d’une virtualisation
légère.
● Dans une virtualisation classique (hyperviseur de type 2), les OS invités
consomment un très grande quantité de ressources (CPU, RAM, HDD, …) pour
nombre de fonctionnalités non utilisées.
● D’autant plus que l’on déploie rarement des OS invités dans une
infrastructure, ce qui renforce le « gâchis ».
● Des optimisations peuvent être mises en place dans ces outils (ex: sur-
provisionning de mémoire, mutualisation de portions d’images, …) mais cela
reste intrinsèquement limité.

11
Le positionnement de Docker.

● Docker permet de faire fonctionner plus d’applications pour la même quantité

de ressources. (5 à 80 x plus)
● Au delà des considérations écologiques, c’est surtout la vitesse de mise en
œuvre d’un conteneur qui explique le succès de Docker. (quelques centaines
de ms versus quelques dizaines de secondes pour une machine virtuelle)
● Docker réalise cette économie de ressources sans sacrifier l’étanchéité des
conteneurs, qui est assurée au niveau de l’OS hôte.

● Bien sûr des failles peuvent exister, comme dans tout processus logiciel, il faut
donc suivre l’apparition de correctifs.

PRÉSENTATION DE DOCKER

12
Présentation de Docker

● L'architecturede Docker.
● Disponibilité et installation de Docker sur différentes plateformes
(Windows, Mac et Linux).

● Création d'une machine virtuelle pour maquettage.

● La ligne de commande et l'environnement.

L'architecture de Docker.

13
L'architecture de Docker.

● Docker est basé sur une architecture client-serveur.

● Le « client Docker » communique avec le « démon Docker » qui s’occupe de
la création, le lancement et la distribution des conteneurs.
● Le client et le démon Docker peuvent être déployés sur une même machine
ou sur des machines différentes.
● Le client et le démon communiquent en utilisant une API REST, via des sockets
UNIX ou via une interface réseau.

L'architecture de Docker.

14
Le démon et le client Docker

● Le démon Docker ( dockerd ) écoute les requêtes interrogeant son API.

● Il gère les images, les conteneurs, les réseaux et les volumes.

● Un démon peut communiquer avec d’autres démons Docker pour gérer des
services distribués.
● Le client Docker ( docker ) est le point d’entrée principale pour interagir avec
Docker.
● Lorsqu’on lance une commande tel que « docker run », le client envoie la
commande, via l’API, au démon Docker qui va devoir la gérer.
● Un client Docker peut communiquer avec plusieurs démons.

Les registres Docker

● Un « registre Docker » stocke des « images Docker ».

● Le « Docker Hub » est un registre public utilisable par tout le monde et qui est
la cible par défaut de Docker pour la récupération des images.
● On peut également mettre en place son propre registre Docker.
● Les commandes « docker pull » et « docker run » téléchargent les
images depuis le registre (par défaut ou propre).
● La commande « docker push » publie une image sur le registre.

15
Les images Docker

● Les images sont des notices de montage, en lecture seule, pour la création de
conteneur.
● La plupart du temps les images se basent sur une autre image, et rajoutent
simplement de la configuration supplémentaire (fichiers, variables
d’environnements, …).
● On peut créer ses propres images ou utiliser celles disponibles dans le registre.
● Pour créer sa propre image, on crée un fichier « Dockerfile » avec une
syntaxe simple décrivant les instructions nécessaires à la création et au
lancement de celle-ci.

Les conteneurs Docker

● Un conteneur est une instance d’une image.

● On peut créer, démarrer, arrêter, déplacer ou supprimer un conteneur via l’API
Docker ou via le client Docker en ligne de commande.
● On peut connecter un conteneur à un ou plusieurs réseaux, y attacher des
espaces de stockages ou même créer un nouvelle image à partir de son état
courant.
● On peut gérer l’isolation d’un conteneur (et des ses composants) avec les
autres conteneurs et le système hôte.
● Un conteneur est défini par son image et par les options de configuration
définies au lancement. Quand un conteneur est supprimé, tous les
changements non stockés dans un dossier persistant sont perdus.

16
Les services Docker

● Un service Docker permet de dimensionner des conteneurs sur plusieurs

démons Docker, qui travaillent tous ensemble comme un « swarm » (essaim)
avec plusieurs « managers » et « workers ».
● Chaque membre du « swarm » est un démon Docker. Tous les démons
communiquent via l’API Docker.
● On peut définir l’état d’un service, tel que le nombre de « replicas » qui doivent
être disponibles à un moment donné.
● Par défaut, le service est load-balancé sur tout les « workers ».
● Pour le client, le service apparait comme une application unique.
● Les « swarm » ont été ajoutés dans la version 1.12de Docker.

Disponibilité et installation de Docker

sur différentes plateformes
(Windows, Mac et Linux).

17
Les éditions de Docker

● Docker est disponible en 2 éditions :

● Community Edition (CE)

● Entreprise Edition (EE)

● “Docker Community Edition (CE) is ideal for individual developers and small
teams looking to get started with Docker and experimenting with container-
based apps.”
● “Docker Enterprise Edition (EE) is designed for enterprise development and IT
teams who build, ship, and run business critical applications in production at
scale.”

Docker CE

● Docker est disponible sous les systèmes :

● Linux
● CentOS

● Debian

● Fedora

● Ubuntu

● Windows

● Mac

18
Docker CE Linux (CentOS 7)

● Pour l’installation de Docker sous CentOS, le repository « centos-extras » doit

être activé.
● Installez certain packages utiles :
sudo yum install -y yum-utils device-mapper-persistent-data lvm2

● Déclarez le repository Docker :

sudo yum-config-manager --add-repo
https://download.docker.com/linux/centos/docker-
ce.repo

● InstallezDocker CE :
sudo yum install docker-ce docker-ce-cli containerd.io

Docker CE W indows

● La version la plus « actuelle » pour installer Docker sous Windows est

« Docker Desktop ».
● Ses prérequis sont :
● Windows 10 64 bit en version Pro, Entreprise ou Education.

● Virtualisation activé dans le BIOS

● Un CPU supportant la traduction d'adressesde second niveau (SLAT)

● 4 GBde RAM minimum

● Cela est dû à l’utilisation des containers Windows HyperV.

● Il suffit essentiellement de lancer l’installeur disponible sur le site Docker.

19
Docker CE Mac

● La version la plus « actuelle » pour installer Docker sous Mac est « Docker
Desktop ».
● Ses prérequis sont :
● Un hardware datant de 2010 ou plus récent avec les fonctionsde virtualisation Intel.

● MacOSSierra 10.12 ou plus récent

● 4 GBde RAM minimum

● Pas de VirtualBox jusqu’à la version 4.3.30 installé

● Il suffit de lancer le DMG disponible sur le site Docker puis de glisser

l’application Docker dans le dossier « Applications ».

Docker CE Toolbox

● Pour les systèmes Windows et Mac ne pouvant installer « Docker Desktop »,

« Docker Toolbox » est utilisable comme solution de repli.
● Ce logiciel utilise Oracle VirtualBox au lieu de la virtualisation HyperV sous
Windows par exemple.
● Les prérequis sous W indow s sont :
● W indow s7 minimum en 64bit

● Virtualisation activé sur la machine

● Les prérequis sous Mac sont :

● MacOs 10.8 « Mountain Lion » minimum

20
 La ligne de commande et l'environnement.

La ligne de commande du client Docker (1/ 2)

● La syntaxe de la ligne de commande est la suivante :

docker [OPTIONS] <COMMAND> [ARG...]

● Quelques options :
● --config string Location of client config files (default "/root/.docker")

● -D, --debug Enable debug mode

● --help Print usage

● -H, --host value Daemon socket(s) to connect to (default [])

● -l, --log-level string Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")

● -v, --version Print version information and quit

● …

21
La ligne de commande du client Docker (2/ 2)

● Quelques commandes :
● pull : récupère une image depuis le registre
● run : démarre un nouveau conteneur
● stop : arrête un ou plusieurs conteneurs
● rm : supprime un ou plusieurs conteneurs
● commit : crée une nouvelle image depuis l’état actuel d’un conteneur
● build : crée une nouvelle image depuis un Dockerfile
● container : gère les conteneurs
● image : gère les images
● network : gère les réseaux
● volume : gère les volumes
● …
● Chaque commande accepte ces propres arguments.

L’environnement

● Docker définit automatiquement certaines variables d’environnement lors de

la création d’un conteneur Linux.

● Docker ne définit aucune variable d'environnement lors de la création d'un

conteneur Windows.
● Les variables d'environnement suivantes sont définies pour les conteneurs
Linux:
● HOME Set based on the value of USER

● HOSTNAME The hostname associated with the container

● PATH Includes popular directories, such as / usr/ local/ sbin:/ usr/ local/ bin:/ usr/ sbin:/ usr/ bin:/ sbin:/ bin

● TERM xterm if the container is allocated a pseudo- TTY

● On peut également définir des variables d’environnement via un ou plusieurs

paramètres « -e ». Si on ne définit pas de valeur pour une variable, celle de
l’hôte est transmise au conteneur.

22
 MISEEN ŒUVREEN
LIGNEDE COMMANDE

Mise en œuvre en ligne de commande

● Mise en place d'un premier conteneur.

● Le Docker hub : ressources centralisées.

● Gestion de données dans un conteneur.

● Gestion du réseau dans un conteneur.

23
 Mise en place d'un premier conteneur.

Gestion des images (1/2)

● La commande permettant de lister les images déjà téléchargées :

docker images [OPTIONS] [REPOSITORY[:TAG]]
● L’argument optionnel [REPOSITORY[:TAG]] restreint la liste des images,
ex: docker images java:8

24
Gestion des images (2/2)

● La commande permettant de gérer les images :

docker image <COMMAND>

● Les principales commandes :

● pull [OPTIONS] NAME[:TAG|@DIGEST] : télécharge une image depuis le registre
● inspect [OPTIONS] IMAGE [IMAGE...] : affiche des infos détaillées sur une ou plusieurs images
● push [OPTIONS] NAME[:TAG] : télécharge une image sur le registre
● rm [OPTIONS] IMAGE [IMAGE...] : supprime une ou plusieurs images
● ...

Mise en place d’un conteneur

● La mise en place d’un conteneur passe par la commande suivante :

docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]

● Par défaut un conteneur est « attaché » à la console, pour qu’il se lance

détaché, on rajoute l’option « -d » :
docker run –d nginx

● Par défaut, les conteneurs sont nommés aléatoirement.

● Pour pouvoir gérer plus facilement les conteneurs, donnez leur vous-
même un nom avec l’option « --name » :
docker run --name web1 nginx

25
Le mode interactif.

● Quand le conteneur est « attaché », les flux STDIN, STDOUT et STDERR

du conteneur sont attachés à la console (l’option « -a » permet d’en
attacher seulement certains).

● Pour avoir accès à la console du conteneur, ajoutez l’option « -it » :

docker run -it debian

Le Docker hub : ressources centralisées.

26
Docker Hub

● Docker Hub est un site web fourni par Docker pour rechercher et partager
des images de conteneur avec son équipe et le monde si on le souhaite.

● Il fournit les fonctionnalités suivantes:

● Repositories: pour pousser et tirer les images de conteneurs.

● Teams & Organizations: pour gérer l'accès aux référentiels privés d'images de conteneurs.
● Official & Publisher Images: pour tirer des images de conteneurs fournies respectivement par Docker et
par des fournisseurs externes. Les images certifiées incluent également une assistance et garantissent la
compatibilité avec Docker Enterprise.

● Builds: pour construire automatiquement des images à partir de GitHub et Bitbucket.

● Webhooks: pour déclencher des actions après une insertion réussie dans un repository.

Repositories (1/ 2)

● Les « repositories » permettent de partager des images avec la

communauté Docker (mode public) ou avec son équipe (mode privé).
● Un repository permet de stocker une seule image, mais en plusieurs
versions via les « tags », par exemple :
● mongo:latest

● mongo:4 , mongo:4.0 , mongo:4.0.10

● mongo:4.0.10-xenial

27
Repositories (2/ 2)

● Les images sont uploadées via la commande « docker push ».

● Il faut préalablement avoir créé un compte sur le Docker Hub.

● Par défaut les repositories sont créés en public.

● Pour créer un repository privé, il faut le déclarer préalablement ou changer
la visibilité d’un repository public.

● On peut chercher des images dans le Docker Hub via le web ou via la ligne
de commande :
docker search <imagename>

Official Images

● Les images « officielles » sont des images qui sont conçues pour :
● Fournir des images de base d’OS servant de point de départ à la majorité des autres images.
● Fournir des solutionsprêtes à l’emploi pour des langages de programmation, bases de
donnéeset autres services populaires.

● Appliquer les mises à jour de sécurité de manière réactive.

● Les images officielles sont analysées à la recherche pour les vulnérabilités.

Les résultats sont visibles dans l’onglet « tags » des images.

● Ces images officielles sont à privilégier autant que possible.

28
Publisher Images

● Les éditeurs de logiciels peuvent distribuer et vendre leurs productions via

des images « Verified Publisher ».
● Ces images peuvent être des versions d’essai accessibles ou des images
commerciales à acheter (dans ce cas, le paiement a lieu sur le Docker Hub).

● Les éditeurs peuvent également être « Docker Certified » s’ils atteignent les
critères de qualité, sécurité et support de ce programme.

Teams & Organizations

● Il est possible de déclarer des « Teams » dans le Docker Hub.

● Ce sont des groupes d’utilisateurs ayant un compte Docker Hub.

● Préalablement, on crée un compte que l’on transformera en « Organization »
en désignant un autre compte qui sera ajouté dans la team « Owner ».

● Cette team peut gérer l’organisation, créer d’autre équipes et gérer les
repositories.

● C’est via les teams que l’on accorde des droits de lecture, lecture/écriture ou
d’administration sur un repository.

29
 Gestion de données dans un conteneur.

Gestion de données dans un conteneur. (1/3)

● Par défaut, tous les fichiers créés dans un conteneur sont stockés dans un
calque de conteneur en écriture.

● Cela signifie que :

● Les données ne persistent pas lorsque ce conteneur n’existe plus.
● Le calque de conteneur en écriture est étroitement couplé à la machine sur laquelle le
conteneur est exécuté.

● Ecrire dans un calque de conteneur en écriture nécessite un pilote de stockage pour gérer le
système de fichiers. Le pilote de stockage fournit un système de fichiers « union » utilisant le
noyau Linux.

● Cette abstraction supplémentaire réduit les performances par rapport à l'utilisation de

volumes de données, qui écrivent directement dans le système de fichiers hôte.

30
Gestion de données dans un conteneur. (2/3)

● Docker met à disposition plusieurs solutions pour persister les données :

● Les « volumes » sont stockés dans une partie du système de fichier hôte géré par Docker. Les
autres processus ne doivent pas modifier cette partie du système de fichier.

● Les « binds mounts » peuvent être stockés n’importe où sur le système hôte. Les autres
processus peuvent modifier les fichiers.

● Si vous utilisez Docker sous Linux, vous pouvez également utiliser un « tmpfs
mount ».

● Si vous utilisez Docker sous Windows, vous pouvez également utiliser un

« named pipe ».

Gestion de données dans un conteneur. (3/3)

31
Volumes (1/2)

● Les volumes constituent le mécanisme privilégié pour la persistance des

données générées et utilisées par les conteneurs.

● Les volumes ont pour avantages par rapport aux « bind mounts » :
● Les volumes sont plus facilesà sauvegarderou à migrer.
● On peut les gérer via la ligne de commande et l’API Docker.

● Fonctionnent sur Linux et W indows.

● Peuvent être partagés entre plusieurs conteneurs d’une manière plus sécurisée.

● Peuvent être situés sur des hôtes distants ou sur des fournisseurs cloud, être chiffrés, etc…

● Peuvent être pré- remplis de données.

Volumes (2/2)

● Les volumes peuvent être créés à l’avance via la commande :

docker volume create <volume-name>

● Lors du lancement d’un conteneur, on associe un volume avec l’option « -v » :

docker run –v <volume-name>:</path/in/container> <image>

● Pour limiter le volume en lecture seule, il suffit de rajouter le paramètre

« :ro » dans l’option « -v » :
docker run –v <volume-name>:</path/in/container>:ro <image>

32
Bind mounts

● Les « bind mounts » ont des fonctionnalités plus limitées que les volumes.

● Un fichier ou un répertoire de l’hôte est monté dans le conteneur.

● Les « bind mounts » sont performants mais s’appuient sur le système de
fichier de l’hôte. Il est conseillé de plutôt se baser sur les volumes.

● Lors du lancement d’un conteneur, on monte un dossier avec l’option « -v » :

docker run –v </path/host>:</path/container> <image>

● Pour limiter le dossier en lecture seule, il suffit de rajouter le paramètre

« :ro » dans l’option « -v » :
docker run –v </path/host>:</path/container>:ro <image>

tmpfs mounts

● Les « tmpfs mounts » permettent de stocker des fichiers temporaires en dehors

du calque de conteneur en écriture.
● Ainsi les fichiers ne persistent qu’en mémoire et ne sont perdus lors que le
conteneur est stoppé.

● Cela est utile pour stocker temporairement les fichiers sensibles que vous ne
souhaitez pas conserver dans l'hôte ou dans la couche en écriture du conteneur.

● Lors du lancement d’un conteneur, on monte un dossier avec l’option « --

tmpfs » :
docker run --tmpfs </path/container> <image>

33
 Gestion du réseau dans un conteneur.

Gestion du réseau dans un conteneur.

● Docker peut mettre en œuvre plusieurs types de réseaux entre un ou

plusieurs conteneurs et l’hôte :
● bridge : type par défaut. Généralement utilisé pour les applicationstournant dans un
conteneur isolé qui doit communiquer.

● host : pour les conteneursisolés, ils utilisent le réseau hôte directement

● overlay : connecte des démonsDocker ensemble (conteneursou swarm distribués)

● macvlan : permet d’attribuer à un conteneur une adresseMAC directement sur le réseau

● none : désactive le réseau pour un conteneur

● Il est également possible d’utiliser des plugins tiers pour accéder à d’autres
types de réseaux.

34
Bridge networking. (1/ 3)

● Le réseau « bridge » utilise un pont logiciel permettant aux conteneurs situés

sur le même réseau de communiquer entre eux (et isolés du reste).

● Ce réseau s’applique sur un seul démon Docker.

● Un réseau « bridge » appelé « bridge » est créé et utilisé par défaut, sauf si on
précise un nom différent au lancement d’un conteneur.

Bridge networking. (2/3)

● Les réseaux « bridge » personnalisés ont des avantages par rapport au

réseau par défaut :
● Les conteneursont leurs ports exposés automatiquement aux autres membres et aucun port
à l’extérieur. Seuls les ports ayant besoin d’être visibles à l’extérieur ont besoin d’être
exposés.

● Résolution DNS automatique entre les conteneursdu même réseau (en plus de l’adresse ip).

● Les conteneurspeuvent être attachés et détachés d’un réseau à chaud (sinon recréés).

● Les réseaux personnalisés peuvent être configurés différemment les uns des autres.

● Pour créer un réseau « bridge » :

docker network create <network-name>

35
Bridge networking. (3/ 3)

● Au lancement d’un conteneur, l’option « --network » permet de l’attacher à

un réseau personnalisé :
docker run --name <container-name> --network <network-name> <image>

● Pour connecter un conteneur déjà lancé :

docker network connect <network-name> <container-name>

● Pour déconnecter un conteneur déjà lancé :

docker network disconnect <network-name> <container-name>

Publication de ports réseau.

● Pour exposer des ports à l’extérieur d’un réseau « bridge », il suffit d’ajouter
une ou plusieurs options « --publish » au lancement des conteneurs
concernés :
docker run --network <network-name> --publish <host-
port>:<container-port> --publish <host-port>:<container-port>

36
Host networking.

● Dans le réseau « host », le conteneur n’est pas isolé en terme réseau et n’a
donc pas d’adresse IPpropre.

● Les services dans les conteneurs utilisent directement les ports de l’hôte.

● Il y a des limitations :
● Un seul service sur l’hôte peut s’approprier un port donné.

● Un service ne peut s’approprier un port déjà utilisé par l’hôte.

● Pour attacher un conteneur au réseau « host » :

docker run --network host image

CRÉATION DE CONTENEUR
PERSONNALISÉ

37
Création de conteneur personnalisé

● Produire l'image de l'état d'un conteneur.

● Qu'est- ce qu'un fichier Dockerfile ?

● Automatiser la création d'une image.

● Mise en œuvre d'un conteneur.

● Conteneur hébergeant plusieurs services : supervisor.

Produire l'image de l'état d'un conteneur.

38
Produire l'image de l'état d'un conteneur.

● Il peut être utile de « commiter » les modifications de fichier ou les paramètres

d’un conteneur dans une nouvelle image.

● Cela peut permettre de déboguer un conteneur en exécutant un shell interactif

ou d'exporter un jeu de données de travail vers un autre serveur.
● En règle générale, il est préférable d'utiliser les « Dockerfile » pour gérer ses
images de manière documentée et maintenable.
● La syntaxe : docker commit <container> <repository>:<tag>

● Les données dans les volumes du conteneur ne sont pas incluses.

Qu'est-ce qu'un fichier Dockerfile ?

39
Qu'est- ce qu'un fichier Dockerfile ? (1/ 2)

● Docker peut créer des images à partir des instructions contenues dans un
fichier « Dockerfile ».

● C’est un fichier texte qui peut contenir les différentes instructions que l’on
utilise dans le ligne de commande pour créer une image.
● La commande « docker build context » crée une image à partir d’un
Dockerfile et d’un contexte.
● Le contexte est un ensemble de fichiers contenu dans un dossier ou dans un
dépôt Git (les sous-dossiers sont inclus récursivement).
● L’ensemble du contexte est envoyé au démon Docker pour construire l’image :
il faut donc mettre dans le dossier uniquement ce qui est nécessaire pour
construire l’image.

Qu'est- ce qu'un fichier Dockerfile ? (2/ 2)

● Traditionnellement, le fichier Dockerfile se situe à la racine du contexte.

● Vous pouvez utiliser l’option « -f » avec la commande « docker build »
pour désigner un fichier à un autre emplacement.
● L’option « -t » permet de préciser le repository, le nom de l’image est le tag
sous lequel l’image sera sauvée :
docker build –t <repository>/<app-name>:<tag> <context>
docker build –t nebiljb/mongo-exercice:4.0 .
docker build –t nebiljb/mongo-exercice:4.2 –
t nebiljb/mongo-exercice:latest .

40
Format du fichier Dockerfile

● Le format d’un fichier Dockerfile est le suivant :

# Comment
<INSTRUCTION> <arguments>

● Les instructions ne sont pas sensibles à la casse mais par convention sont
écrites en majuscule.
● Les instructions sont exécutées dans l’ordre du fichier.
● La première instruction doit être « FROM » : elle précise l’image de base au
dessus de laquelle vous construisez votre image.
● Les lignes commençant par « # » sont considérées comme des commentaires,
sauf si ce sont des directives de parser valides.

Directive de parser

● Les directives de parser sont optionnelles.

● Leur format est le suivant :
# <directive>=<value>

● La même directive ne peut être utilisée qu’une seule fois.

● Pour être prise en compte une directive doit être située en haut du fichier
Dockerfile (avant commentaires, instructions et lignes vides).
● Définir le caractère d’échappement se fait grâce à la directive « escape » :
# escape=\
# escape=`

41
Utilisation de variable d’environnement

● Il est possible d’utiliser des variables d’environnement de l’hôte au sein du

Dockerfile lors du processus de build.
● Celles-ci sont notées « $variable_name » ou « ${variable_name} ».
● Les variables d’environnements sont supportées par les instructions :
● ADD ● STOPSIGNAL

● COPY ● USER

● ENV ● VOLUME

● EXPOSE ● WORKDIR

● FROM ● ONBUILD (en conjonction avec une

instruction précédente)
● LABEL

Automatiser la création d'une image.

42
ARG

● Syntaxe : ARG <name>[=<default value>]

● L’instruction ARG permet de définir une variable que l’on pourra fournir en
argument lors de la construction de l’image.
● Dans les lignes suivantes du Dockerfile, on peut utiliser cette variable en la
préfixant de « $ » :
ARG version
RUN echo $version
● La fourniture de la variable lors du build se fait via le paramètre « --build-
args » :
docker build --build-args version=1.0.1 .

FROM

● Syntaxe : FROM <image>[:<tag>]

● L’instruction FROM définit l’image de base à partir de laquelle vous construisez
votre image.
● Cette instruction doit être la première du Dockerfile.
● L’instruction ARG est la seule qui peut précéder l’instruction FROM.
ARG version
FROM mongo:$version

43
SHELL

● Syntaxe : SHELL ["executable", "parameters"]

● L'instruction SHELL permet de remplacer le shell par défaut utilisé par les
instructions qui reçoivent des commandes shell.
● Le shell Linux par défaut est : ["/bin/sh", "-c"]
● Le shell Windows par défaut est : ["cmd", "/S", "/C"]
● Cette instruction peut apparaitre plusieurs fois au sein d’un Dockerfile, son effet
s’applique dans ce cas jusqu’a la prochaine instruction SHELL.

RUN

● Syntaxe « shell »: RUN <command>

● Syntaxe « exec »: RUN ["executable", "param1", "param2"]
● L'instruction RUN exécute une commande dans une nouvelle couche de
l’image et « commit » le résultat.
● Le résultat « commité » sera utilisé pour les étapes suivantes du Dockerfile.
● Cette instruction est destinée à la création de l’image et ne doit pas utiliser le
service de l’image.

44
ADD / COPY

● Syntaxe: ADD/COPY [--chown=<user>:<group>] <src>... <dest>

● Les instructions ADD et COPYpermettent de copier un fichier ou un dossier du
contexte dans l’image.
● L’instruction ADD permet également de préciser une URL comme source.
● L’instruction ADD décompresse automatiquement certaines archives (sauf
venant d’une url).
● Il est conseillé d’utiliser COPYà moins d’avoir besoin des fonctionnalités de
l’instruction ADD (on peut également décompresser « manuellement » via une
instruction RUN).

EXPOSE

● Syntaxe: EXPOSE <port> [<port>/<protocol>...]

● L’instruction EXPOSEpermet de déclarer un ou plusieurs ports sur lesquels le
service dans l’image va écouter.
● Vous pouvez spécifier si le port écoute sur TCPou UDP. La valeur par défaut
est TCP si le protocole n'est pas spécifié :
EXPOSE 80
EXPOSE 80/tcp
EXPOSE 1234/udp

● Cela ne publie pas le port : c’est le rôle de l’option « -p » dans la commande

« docker run ».

45
VOLUME

● Syntaxe: VOLUME ["/data"]

● L’instruction « VOLUME » permet de désigner un ou plusieurs dossiers de
l’image qui seront partagés en tant que volumes externes.
● Ces volumes pourront être montés via l’option « -v » de la commande
« docker run ».
● Les volumes non montés explicitement lors du lancement d’un conteneur, sont
montés automatiquement par Docker de manière implicite mais sous un nom
aléatoire.

CMD / ENTRYPOINT

● Syntaxe: CMD ["param3","param4"]

● Syntaxe: ENTRYPOINT ["executable", "param1", "param2"]
● L’instruction « ENTRYPOINT » permet de préciser quel exécutable sera lancé
lors du lancement d’un conteneur à partir de l’image.
● Vous pouvez préciser des paramètres pour cette instruction.
● L’instruction « CMD » permet de préciser des paramètres par défaut qui seront
ajoutés après ceux de l’instruction « ENTRYPOINT ».

● Il est possible de fournir des paramètres au lancement d’un conteneur, dans ce

cas ceux- ci remplacent ceux fournis par l’instruction « CMD »:
docker run <image> param3 param4

46
 Mise en œuvre d'un conteneur.

Mise en œuvre d'un conteneur.

● La commande « docker push » permet de publier ses images sur le

DockerHub :
docker push <image_name>[:<tag>]
● Il faut préalablement s’authentifier auprès du DockerHub :
docker login

● A noter qu’il est également possible de publier une image sous forme d’un
archive tar :
docker save -o <fichier> <image>
● Une image sous forme d’une archive TAR peut ensuite être importée ailleurs :
docker load -i <fichier>

● Attention ces images archives incluent l’ensemble du contenu d’une image

(image de base récursivement par ex.  taille importante !)

47
 Conteneur hébergeant plusieurs services :
supervisor.

Conteneur hébergeant plusieurs services

● Le processus principal d’une image est précisé dans l’instruction

«ENTRYPOINT» de son Dockerfile.
● Il est conseillé d’avoir un seul service par conteneur pour séparer les
responsabilités (voire un seul processus pour les plus rigoristes).
● Le processus principal peut « forker » d’autres processus, mais il est
responsable de l’arrêt de ceux-ci lorsque le conteneur est fermé.
● Plusieurs possibilités existent pour gérer plusieurs services dans un conteneur :
● Regrouper les commandesde lancement dans un script (avec test que le service est bien lancé
et debug dans le cas contraire) et inclure le script comme point d’entrée du Dockerfile.

● Utiliser un gestionnaire de processus tel que « supervisord » qui managera les processus pour
vous (supervisord étant le point d’entré du Dockerfile »).

48
Supervisord (1/2)

● Supervisor est un processus de gestion de lancement d’autres processus.

● On installe préalablement les paquets nécessaires :
RUN apt-get update & apt-get –y install supervisor & apt-get …

● Supervisor se base sur un fichier de configuration « supervisord.conf » ayant la

forme suivante :
[supervisord]
nodaemon=true

[program:process1]
command=/path/to/exec -option

[program:process2]
command=/path/to/exec2 -option

Supervisord (2/2)

● On copie le fichier de configuration du contexte vers l’image :

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

● Supervisor sera le processus principal de notre image :

CMD ["/usr/bin/supervisord"]

● Celui-ci lance ensuite nos différents processus définis dans la configuration.

● Cette approche est critiquable si nos processus exposent plusieurs services à
l’extérieur (ex: php et mysql).
● Si un processus est exposé comme service et que les autres sont des
processus internes/ esclaves, on se conforme plus à l’esprit de Docker.

49
 METTREEN ŒUVRE
UNEAPPLICATION
MULTICONTENEUR

Mettre en œuvre une application multiconteneur

● Utilisations de Docker Compose.

● Installation de Docker Compose.

● Création d'un fichier YML de configuration.

● Déployer une application multiconteneur.

● Lier tous les conteneurs de l'application.

50
 Utilisations de Docker Compose.

Docker Compose.

● Docker Compose est un outil permettant de définir et d’exécuter des

applications Docker à conteneurs multiples.

● Avec Compose, vous utilisez un fichier YAML pour configurer les conteneurs de
votre application.
● Ensuite, avec une seule commande, vous créez et démarrez ceux-ci.
● Compose propose des commandes permettant de gérer l’ensemble du cycle
de vie de votre application:
● Démarrer, arrêter et reconstruire desconteneurs

● Afficher le statut des conteneursen coursd'exécution

● Diffuser la sortie du journal des conteneursen coursd'exécution

● Exécuter une commande unique sur un service

51
Fonctionnalités de Docker Compose.

● Les fonctionnalités de Docker Compose qui le rende intéressant sont :

● Plusieurs environnementsisolés sur un seul hôte différenciés par un nom de projet
(ex: par projet, par branches de code, par numéro de build, …).

● Préserver les donnéesde volume lorsque des conteneurssont créés

(les volumes de précédents runssont copiés pour les nouveaux).
● Recréer uniquement les conteneursqui ont changé
(car cache de la configuration  optimise le temps de recréation).
● Variables et déplacement d'une composition entre environnements
(supporte lesvariables  adaptation selon les environnementspossibles).

Cas d’usage de Docker Compose.

● Docker Compose peut être utilisé dans différents besoins:

● Environnementsde développement : le fichier de configurationpermet de mettre en place
facilement un environnement complet (l’applicationet ses dépendances).
Celui- ci est déployé avec une simple commande.

● Environnementsde tests automatisés : en quelquescommandes, on peut mettre en place un

environnement, lancer ses tests et détruire cet environnement.

● Déploiementssur une machine : on peut déployer sur un démon Docker distant.

● Déploiementssur plusieurs machines : on peut déployer sur un cluster de démon Docker.

52
 Installation de Docker Compose.

Installation de Docker Compose.

● Docker Compose est inclus dans Docker Desktop sur Windows et Max.
● Sous Linux, l’installation se fait séparément après celle du démon Docker.
● Téléchargez tout d’abord l’exécutable :
sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-
compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

● Donnez les droits d’exécution au fichier :

sudo chmod +x /usr/local/bin/docker-compose

● Testez l’installation :
docker-compose --version

53
 Création d'un fichier YML de configuration.

Fichier de configuration de Composer.

● Il existe plusieurs formats pour ce fichier de configuration :

Format Docker release
3.7  18.06.0+
3.6  18.02.0+
3.5  17.12.0+
…
● Le fichier de configuration est au format YAML situé par défaut à « ./docker-
compose.yml ».
● Celui peut se composer de 3 sections :
● « services» : les conteneurs

● « netw orks» : lesréseaux (si besoin avancé)

● « volumes » : les volumes (si besoin avancé)

54
Structure de base

● La première ligne du fichier de configuration désigne la version du format

utilisée :
version: "3.7"

● Généralement ensuite la section de définition des conteneurs :

services:
...

● Puis, si besoin, les sections de définition des volumes et réseaux :

volumes:
...
networks:
...

● Une indentation par multiple de 2 espaces caractérise la hiérarchie des

instructions de configuration.

Les conteneurs

● Au sein de la section « services », nous avons plusieurs définitions de

conteneurs identifiées par un nom :
services:
container_name1
:
..
container_name2:
..

● Ce nom identifiera le conteneur au sein de l’environnement d’application.

55
Les conteneurs : image

● Pour créer un conteneur, le plus simple est de se baser sur une image
disponible dans le DockerHub.
● Pour cela, on précise l’image avec la ligne « image » :
service:
container_name:
image: <repository>/<image_name>

Les conteneurs : build

● Pour créer un conteneur, il est aussi possible de construire une image à partir
d’un Dockerfile.
● Pour cela, le plus simple est de définir le dossier contenant le Dockerfile:
services:
container_name:
build: ./service_dir

● Pour des besoins plus poussés, « build » sera une section :

services:
container_name
:
build:
context: ./service_dir
dockerfile: Dockerfile-alternate
args:
arg1: value
arg2: value
...

56
Les conteneurs : command et entrypoint

● On peut remplacer la commande et le point d’entrée par défaut avec les lignes
« command » et « entrypoint »:
service:
container_name:
..
command: bundle exec thin -p 3000

// ou

command: ["exec", "thin", "-p", "3000"]

...
entrypoint: /code/entrypoint.sh

Les services : depends_on

● On peut préciser qu’un conteneur doit démarrer après un ou plusieurs autres

avec la ligne « depends_on » :
services:
web:
build: .
depends_on:
- db
- redis
redis:
image: redis
db:
image: postgres

57
 Les conteneurs : environnement et env_file

● On peut fournir des variables d’environnement aux conteneurs avec les lignes
« environnement » et « env_file »:
service:
container_name:
..
environnement:
ENV1: value1
ENV2: value2

// ou

env_files: .env

● Dans un fichier de variables d’environnement, les lignes ont le format suivant :

ENV1=value1

Les conteneurs : networks

● On peut préciser les réseaux qu’un conteneur doit rejoindre avec la ligne
« networks » :
services:
web:
networks:
- front
app-server:
networks:
- front
- back
db:
networks:
- back

● Dans ce cas, il faut déclarer le ou les réseaux dans la section « networks ».

58
Les conteneurs : ports

● On peut préciser quels ports réseaux on veut publier à l’extérieur de

l’environnement d’application (c.a.d. visible depuis l’hôte) avec la ligne
« ports » :
services:
web:
ports:
- "80:80"
- "8080:81"
- "6060:6060/udp"

● Le 1erchiffre est le port visible à l’extérieur, le 2ème est le port d’écoute du

conteneur, visible à l’intérieur de l’environnement d’application.

Les conteneurs : volumes

● On peut monter des volumes et des « bind mounts » pour chaque conteneur
avec la ligne « volumes » :
services:
web:
volumes:
- datavolume:/var/lib/mysql (volume nommée)
- /var/lib/mysql (volume créé auto...)
- /opt/data:/var/lib/mysql (bind mount)
- ~/configs:/etc/configs/:ro (bind mount read-only)

● Pour des besoins avancés, les volumes peuvent être l’objet d’une section
propre.

59
Les conteneurs : restart

● Par défaut les conteneurs ne sont jamais redémarrés en cas de soucis.

● Avec la ligne « restart », on peut changer ce comportement :
● "no" : comportement par défaut.

● always : les conteneurssont toujours redémarrés. Si stoppésmanuellement, ils sont

redémarréslorsque le démon Docker est redémarré.
● on-failure : les conteneurssont redémarréss’ils se sont terminés avec un code d’erreur
(!= 0).

● unless-stopped : similaire à « always » sauf que le conteneur n’est pas redémarré lorsque le
démonDocker est redémarré.

● Il faut que le service soit « up » au moins 10 secondes que la politique de

redémarrage soit prise en compte (pour éviter une boucle de redémarrage).

Les réseaux

● Les réseaux sont déclarés au sein de la section « networks » :

networks:
network-name1:
…
network-name2:
…

● Pour chaque réseau, le point essentiel est le type de réseau choisi, définissable
avec la ligne « driver », par exemple :
networks:
some-network:
driver: bridge

60
 Déployer une application
multiconteneur.

Déployer une application multiconteneur (1/2)

● L’exécutable « docker-compose » permet de mettre en œuvre un

environnement en se basant sur un fichier « docker-compose.yml ».
● La syntaxe de cet exécutable est le suivant :
docker-compose [-f <arg>...] [options] [COMMAND] [ARGS...]

● Les principales commandes sont :

● up : pour créer et démarrer les conteneurs

● down : pour arrêter et supprimer les conteneurs et réseaux, images et volumes associés

● start : pour démarrer les conteneurs

● stop : pour stopper les conteneurs

● pause : pour mettre en pause les conteneurs

● unpause : pour arrêter la mise en pause des conteneurs

● ps : pour lister les conteneurs

61
Déployer une application multiconteneur (2/2)

● Les 2 principales options sont :

● -f : pour préciser un fichier Dockerfile (si celui-ci est situé dans un dossier différent ou à un nom différent)

● -p : pour préciser un nom de projet (si différent du nom du dossier)

Lier tous les conteneurs de l'application.

62
Lier tous les conteneurs de l'application

● Tous les conteneurs lancés par docker-compose et attachés au même réseau

peuvent se voir les uns les autres (si les ports sont exposés).

● Pour rendre cela possible, le nom de chaque conteneur sera utilisé comme
nom d’hôte au sein de ce réseau et sera référencé auprès des autres.
● Pour lier un conteneur à un autre (dans le même réseau), il suffit généralement
de fournir le nom d’hôte du conteneur à consommer au conteneur qui doit le
consommer via une variable d’environnement.
wordpress: db:
image: wordpress image: mysql:5.7
restart: always restart: always
ports: environment:
- 8080:80 MYSQL_DATABASE: exampledb
environment: MYSQL_USER: exampleuser
WORDPRESS_DB_HOST: db MYSQL_PASSWORD: examplepass
... MYSQL_RANDOM_ROOT_PASSWORD: '1'

INTERFACES
D'ADMINISTRATION

63
Interfaces d'administration

● L'API Docker et les W eb Services.

● Interfaces graphiques d'administration.

● Héberger son propre registre : Docker Registry, Gitlab-CE...

L'API Docker et les W eb Services.

64
L'API Docker et les W eb Services

● Le démon Docker expose une API qui est utilisée par le client Docker ainsi que
par les SDKs.
● Par défaut, le démon Docker Linux écoute uniquement sur le socket UNIX
« /var/run/docker.sock ».
● Pour exposer celui- ci en HTTP, il faut « overrider » son service :
sudo systemctl edit docker.service

● Puis, dans le fichier ouvert, ajouter les lignes suivantes :

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://127.0.0.1:2375

● Puis, recharger la configuration systemctl et relancer le démon Docker :

sudo systemctl daemon-reload
sudo systemctl restart docker.service

L'API Docker et les W eb Services

● L’API est au format REST

● Utilisation des méthodes HTTP : GETpour lire, POST pour créer/mettre àjour, DELETEpour
supprimer.

● Retour au format JSON

● L’API permet de gérer :

● Les conteneurs : / containers/ …
● Les images : / images/ …
● Les réseaux : / networks/ …
● Les volumes : / volumes/ …
● …

65
 Interfaces graphiques d'administration.

Interface graphiques d'administration

● Docker a proposé via Docker Toolbox une interface d’administration en

mode desktop : Kinematic mais celle-ci n’est plus maintenue par Docker.

66
Interface graphiques d'administration

● Beaucoup d’autres outils en mode web sont proposés par des sociétés /
communautés tiers :
● Portainer : permet de gérer conteneurs Docker, images, volumes, réseaux, etc…
Distribué sous forme d’une image Docker. Gère Docker Engine et Docker Swarm.

● DockStation: permet de gérer conteneurs Docker et Docker Compose…

Distribué sous forme d’application Windows, Mac, Linux

● Rancher: permet de gérer Docker et Kubernetes.

Distribué sous forme d’une image Docker.

● ...

Héberger son propre registre :

Docker Registry, Gitlab- CE...

67
Héberger son propre registre

● Pour publier ses images dans son propre registre privé, il y a plusieurs
possibilités :
● DockerHub : en payant, on peut héberger plus d’une image privée avec une
interface web permettant de gérer équipes et repository.

● Docker Registry : une application serveur sans état qui vous permet de stocker et
de distribuer vos images.

● Docker Trusted Registry : fait partie de Docker Entreprise, permet en plus : LDAP,
signature des images, scan de sécurité, …

● Des services web tiers, telque Gitlab, vous permettant de stocker et de distribuer
vos images.

Docker Registry (1/ 3)

● Pour mettre en œuvre son propre registre avec Docker Registry, il suffit de lancer
l’image Docker correspondante :
docker run -d -p 5000:5000 --name registry registry

● Pour construire une image, il faut préciser le registre pour le pousser ensuite :
docker build –t localhost:5000/myfirstimage
docker push localhost:5000/myfirstimage

● Pour récupérer une image :

docker pull localhost:5000/myfirstimage

● Pour arrêter son registre :

docker container stop registry && docker container rm -v registry

68
Docker Registry (2/ 3)

● Par défaut, le Registry stocke ses données dans un volume Docker. Pour faire un
« bind mount », rajoutez par exemple le paramètre :
-v /mnt/registry:/var/lib/registry

● On crypte les communications avec le registre à l’aide d’un certificat TLS via les
paramètres :
-v "$(pwd)"/certs:/certs
-e REGISTRY_HTTP_ADDR=0.0.0.0:443
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt
-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key

Docker Registry (3/ 3)

● L’accès au registre peut être sécurisé par :

● Un fichier « htpasswd » Apache que l’on copiera dans le conteneur au lancement
(format « bcrypt » seulement).

● Des tokens générés par un système d’authentification externe.

69
 ADMINISTRERDES
CONTENEURSEN PRODUCTION

Administrer des conteneurs en production

● Automatiser le démarrage des conteneurs au boot.

● Gérer les ressources affectées aux conteneurs.

● Gestion des logs des conteneurs.

● Sauvegardes : quels outils et quelle stratégie ?

70
 Automatiser le démarrage
des conteneurs au boot.

Automatiser le démarrage des conteneurs au boot

● Pour lancer des conteneurs au boot, il faut tout d’abord s’assurer que le démon
Docker soit lancé au boot (enabled) :
systemctl list-unit-files | grep docker
● Si ce n’est pas le cas, activez-le :
systemctl enable docker

● Pour que des conteneurs soient lancés au boot, il y a plusieurs possibilités :

● Se baser sur les politiques de redémarrage de Docker (docker run –restart …)
● Utiliser un gestionnaire de processus externe tel que upstart, systemd ou supervisor

71
 Gérer les ressources affectées
aux conteneurs

Gérer les ressources affectées aux conteneurs

● Par défaut, un conteneur n’a pas de contraintes d’accès aux ressources et peut
donc utiliser autant de ressources que le noyau Linux lui permet.
● Il est possible de limiter :
● La mémoire utilisée
● Les cycles CPU utilisés

72
Out Of Memory Exception (1/2)

● Il est important de ne pas permettre à un conteneur en cours de consommer

trop de mémoire de la machine hôte.
● Sur les hôtes Linux, si le noyau détecte qu'il n'y a pas assez de mémoire pour
exécuter des fonctions système importantes, il déclenche une Out Of Memory
Exception et commence à supprimer des processus pour libérer de la
mémoire.
● Tout processus est sujet à être tué, y compris Docker et d’autres applications
importantes.
● Docker tente d'atténuer ces risques en ajustant la priorité de OOM sur le
démon Docker afin qu'il soit moins susceptible d'être tué que d'autres
processus.
● La priorité du OOM sur les conteneurs n'est pas ajustée  kill plus probable.

Out Of Memory Exception (2/2)

● Vous pouvez réduire les risques dûs aux OOME en :

● Effectuant des tests pour comprendre les besoins en mémoire des conteneurs
avant de les mettre en production.

● S’assurant que les conteneurs ne s'exécutent que sur des hôtes disposant de
ressources suffisantes.
● Limitant la quantité de mémoire que les conteneurs peuvent utiliser.
● Soyez averti lors de la configuration du swap sur vos hôtes Docker :
Le swap est plus lent et moins performant que la mémoire, mais peut fournir
une mémoire tampon contre le manque de mémoire système.

73
Limiter la mémoire

● Les limites de mémoires sont exprimées sous forme d’entier, suivi d’une lettre:
b, k, m, g (octet, kilo- octet, mega- octet, giga- octet)
● L’option « -m » ou « --memory » permet de définir le maximum de mémoire
utilisable par un conteneur (mini : 4m).
● L’option « --memory-swap » permet de définir la taille maximum de swap.
Le chiffre est exprimé mémoire incluse. (non définie : x3, 0: pas de swap, -1:
swap illimité).
● L’option « --memory-reservation » permet de définir une limite logicielle
de mémoire plus faible que « --memory ». Cette dernière servant de filet de
sécurité dans ce cas.
● L’option « --kernel-memory » permet de définir le maximum de
« kernel memory » utilisable par un conteneur (mini : 4m).

Limiter le CPU

● L’option « --cpus » permet de définir le nombre de cœurs utilisables par un

conteneur (virgule utilisable, ex: 1.5 pour un cœur et demi).
● L’option « --cpuset-cpus » permet de désigner les cœurs utilisables par un
conteneur :
● 0 le 1er, 1le 2ème, etc.
● 0 - 3 le 1er, le 2ème, le 3ème et le 4ème.
● 1,3 le 2ème et le 4ème.
● L’option « --cpu-shares » permet de définir la priorité d’un conteneur
d’obtenir des cycles CPU en cas de contention (défaut: 1024, >1024 : plus
prioritaire, <10 24 : moins prioritaire)

74
 Gestion des logs des conteneurs

Consulter les logs d’un conteneur

● Si on lance un conteneur sans le détacher de la console, ses logs apparaissent

dans celle-ci.
● Sinon la commande « logs » permet de voir les log d’un conteneur :
docker logs [OPTIONS] <container_name>

● Si vous ne voyez rien, il se peut que le processus écrive ses logs autre part
que dans STDIN et STDERR.
● Quelques options utiles :
● --since : pour afficher le contenu du log depuis une date donnée

● --until : pour afficher le contenu du log jusqu’à une date donnée

● - - tail : pour préciser le nombre de lignes à afficher

75
Configurer les logs (1/ 2)

● Docker inclut plusieurs mécanismes ou « drivers » de log.

● Chaque démon Docker a un driver de log par défaut que chaque conteneur
utilise sauf si vous le configurez pour utiliser un driver différent.
● Outre l'utilisation des drivers fournis avec Docker, vous pouvez également
implémenter et utiliser des plug-ins de drivers tiers.
● Pour configurer le démon Docker afin qu’il utilise un driver spécifique par
défaut, il suffit de définir le champ « log-driver » dans le fichier de
configuration « daemon.json » situé :
● Pour Linux dans « /etc/docker »
● Pour W indows Server dans « C:\ProgramData\docker\config\ »

Configurer les logs (2/ 2)

● Si le driver choisi à des options de configuration, vous pouvez les fournir via le
champ « log- opts » :
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3",
"labels": "production_status",
"env": "os,customer"
}
}

● Si le driver n’est pas spécifié, le driver par défaut est « json-file ».

● Pour trouver le driver par défaut d’un démon docker, lancez la commande
« docker info » et cherchez « Logging Driver ».
● Pour configurer le driver de log d’un conteneur, utilisez l’option « --log-
driver » et si besoin l’option « --log-opt » pour les options du driver.

76
Les drivers de log

● Les drivers de log suivant sont supportés:

● none : pas de log

● local : les logs sont stockés en fichiers dans un format interne optimisé pour la performance.

● json-file : les logs sont stockés sous forme de fichiers JSON

● syslog : les logs sont envoyés à un démon syslog

● journald : les logs sont envoyés au démon journald

● gelf : les logs sont envoyés à une destination GELF tel que Graylog ou Logstash

● fluentd : les logs sont envoyés à un démon fluentd

● awslogs : les logs sont envoyés vers Amazon CloudW atch Logs

● gcplogs : les logs sont envoyés vers Google Cloud Platform Logging

● logentries : les logs sont envoyés vers Rapid7 Logentries

● splunk, etwlogs

Log driver « local »

● Le driver « local » capture les sorties de STDOUT/ STDERRdes conteneurs et

les écrit sur un stockage interne optimisé pour la performance et l’utilisation
du disque.
● Par défaut, le driver garde 100Mo de log par conteneur (sous forme de
plusieurs fichiers en rotation) avec compression pour économiser de l’espace
disque.
● Les options du driver :
● max-size : la taille maximum d’un fichier (défaut : 20m)
● max-file : le nombre maxi de fichier (défaut : 5)
● compress : active la compression (défaut : true)

77
Log driver « json- file »

● Le driver « json-file » capture les sorties de STDOUT/ STDERRdes conteneurs

et les écrit dans des fichiers JSON par conteneur en ajoutant le timestamp.
● Les principales options du driver :
● max-size : la taille maximum d’un fichier (défaut : -1 c.a.d. illimité)
● max-file : le nombre maxi de fichier (défaut : 1)
● compress : active la compression (défaut : false)
● …

Log driver « journald »

● Le driver « journald » envoie les logs au démon « journald ». Les logs peuvent
être lus ensuite via les commandes « journalctl » ou « docker logs ».
● En plus du message, le driver ajoute des métadonnées au journal :
● CONTAINER_ID : l’id du conteneur tronqué à 12 caractères.
● CONTAINER_ID_FULL : l’id complet du conteneur.
● CONTAINER_NAME : le nom du conteneur.

78
 Sauvegardes :
quels outils et quelle stratégie ?

Sauvegardes : quels outils et quelle stratégie ?

● La sauvegarde des données dans Docker dépend des cas :

● Sauvegarder les changementsd’un conteneur

● Sauvegarderles donnéesexternesau conteneur (volumes, bind mount, …)

● Sauvegarderles donnéesvia les outils du fournisseur des service

79
Sauvegarder les changements d’un conteneur

● La commande « docker commit » permet de :

● Sauvegarder l’état d’un conteneur en créant une nouvelle image

● Cette nouvelle image peut être redémarrée en l’état

● Cette nouvelle image peut être « backup » en tar.gz via la commande :

docker save myimage:latest | gzip > myimage_latest.tar.gz

● Il est également possible de sauvegarder le système de fichier d’un conteneur :

docker export myimage:latest | gzip > myimage_latest.tar.gz

● Ces solutions ne sont pas prévues pour sauvegarder des données :

● Les « volumes » et « bind mount » ne font pas partie des sauvegardes

● Fonctionnement « binaire » (sauvegarde/ restauration : pas d’incrémental)

Sauvegarder les données externes au conteneur

● La sauvegarde des données dans un « volume » ou dans un « bind mount » peut

se faire via des outils de backup standard (rsync, borg, …) :
● Il suffit de sauvegarder les dossiersconcernés
● Si vous n’avez pas accèsau dossier du volume, vouspouvez lancer un nouveau conteneur qui
monte le volume et lancer la commande de sauvegardedans celui-ci.

● Ces solutions demandent généralement un arrêt du service pour avoir une

sauvegarde cohérente.
● Il existe d’autres technologies de stockages externes basées sur des plugins
tiers. En fonction des cas, des solutions de backup sans interruption peuvent
exister.

80
Sauvegarder les données via les outils du fournisseurs de service

● Les fournisseurs de services, en particulier les fournisseurs de bases de

données prévoient des outils ou architectures pour faire des backups.

● Ces sauvegardes plus « applicatives » que « fichiers » peuvent permettre de

faire des sauvegardes sans interruption.
● Dans ce cas, on peut lancer dans le conteneur une commande de sauvegarde
via la commande :
docker exec <container-name> <command> [args...]

ORCHESTRATION ET
CLUSTÉRISATION

81
Orchestration et clustérisation

● Présentation de Docker Machine.

● L'orchestrateur Swarm : nodes, services, secrets, configs.

● Déploiement de services et stacks dans un Sw arm.

● Reverse-proxy et load-balancer pour Web Services en cluster (Traefik...).

Présentation de Docker Machine

82
Présentation de Docker Machine (1/3)

● Docker Machine est un outil qui vous permet d'installer le démon Docker sur
des hôtes virtuels et de gérer les hôtes à l'aide de commandes « docker-
machine ».
● Vous pouvez l’utiliser pour créer des hôtes Docker sur votre ordinateur Mac ou
Windows, sur le réseau de votre entreprise, dans votre centre de données ou
sur des fournisseurs de cloud, tels qu'Azure, AW S , ...
● À l'aide des commandes « docker-machine », vous pouvez démarrer,
inspecter, arrêter et redémarrer un hôte géré, mettre à niveau le client et le
démon Docker et configurer un client Docker pour qu'il puisse communiquer
avec votre hôte.
● Docker Machine était le seul moyen d’exécuter Docker sur Mac ou Windows
avant la version 1.12

Présentation de Docker Machine (2/3)

● Depuis la version 1.12 (au départ sous forme de beta), Docker Desktop pour
Mac et Docker Desktop pour Windows sont disponibles en tant qu'applications
natives et constituent un meilleur choix.
● Ces installeurs incluent le démon docker, le client Docker, Docker Compose,
Docker Machine, …
● Les machines virtuelles provisionnées par Docker Machine ont le démon
Docker pré-installé et peuvent donc être manipulés par Docker Machine.
● Exemple pour créer une machine dans VitualBox :
docker-machine create --driver virtualbox machine1

● Exemple pour créer une machine sur Azure :

docker-machine create --driver azure --azure-subscription-
id="***" --azure-subscription-cert="mycert.pem" machine2

83
Présentation de Docker Machine (3/3)

● Pour lister les machines :

docker-machine ls

● Pour arrêter une machine :

docker-machine stop machine1

● Pour lancer une machine :

docker-machine start machine2

● Une fois une machine lancée, les commandes Docker lancé sur l’hôte sont
exécutées sur cette dernière.
● La technologie Docker Machine est considéré obsolète par Docker lui-même et
même plus en avant « Docker Sw arm ».

L'orchestrateur Swarm :
nodes, services, secrets, configs

84
L'orchestrateur Swarm (1/3)

● L’orchestrateur « Swarm » (dénommé également « Swarm Mode ») est intégré

nativement au démon Docker.
● Grace au client Docker, on peut créer un « swarm » c’est-à-dire un cluster de
nœuds ayant le démon Docker, y déployer des applications et manager le
comportement du « sw arm ».
● Au lieu de gérer la différenciation entre les rôles des nœuds au moment du
déploiement, le moteur Docker gère la spécialisation au moment de
l'exécution.
● Une approche déclarative est utilisée pour permettre de définir l'état souhaité
des différents services de votre pile d'applications (ex: un service frontal web,
un service fil de message et un service base de données).

L'orchestrateur Swarm (2/3)

● Pour chaque service, on peut déclarer le nombre de tâches que l’on veut lancer
(c.a.d. le nombre de conteneur). Avec le « manager » du swarm, on peut
redimensionner le service (c.a.d. ajouter des tâches ou en supprimer).
● Le manager s’assure que l’état du swarm correspond à l’état que vous avez
demandé (c.a.d. si 2 taches d’un service crashent, le manager créera 2
nouvelles tâches).
● Les communications entre les services passent par un réseau « overlay »
(réseau virtuel regroupant plusieurs nœuds physiques). Le manager assigne
automatiquement aux conteneurs des adresses IP.
● Le manager assigne à chaque service un nom DNS unique et load-balance
entre les différents conteneurs (tâches) du service.

85
L'orchestrateur Swarm (3/3)

● On peut exposer les ports de certains services, à l’extérieur du swarm, à

destination d’un load-balancer externe.
● Les nœuds du swarm s’authentifient mutuellement (TLS) et les
communications sont cryptées entre elles (certificats auto-signés ou d’une
autorité de certification).
● On peut faire des « rolling update » de service au sein d’un swarm. Le manager
vous laisse décider du délai entre chaque déploiement. S’il y a un problème, on
peut également revenir en arrière.

Swarm (1/2)

● Un swarm est composé de plusieurs hôtes Docker qui fonctionnent en « mode

swarm ».

● Ces nœuds peuvent être des « managers » (qui gèrent les membres et la
délégation de services) ou des « workers » (qui exécutent les services).
● Un hôte Docker peut être un « manager », un « worker » ou les 2.
● Lorsque que l’on crée un service, on définit son état optimal (nombre de
répliques, ressources réseau et de stockage qui lui sont attachés, les ports
exposés à l’extérieur du sw arm).
● Le manager va s’efforcer de maintenir cet état optimal.

86
Swarm (2/2)

● L'un des principaux avantages par rapport aux conteneurs autonomes est que
vous pouvez modifier la configuration d'un service sans qu'il soit nécessaire de
redémarrer manuellement.
● Pour cela, Docker met à jour la configuration, arrête les tâches et en crée de
nouvelles avec la nouvelle configuration de service.
● De la même manière que l’on utilise Docker Compose pour déployer plusieurs
conteneurs sur un hôte Docker, on peut définir des piles applicatives (« service
stacks ») et les déployer dans un cluster swarm.

Nodes

● Un nœud (« node ») est une instance de démon Docker participant à un swarm.

● On peut lancer un ou plusieurs nœuds sur une machine physique ou virtuelle,
mais, en production, on répartira ces nœuds sur plusieurs machines
différentes.
● Pour déployer un application dans un swarm, on soumet une définition de
service à un nœud « manager » qui va répartir les taches (« tasks ») sur les
nœuds « w orker ».
● Les nœuds « manager » élisent un leader qui conduira l’orchestration.
● Les workers reçoivent leurs tâches des managers et les exécutent. Ils informent
les managers de l’état de leurs tâches afin que ceux-ci puissent maintenir l’état
optimal des services.

87
Services & tasks

● Un service est une définition de tâches (« tasks ») devant s’exécuter sur les
nœuds.

● Lorsque vous créez un service, vous spécifiez quelle image utiliser et quelles
commandes exécuter dans les conteneurs.
● Les services « répliqués » sont distribués sous forme de tâches aux nœuds (le
nombre de tâches dépend de l’optimal que vous avez défini).
● Pour les services « globaux », une tâche du même service est exécutée sur
chaque nœud du cluster.
● Une tâche (« task ») est l’unité de travail atomique dans le cluster. Une tâche est
assignée à un nœud, elle ne peut pas être migrée sur un autre nœud.

Load balancing

● Le sw arm load- balance les requêtes arrivant de l’extérieur.

● Le manager peut assigner automatiquement un « PublishedPort » à un service
ou vous pouvez le configurer vous-même.
● Les éléments externes peuvent accéder aux services via leur « PublishPort » sur
n’importe quel nœud du swarm, même si celui-ci n’exécute pas une tâche
correspondante (les nœuds peuvent retransmettre les requêtes aux « bons »
nœuds).
● A l’intérieur du swarm, chaque service se voit affecter une entrée DNS.
● Les requêtes internes sont également load-balancées via ces entrées DNS.

88
Secret (>1.13)

● Un « secret » est un bloc de données, tel que mot de passe, clé privée SSH,
certificat SSL, etc. qui ne doit pas être transmis en clair sur le réseau ni stocké
en clair dans un Dockerfile ou dans le code de ses applications.
● Les secrets sont stockés et transmis cryptés dans un swarm.
● Un secret donné est accessible uniquement aux services auxquels un accès
explicite à celui-ci a été accordé et uniquement quand les tâches de ce service
sont en exécution.
● Une autre utilisation possible des « secrets » est de fournir une couche
d’abstraction entre une application et sa configuration.
● Dans ce cas, on peut publier sous le même nom de secret, une configuration
différente pour des swarms « dev », « recette », « production », … l’application
n’a ainsi qu’a connaitre le nom du « secret ».

Config (>= 17.0 6)

● Les « configs » permettent de stocker des informations non sensibles, telles

que des fichiers de configuration en dehors des images ou des conteneurs.
● Cela permet de garder ses images aussi génériques de possible, de ne pas
avoir besoin de monter des fichiers de configurations dans les conteneurs ou
d’utiliser des variables d’environnements.
● Les « configs » sont similaires aux « secrets » à ceci près qu’elles ne sont pas
cryptés et sont montées directement dans les systèmes de fichiers des
conteneurs sans passer par des disques RAM.
● Les « configs » peuvent être ajoutées ou enlevées aux services à tout moment.
Les services peuvent partager une « config ».
● Les données dans une « config » sont des chaînes de caractères (ou 500ko
max de binaire).

89
 Déploiement de services et stacks
dans un Swarm

Création du swarm

● Sur la machine destinée à être le « manager », on initie le mode « swarm » via

la commande :
docker swarm init --advertise-addr <MANAGER-IP>

● L’option « advertise-addr » permet de préciser l’adresse IP du manager qui

sera publiée à destination des autres nœuds du swarm (si la machine n’a
qu’une adresse IP, l’option peut être omise).
● La commande « docker info » permet de savoir si la machine fait partie
d’un swarm :
Swarm: inactive  Swarm: active

90
Ajouter des nœuds au swarm

● Sur le manager, on demande un token pour ajouter un worker ou un autre

manager au swarm :
docker swarm join-token(worker|manager)

● Sur la machine que l’on veut ajouter au swarm, on exécute la commande :

docker swarm join --token <token> <advertise-addr>:2377

● Sur le manager, la commande « docker node ls » permet de connaitre la

composition du swarm.
ID HOSTNAME STATUS AVAILABILITY MANAGER
STATUS
03g1y59jwfg7cf99w4lt0f662 worker2 Ready Active
9j68exjopxe7wfl6yuxml7a7j worker1 Ready Active
dxn1zf6l61qsb1josjja83ngz * manager1 Ready Active Leader

Déployer des services dans le swarm

● Sur le manager, on déploie des services sur le swarm via la commande :

docker service create --replicas <nombre-taches> --name <nom-
service> <image> [<commande>]

● La commande « docker service ls » permet de lister les services

déployés sur le swarm.
ID NAME SCALE IMAGE COMMAND
9uk4639qpg7n <nom-service> 1/1 <image> <commande>

● Pour afficher le détail d’un service :

docker service inspect --pretty <nom-service>

● Pour savoir quels sont les nœuds sur lesquels un service tourne :
docker service ps <nom-service>

● Pour changer le nombre de tâches d’un service :

docker service scale <nom-service>=<nombre-taches>

91
Déployer des stacks dans un swarm

● Les « stacks » sont des piles applicatives que l’on déploie dans un swarm.
● Celles-ci sont décrites dans un fichier « docker-compose.yml » avec pour chaque
service une sous- section « deploy » :
version: "3.7"
services:
db:
image: <image-name>
deploy:
mode: global|replicated
replicas: <nombre-taches>
...
● Les « stacks » sont déployées avec la commande :
docker stack deploy --compose-file docker-compose.yml <stack-name>

Reverse-proxy et load-balancer pour

W eb Services en cluster (Traefik...)

92
Reverse-proxy et load-balancer

● Un proxy inverse (reverse proxy) est un type de serveur, habituellement placé en

frontal de serveurs web. Il permet à un utilisateur d'Internet d'accéder à des
serveurs internes.
● Cette technique permet :
● Mémoire cache: le proxy inverse peut décharger les serveurs Web de la charge de pages/objets
statiques (pages HTML, images) par la gestion d'un cache web local.
● Intermédiaire de sécurité: le proxy inverse permet de protéger un serveur Web des attaques
provenant de l'extérieur, surtout en filtrant en un point unique des accès aux ressources Web.

● Chiffrement SSL: le proxy inverse peut être utilisé pour la mise en place de cryptage.
● Répartition de charge: le proxy inverse peut distribuer la charge d'un site unique sur plusieurs
serveurs Web applicatifs.

● Compression: le proxy inverse peut optimiser la compression du contenudes sites.

Traefik

● Traefik est un proxy inverse HTTP et un équilibreur de charge conçu pour le

déploiement de microservices.
● Traefik s'intègre aux composants d'infrastructure existants (Docker, mode Swarm,
Kubernetes,...) et se configure automatiquement et dynamiquement.
● La plupart du temps, pointer Traefik sur son orchestrateur suffit pour le configurer.
● Ses fonctionnalités :
● Met à jour sa configuration automatiquement

● Prend en charge plusieurs algorithmes d'équilibrage de charge

● Fournit HTTPS à vos micro-services en utilisant Let's Encrypt (prise en charge des certificats génériques)

● Interface Web de gestion

● Prêt pour W ebsocket, HTTP/ 2, …

● Conserve les journaux d'accès (JSON, CLF)

93
Traefik : Concepts (1/ 2)

● Imaginons que nous voulions définir les règles suivantes :

● api.domain.com  service « api »

● domain.com/ w eb  service « w eb »

● backoffice.domain.com  services « backoffice»load-balancés

Traefik : Concepts (2/ 2)

● Les concepts de Traefik sont :

● Les « entrypoints» qui sont les points d’entrée qui reçoivent les requêtesweb

● Les « frontends» qui associentles « entrypoints» aux « backends » suivant diverses règles.

● Les « backends» qui load-balancent le traffic vers un ou plusieurs services web.

94
Traefik : mise en place simple

● Créons un fichier de configuration « traefik.toml » :

###############################################################
#
# API and dashboard configuration
###############################################################
#
[api]
###############################################################
#
# Docker configuration backend
###############################################################
#
[docker]
domain = "docker.local"
watch = true
swarmMode = false|true

● Lançons Traefik sous forme de conteneur Docker :

docker run -d -p 8080:8080 -p 80:80
-v $PWD/traefik.toml:/etc/traefik/traefik.toml
-v
/var/run/docker.sock:/var/run/docker.sock
traefik

95