Conteneurisation

M41 : Virtualisation et Cloud
Computing
Dr. Hind IDRISSI
4. Conteneurisation
Email: h.idrissi@usms.ma
IRIC (S2)
2022 / 2023
PR. H.IDRISSI, ENSAK 2023 1

PLAN
1. Introduction à la Conteneurisation
2. Virtualisation Vs. Conteneurisation
3. Les Fondations Linux : Chroot, Cgroups, Namespace
4. Avantages et Inconvénients
5. Outils de Conteneurisation : LXC, Docker
6. Kubernetes
PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 2

1 . Introduction à la Conteneurisation

Les conteneurs logiciels cherchent à répondre à la même problématique que les conteneurs physiques
aussi appelés conteneurs intermodaux, ces grandes boîtes de métal standardisées qui transportent de
nos jours l’essentiel des biens matériels par camion, train, avion ou bateau.
Les avantages du transport par conteneur intermodal sont liés à ce que les Anglo-Saxons nomment
separation of concerns (en français ségrégation des problèmes ou ségrégation des responsabilités).

 Les transporteurs délèguent à leurs clients le remplissage du conteneur qui est ensuite scellé avant le
transport. De ce fait, le transporteur n’a pas à s’occuper de la nature précise des biens transportés. Il
doit s’assurer que le conteneur dans son ensemble arrive intact. Il assure donc la traçabilité d’un objet
dont les caractéristiques physiques sont standardisées. Il peut les empiler, choisir le mode de transport
adapté à la destination, optimiser les coûts et la logistique.
 La personne ou l’entreprise cliente a de son côté la garantie, pour peu que le conteneur ne soit pas
perdu ou ouvert, que ses biens arriveront dans le même état et arrangement que lors du chargement.
Le client n’a donc pas à se soucier de l’infrastructure de transport.
 Cette séparation des responsabilités est à l’origine de la baisse drastique des coûts du transport de
marchandises. Grâce à la standardisation et à l’automatisation qu’elle rend possible, les infrastructures
de transport se sont mécanisées, automatisées et donc fiabilisées.

 Le monde informatique reste profondément organisé autour de l’aspect artisanal de la livraison du

produit logiciel. De très nombreux incidents survenant au cours du cycle de vie d’un
logiciel sont liés à cette problématique.
Séparation des responsabilités dans une architecture à conteneurs
La technologie des conteneurs logiciels cherche à résoudre cette problématique.

Qu'est-ce que la conteneurisation ?
Il s'agit d'une forme de virtualisation du système d'exploitation dans laquelle vous exécutez des
applications dans des espaces utilisateurs isolés appelés conteneurs qui utilisent le même système
d'exploitation partagé.
 La conteneurisation permet de réduire les charges au démarrage et de supprimer la nécessité de

configurer des systèmes d'exploitation invités distincts pour chaque application, car ils partagent
tous un seul noyau de système d'exploitation.
 En raison de cette efficacité élevée, les développeurs de logiciels utilisent couramment la

conteneurisation des applications pour regrouper plusieurs micro-services individuels constituant les
applications modernes.

Qu'est-ce que la conteneurisation ?
Un conteneur d'applications est un environnement informatique entièrement regroupé en package et

portable :
o Il dispose de tout ce dont une application a besoin pour s'exécuter : fichiers binaires, bibliothèques,
dépendances et fichiers de configuration, le tout encapsulé et isolé dans un conteneur.
o La conteneurisation d'une application permet d'isoler le conteneur du système d'exploitation hôte,

avec un accès limité aux ressources sous-jacentes, à l'instar d'une machine virtuelle légère.
o Vous pouvez exécuter l'application conteneurisée sur différents types d'infrastructure, tels qu'un
serveur bare-metal, dans le cloud ou sur des VM, sans la remanier pour chaque environnement.

À quoi sert la conteneurisation ?
 La conteneurisation permet aux développeurs de logiciels de créer et de déployer des applications de

façon plus rapide et plus sécurisée.
 Avec les méthodes traditionnelles, vous codez dans un environnement informatique spécifique, ce qui
entraîne souvent des erreurs et des bogues lorsque vous transférez ce code dans un nouvel emplacement. Par
exemple, lorsque vous transférez du code de votre ordinateur de bureau vers une machine virtuelle, ou d'un
système d'exploitation Windows vers Linux.
 La conteneurisation élimine ce problème en vous permettant de regrouper le code de la demande avec les
fichiers de configuration, les dépendances et les bibliothèques associées. Vous pouvez ensuite isoler ce
package de logiciels unique (conteneur) du système d'exploitation hôte, ce qui lui permet d'être autonome et
de devenir portable, c'est-à-dire de s'exécuter sur n'importe quelle plate-forme ou n'importe quel cloud sans
aucun problème.

À quoi sert la conteneurisation ?
 Pour faire simple, la conteneurisation permet aux développeurs d'écrire des applications une seule fois
et de les exécuter partout. Ce niveau de portabilité est essentiel pour développer la compatibilité des
processus et des fournisseurs. Elle présente également d'autres avantages, comme l'isolation des
pannes, la sécurité et la facilité de gestion.
 L'industrie qualifie souvent les conteneurs de légers, ce qui signifie qu'ils partagent le noyau du système
d'exploitation de la machine et ne nécessitent pas l'association d'un système d'exploitation à chaque application,
comme c'est le cas avec la virtualisation.
 Par conséquent, les conteneurs ont une capacité intrinsèquement plus petite qu'une machine virtuelle et
nécessitent moins de temps de démarrage, ce qui permet l'exécution de plus de conteneurs sur une seule capacité
de calcul en tant que machine virtuelle unique. Ainsi, l'efficacité des serveurs est augmentée et les coûts des
serveurs et des licences sont réduits.

Historique ?
- 1979 : Unix V7 chroot

- 2000 : FreeBSD Jails
- 2001 : LinuxVServer
- 2004 : Solaris Containers
- 2005 : OpenVZ
- 2006 : cgroups
- 2008 : namespaces
- 2008 : LXC
- 2011 : Warden (Cloudfoundry)
- 2013 : Lmctfy (google)
- 2013 : Docker

2 . Conteneurisation Vs. Virtualisation

Pourquoi la conteneurisation est-elle nécessaire maintenant ?
 La conteneurisation est devenue le dernier mot à la mode dans le domaine du cloud computing, et
beaucoup pensent qu'elle peut aider à moderniser les systèmes existants en créant de nouvelles
applications évolutives conçues dans le cloud.
 Pour comprendre la nécessité et la nature de la conteneurisation, commençons par la virtualisation et

l'utilisation croissante des machines virtuelles (VM) dans le cloud.
 En général, presque toutes les entreprises utilisent l'environnement cloud (public ou privé),
avec des instances exécutant des VM avec des capacités d'évolutivité et d'équilibrage de
charge représentant leur couche de calcul.
 Cependant, les approches de virtualisation ont fait face à quelques défis qui ont rendu ces
environnements inefficaces.

Cependant, les approches de virtualisation ont fait face à quelques défis qui ont rendu ces environnements
inefficaces. En voici quelques exemples :
 Manque de cohérence des environnements : Déploiement d'applications et de packages dans des

environnements virtuels;
 Dépendance du système d'exploitation : Les applications déployées sont exécutées uniquement sur des
systèmes d'exploitation compatibles;
 Niveau d'isolement : Incapacité à fournir un sandbox instantané au-dessus du niveau du système d'exploitation;
 Granularité de la consommation de calcul : Impossibilité de déployer plusieurs applications répliquées, alors que
l'équilibrage de la charge sur la couche applicative ne se produit qu'au sein d'une seule machine et non au niveau
de la couche du système d'exploitation;
 Correctifs des images dans les environnements de production : Les déploiements canari et bleu-vert ne sont pas
flexibles au niveau du cluster et sont difficiles à gérer dans plusieurs régions;
Comment pouvez-vous résoudre ces problèmes de virtualisation ? => La réponse est la conteneurisation.

Architecture Traditionnelle [Problématiques]
 Interaction entre les différents logiciels est possible :

• accès au même chemin sur le système de fichiers.
• accès aux mêmes ressources $matérielles (ports, cpu, etc)
 La mise à jour du système d’exploitation / (d’un logiciel) va nécessairement

impacter tous les logiciels qui tournent dessus.
 Pour des logiciels fournis par des éditeurs différents, la cohabitation

est très souvent problématique.
Installation native de 3 logiciels sur même hôte

==> Solution : la virtualisation

Virtualisation basée Hyperviseur [Problématiques]
 Émule un ordinateur complet : possibilité d’émuler d’autres

types de hardware, architectures CPU et OS, etc.
 Isolation des applications via les VMs :

- Niveau d’isolation élevé (Sandbox): problème résolu
 Nouveaux problèmes apparaissent :

 Un nouveau OS est nécessaire;
 Stockage VM important même avec OS minimal;
 Bande passante réseau conséquente;
 Trop d’éléments dans une VM : pas de choix du type de stockage,
Virtualisation Matérielle: 3 VMs sur même hôte
nombre de CPU utilisés, configuration réseau, etc.

Virtualisation basée Conteneur
 Couche de virtualisation sans hyperviseur

=> Permet le fonctionnement de plusieurs applications dans un
environnement isolé ou limité.
 Les applications conteneurisées communiquent directement avec le
système hôte et sont capables ainsi de s’exécuter sur le système
d’exploitation hôte et sur l’architecture du CPU.
Architecture à Conteneurs : 3 conteneurs sur même hôte
 Démarrage facile au bout de quelques secondes : ne nécessite pas une émulation du hardware et le démarrage d’un système
d’exploitation.
 Taille des applications conteneurisées (images) très petite vis à vis celle d’une image d’une VM.
 La portabilité des conteneurs est une approche intéressante dans le développement des applications.
 Gestion facile des projets dans une machine : pas de conflit de dépendance.

Virtualisation basée Conteneur
Solution de compromis
 Une architecture qui permet au développeur d’embarquer l’ensemble des dépendances

logicielles et de les isoler.
 Stockage très léger : le conteneur s’appuie sur le noyau du système hôte.
 Le nombre de conteneurs qu’un système hôte peut encapsuler est nettement très supérieur que
son équivalent en VMs.
 Côté Cloud : offre des performances meilleures
 Côté entreprise : remplacer les solutions couteuses (hyperviseurs) par des conteneurs.

Les technologies de conteneurisation et de virtualisation entrainent une amélioration importante de

l'efficacité, car elles permettent aux développeurs d'exécuter plusieurs types de logiciels (basés sur
Windows ou Linux) dans un seul environnement.
 Cependant, la technologie des conteneurs d'applications a prouvé qu'elle offrait des avantages
considérables par rapport à la virtualisation, ce qui en fait la technologie préférée des professionnels
de l'informatique:

La virtualisation permet à plusieurs systèmes d'exploitation et applications logicielles de fonctionner

simultanément tout en partageant les ressources physiques d'un ordinateur.
 Par exemple, vous pouvez exécuter les systèmes d'exploitation Linux et Windows ainsi que
plusieurs applications sur le même serveur. Les développeurs regroupent chaque application et
ses fichiers, dépendances et bibliothèques (y compris une copie du système d'exploitation) sous
forme de machine virtuelle.
 Lorsque vous exécutez plusieurs machines virtuelles sur une seule machine physique, vous
pouvez réaliser d'importantes économies sur les coûts d'investissement initial, d'exploitation et
d'énergie

La conteneurisation utilise les ressources informatiques de manière efficace. Un conteneur crée un

progiciel exécutable qui regroupe le code de l'application et tous les fichiers de configuration,
dépendances et bibliothèques dont il a besoin pour fonctionner dans un environnement portable et
défini par le logiciel.
 Cependant, contrairement aux VM, les conteneurs ne sont pas regroupés dans une copie du
système d'exploitation.
 Au lieu de cela, les développeurs installent leurs moteurs d'exécution sur le système
d'exploitation du système hôte pour transformer celui-ci en relais et permettre à tous les
conteneurs de partager un système d'exploitation similaire.

3 . Les Fondations Linux
Chroot, Cgroups, Namespace

3 . Fondations Linux
La conteneurisation utilise les propriétés existantes (fonctionnalités) du noyau du système d’exploitation
pour créer un environnement isolé pour les processus.

La commande “jail” :: chroot
Définition : chroot (change root ) (1979) — Commande qui permet le changement du répertoire racine d’un
processus et de ses processus fils (sous-processus)
 chroot fournit un espace disque isolé pour chaque processus;
 chroot peut prévenir les logiciels malveillants de

l’accès à des fichiers à l’extérieur de l’espace
créé (faux répertoire /) crée (faux répertoire /);
 chroot n’offre aucun autre mécanisme d’isolation

processus à part le changement du répertoire
racine (/) du processus.

Contrôle de ressources : cgroups (Control Groups)
Définition : une fonctionnalité du noyau Linux pour limiter, compter et isoler l’utilisation des ressources
(processeur, mémoire, utilisation disque, etc.
 cgroups (2006) fournit un mécanisme pour rassembler des processus dans un groupe et limiter leur
accès aux ressources système.
 permet de partitionner les ressources d’un hôte.
 L’objectif est de contrôler la consommation des ressources par processus.
 Les ressources sont : Temps CPU, Mémoire système Disque dur (stockage), Bande passante (réseau).

Contrôle de ressources : cgroups (Control Groups)
Prenons par exemple une machine sur laquelle serait

installée une application web avec un front-end PHP et
une base de données MySQL.
=> CGroups permettrait de répartir la puissance de

calcul (CPU) et la mémoire disponible entre les
différents processus, afin de garantir une bonne
répartition de la charge (et donc probablement Répartition des Ressources avec Cgroups
des temps de réponse)

Les espaces de nom: namespaces
Définition : Les namespaces (ou "espaces de noms") isolent les ressources partagées. Ils donnent à chaque
processus sa propre vue unique du système, limitant ainsi leur accès aux ressources système sans que le
processus en cours ne soit au courant des limitations.
 Permettent de disposer d’un environnement distinct pour : PID, réseau, points de montage, utilisateurs
et groupes, etc.
• Par défaut, chaque système Linux possède un unique espace de nom (Namespace);
• Toutes les ressources système (système de fichiers, processus PID, IDs des utilisateurs, interfaces
réseau, etc) appartiennent à cet espace de nom.
• On peut créer des espaces de nom additionnels pour organiser les ressources à l’intérieur.
Une utilisation importante des espaces de nom, “namespaces”, est l’implémentation d’une virtualisation
légère (conteneurisation)

Les espaces de nom: namespaces

Qu’est ce qu’un container au final ?
Un conteneur est un système de fichiers (RootFS) sur le quel s’exécutent des processus en respectant les
règles suivantes :
 L’isolation : les conteneurs ne se voient pas les uns des autres;
 La limite en terme de ressources grâce à Cgroups.
Container Runtime : environnement d’exécution des conteneurs.

4 . Avantages et Inconvénients

Avantages
1) Portabilité
 Un conteneur d'application crée un progiciel exécutable qui est isolé par rapport au système
d'exploitation hôte. Ainsi, il ne dépend pas du système d'exploitation hôte et n'est pas lié à celui-
ci, ce qui le rend portable et lui permet de s'exécuter de manière cohérente et uniforme sur
n'importe quelle plate-forme ou cloud.
 Les méthodes de consolidation du système d'exploitation utilisées par les développeurs

permettent également d'éviter les incohérences telles que l'intégration qui cherche à entraver la
fonctionnalité de l'application.

Avantages
2) Vitesse
 La légèreté des conteneurs permet d'améliorer l'efficacité des serveurs et de réduire les coûts liés
aux serveurs et aux licences.
 Elle réduit également le temps de lancement, car il n'y a pas de système d'exploitation à
démarrer.
 L'utilisation d'un conteneur Docker vous permet de créer une version principale d'une application
(image) et de la déployer rapidement sur demande.

Avantages
3) Evolutivité
 La conteneurisation offre une grande évolutivité. Un conteneur d'application peut gérer des
charges de travail croissantes en reconfigurant l'architecture existante afin d'activer les ressources
à l'aide d'une conception d'application orientée vers les services. Par ailleurs, un développeur
peut ajouter d'autres conteneurs dans un cluster d'ordinateurs distribués.
 Un environnement conteneur permet l'ajout de nouvelles fonctions, mises à jour et

caractéristiques instantanément sans que cela affecte les applications d'origine. Par conséquent,
les conteneurs permettent l'évolutivité des applications avec une utilisation des ressources
minimale.

Avantages
4) Agilité
 Le Docker Engine, qui permet l'exécution des conteneurs, est devenu la norme de l'industrie en
matière de conteneurs d'applications grâce à des outils de développement simples et à une
approche universelle fonctionnant avec les systèmes d'exploitation Windows et Linux.
 Les développeurs peuvent donc continuer à utiliser les outils et les processus DevOps pour
accélérer le développement et l'amélioration des applications.

Avantages
5) Efficacité
 Étant donné que les logiciels exécutés dans les environnements conteneurisés partagent le noyau
du système d'exploitation de la machine hôte, les développeurs peuvent partager les couches
d'application entre les conteneurs.
 De plus, les conteneurs ont une capacité intrinsèquement plus petite que les machines virtuelles.
 Leur temps de démarrage est réduit, ce qui permet aux développeurs d'exécuter plus de
conteneurs sur la même capacité de calcul qu'une machine virtuelle unique. Ainsi, l'efficacité des
serveurs est augmentée et les coûts des serveurs et des licences sont réduits.

Avantages
6) Sécurité
 L'isolation des applications via les conteneurs empêchent le code malveillant d'affecter d'autres
applications conteneurisées ou le système hôte. Vous pouvez également définir des autorisations
de sécurité pour bloquer automatiquement l'accès aux composants indésirables qui cherchent à
s'introduire dans d'autres conteneurs ou à limiter les communications.
 L'isolation des applications aide les développeurs à partager des fonctionnalités supplémentaires
sans facteur de risque. Par exemple, si vous travaillez avec une équipe de développement à
l'extérieur de votre réseau, vous pouvez partager les ressources nécessaires sans que les
informations critiques ne se trouvent dans votre réseau.

Avantages
7) Facilité de Gestion
 En utilisant une plate-forme d'orchestration des conteneurs, vous pouvez automatiser

l'installation, la gestion et l'évolution des charges de travail et des services conteneurisés.
 L'orchestration des conteneurs permet de faciliter les tâches de gestion, comme le déploiement
de nouvelles versions d'applications, l'évolution d'applications conteneurisées ou la mise à
disposition de fonctions de surveillance, de consignation et de débogage.

Avantages
8) Continuité des Opérations
 Différents conteneurs s'exécutent indépendamment, de sorte que la défaillance de l'un n'aura

pas d'impact sur la continuité des autres.
 Les équipes de développement bénéficient de la flexibilité nécessaire à la correction des erreurs

dans un conteneur sans provoquer l'arrêt des autres. Par conséquent, la conteneurisation assure
la continuité des opérations.

Avantages
8) Facilité d’Utilisation
 Les conteneurs sont conviviaux pour les développeurs, car il est possible d'utiliser un seul
environnement pour le développement et la production (un obstacle courant dans le développement
d'applications web => écrire une app sur Windows, mai ne s'exécute pas sur Mac).
 Avec la conteneurisation, l'image que votre équipe construit localement est la même que celle
exécutée en production. Lorsqu'elles sont combinées à un workflow approprié, les applications
conteneurisées peuvent aider à minimiser les bogues liés au changement d’emplacement.

Inconvénients
Les conteneurs ne sont pas parfaits et ont leurs inconvénients et leurs limites.
 Tout d'abord, une quantité étonnamment élevée de travail de mise en place est nécessaire pour
développer et lancer une stratégie de conteneurisation et la gérer efficacement.
 Il n'y a pas assez de prise en charge et de dépendance pour les applications, et malgré les technologies
émergentes dans le domaine, il n'existe toujours aucune solution complète pour le moment.
 En outre, il n'y a pas assez d'experts qualifiés, compétents et expérimentés dans ce domaine.

Inconvénients
 En augmentant la flexibilité des applications, la conteneurisation apporte de la complexité de

différentes manières. Cette complexité peut être liée à la sécurité, à l'orchestration, à la surveillance
et au stockage des données:
- Sécurité : par rapport aux VM traditionnelles, les conteneurs présentent un risque de sécurité
potentiellement plus important. Ils ont besoin d'une sécurité multiniveau, car ils ont plusieurs
couches. Par conséquent, vous devez sécuriser l'application conteneurisée ainsi que le registre, le
daemon Docker et le système d'exploitation hôte.
- Orchestration : vous pouvez utiliser un seul outil d'orchestration pour les machines virtuelles,
fourni avec une solution virtualisée (par exemple, un outil d'orchestration VMware pour
VMware). Toutefois, lorsqu'il s'agit de conteneurs, vous devez choisir parmi différents outils
d'orchestration comme Kubernetes, Mesos ou Swarm.

Inconvénients
- Stockage : le stockage des données sur les VM est simple, mais se complexifie lorsqu'il s'agit de
conteneurs. Pour les données persistantes du conteneur, vous devez les déplacer hors du
conteneur d'application vers le système hôte ou vers un endroit disposant d'un système de
fichiers persistant. La conception des conteneurs est à l'origine de la perte de données. En effet,
les données du conteneur peuvent disparaître à jamais une fois celui-ci supprimé, à moins d'en
faire une sauvegarde ailleurs.
- Surveillance : il est également essentiel de surveiller les conteneurs pour détecter les problèmes
de performance et de sécurité. Vous pouvez utiliser différents outils de surveillance, services de
surveillance externes et analyses pour faire face à ce problème. L'environnement cloud étant
complexe, vous devez surveiller de près les problèmes de sécurité.

 Néanmoins, les avantages de la conteneurisation l'emportent largement sur les inconvénients.
 Par conséquent, la décision concernant la nécessité des conteneurs dépendra uniquement de vos
besoins spécifiques en matière de stockage dans le cloud.

5 . Outils de Conteneurisation

==> Historique
 1979 : Unix V7 chroot
 2000 : FreeBSD Jails
 2001 : LinuxVServer
 2004 : Solaris Containers
 2005 : OpenVZ
 2006 : cgroups
 2008 : namespaces
 2008 : LXC
 2011 : Warden (Cloudfoundry)
 2013 : Lmctfy (google) : https://github.com/google/lmctfy
 2013 : Docker
==> LXC (Linux Container)
LXC est un projet en open source soutenu financièrement par Canonical.
o Site web : http://linuxcontainers.org/
o Plus de 60 contributeurs
o Mainteneurs : Serge Hallyn(Ubuntu), Stéphane Graber(Ubuntu)
o Intégré au noyau 2.6.24 : création des instances isolées baptisées “Conteneur Linux” ou LXC
(LinuX Containers)
o LXC utilise la notion de contrôle de ressource “cgroups” et propose également une isolation au
niveau des espaces de nom (Namespaces) et les modules ‘Application Armor’ (AppArmor) et
Security-Enhanced Linux (SELinux).
o LXC est une technologie de conteneurisation qui offre des conteneurs Linux légers

==> Docker
 Docker est un projet open source écrit en GO et hébergé

sur GitHub ( https://github.com/docker).
 Le projet a été initialement développé par la startup

DotCloud en 2013.
 Docker a utilisé LXC à ses débuts et qui a été remplacé par

la suite par sa propre bibliothèque, libcontainer.

==> Docker
Docker Vs. LXC ??
• Docker restreint l’utilisation du conteneur à une seul service (“one service per container” philosophy) :
il faut construire X conteneurs pour une application qui consiste de X services.
 On peut utiliser un seul conteneur Docker pour lancer plusieurs services via un script mais il
est généralement recommandé d’utiliser un service par conteneur.
• LXC peut contenir plusieurs processus à l’intérieur d’un conteneur;
• Docker construit sur LXC pour y ajouter des services de gestion et de déploiement d’images.
 Portabilité des conteneurs entre deux machines;
 Automatisation : création des conteneurs à partir des fichiers Dockerfile;
 Docker est un outil de création et distribution d’application portable via le concept d’image;
• l'objectif principal de Docker est de faire le paquetage, la conteneurisation, la distribution et
l’exécution des applications autant de fois, n’importe où et à tout moment.

==> Docker
L'image suivante montre la nouvelle génération de virtualisation activée via
Dockers.
 Server : est le serveur physique utilisé pour héberger plusieurs

machines virtuelles.
 Host OS : est une machine de base telle que Linux ou Windows
 Au-dessus du système d'exploitation, on déploie le moteur Docker
ou Docker Engine .
 Puis on crée un conteneur où on exécute les applications.
Le principal avantage de cette architecture est que vous n'avez pas besoin
de matériel supplémentaire pour le système d'exploitation invité.

==> Docker
Architecture Docker ??
• Docker utilise une architecture client-serveur :

o Docker Client demande à Docker daemon de créer un conteneur;
o Docker Daemon est chargé de la construction, l’exécution, et la distribution des conteneur;
o Docker Client et Daemon communiquant avec le noyau via libcontainer en utilisant REST API, Unix
Sockets ou une interface réseau.
• Docker Daemon et libcontainer existent sur la même machine ou système.
• Docker client et Daemon peuvent s'exécuter sur le même système, ou vous pouvez connecter un
client Docker à un démon Docker distant.

==> Docker

==> Docker

==> Docker
Docker Deamon (dockerd) écoute les requêtes de l'API Docker et gère les objets Docker tels que les images,
les conteneurs, les réseaux et les volumes. Un démon peut également communiquer avec d'autres démons
pour gérer les services Docker.
Docker Client (docker) est le principal moyen utilisé par de nombreux utilisateurs Docker pour interagir avec
Docker. C’est une application cliente sous forme d’interface de ligne de commande (CLI). Lorsque vous
utilisez des commandes telles que docker run, le client envoie ces commandes à dockerd, qui les exécute.
Docker Client peut communiquer avec plusieurs démons.
Container est une instance exécutable d'une image. Vous pouvez créer, démarrer, arrêter, déplacer ou
supprimer un conteneur à l'aide de l'API ou de la CLI Docker. Vous pouvez connecter un conteneur à un ou
plusieurs réseaux, y attacher un stockage ou même créer une nouvelle image en fonction de son état actuel.
Docker Engine est une application client-serveur avec ces composants majeurs : un serveur (dockerd), une
API REST et une interface cliente de ligne de commande (CLI : Client Line Interface).

==> Docker
Workflow Docker ??
1. Docker Client demande à Docker daemon de créer un conteneur en utilisant une image spécifique;
2. Docker daemon télécharge l’image depuis le dépôt Registry;
3. Docker daemon conteneur communique avec le noyau Linux via libcontainer pour créer le conteneur:
o Libcontainer permet l’accés aux APIs du noyau (cgroups, namespaves, etc) sans dépendance
externe.
o Pour construire un espace isolé pour l’application, le conteneur est crée avec les fonctionnalités.

==> Docker
Workflow Docker ??

==> Docker
Notion d’image
 Image : c’est le template / modèle, les données de l’application prêtes à l’emploi:

=> Archive qui peut être échangée entre plusieurs hôtes et réutilisée tant de fois.
 Conteneur : instance qui fonctionne / peut être démarrée

==> Docker
Notion d’image
 Les images sont disponibles dans des dépôts : https://hub.docker.com ou https://store.docker.com

 Un dépôt contient les images déposées par les autres;
 Choix multiple : possibilité de télécharger des versions;
 Le dépôt git d'une image contient les informations sur les options possibles et les explications;
 Mais !! Contraintes de sécurité liées à l’utilisation des images publiques.
Une image Docker peut être :

 Soit téléchargée depuis un dépôt;
 Soit construite à partir d’un DockerFile, puis envoyée sur un registry ou serveur

==> Docker
Gestion d’image : Docker Pull // Docker Push

==> Docker
Gestion d’image : Construction d’une image (1)
 Construction d’une image à partir d’un conteneur : docker commit
docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]

==> Docker
Gestion d’image : Construction d’une image (2)
 Construction d’une image à partir du fichier Dockerfile
 Une image est construite à partir d’un fichier de description appelé Dockerfile.
 Le fichier Dockerfile contient les commandes nécessaires pour :
o télécharger une image de base
o appliquer une série de commandes spécifiques
o décrire l’environnement d’exécution
docker build [OPTIONS] PATH

==> Docker
Gestion d’image : Construction d’une image
 Construction d’une image à partir du fichier Dockerfile
FLASK : framework open-source de

développement web en Python.

==> Docker
Gestion de conteneur : Création de conteneur
 Construction d’un conteneur à partir d’une image :
docker create --name ContainerName [OPTIONS] ImageName:TAG [COMMAND]
 ContainerName — Nom du conteneur à créer

 ImageName:TAG — Nom de l’image à exécuter et version
 COMMAND — Commande à exécuter dans le docker
 Exemples d’options :
-v HostVolume : ContainerVolume — Crée un volume partagé entre l’hôte et le conteneur
- - network — Choisir le réseau du Docker
p HostPort : DockerPort — mapping de port entre l’hôte et le conteneur

==> Docker
Gestion de conteneur : Commandes (1/2)
 Lancer un conteneur à partir d’une image :
docker run --name ContainerName ImageName:Tag command
 Lancer un conteneur existant :

docker start ContainerName (docker run = docker create + docker start)
 Arrêter un conteneur :
docker stop ContainerName

==> Docker
Gestion de conteneur : Commandes (2/2)
 Lister les conteneurs exécutés :
docker ps
 Lister les conteneurs existants :
docker ps -a
 Exécuter une commande dans un docker existant :
docker exec -it ContainerName Command

==> Docker
Gestion de conteneur : Réseau Docker

==> Docker
Gestion de conteneur : Réseau Docker Bridge
Host
Réseau 1: 172.19.0.0
Même réseau 192.168.0.0 Réseau 2: 192.168.1.0

==> Docker
Gestion de conteneur : Port Publishing
o Par défaut et lors de la création, un conteneur ne partage aucun port avec l’extérieur.
 La publication de ports réseau est un moyen de permettre au conteneur de communiquer avec
d'autres conteneurs et le monde externe.
o Publier un port (- - publish / -p)
 Publie un port conteneur à un port host (mapping)
 Exemple d’utilisation : Transfert de tout le trafic de données entrant sur le port hôte 8000 au
port conteneur 8080
docker run --publish 8000:8080 image
 8000 : port usuel de l’application conteneurisée

 8080 : port hôte (accès conteneur)

==> Docker
Gestion de conteneur : Port EXPOSE

==> Docker
Gestion de conteneur : Gestion des Données
 Les données dans un conteneur sont éphémères : les fichiers créés à l'intérieur d'un conteneur sont
stockés sur un espace de travail : couche de conteneur inscriptible (writable).e).
- Cela signifie que : Les données ne sont pas conservées lorsque ce conteneur est supprimé
 Trois méthodes de stockage :

 tmpfs mount : (éphémère) permet de stocker les données dans la mémoire du système hôte en
plus de la couche inscriptible.
 volume : configurer un volume Docker commun entre hôte
et conteneur au moment du lancement.
 bind mount : monter un répertoire du système de fichier
hôte au conteneur lors de son lancement.

==> Docker
Ecosystème Docker
Les L’écosystème Docker regroupe tous les utilitaires utilisés avec Docker :
o Docker Engine : c’est l’application client-serveur open source dont les composants centraux sont : démon
et client Docker.
o Docker machine : outil de gestion et provisioning des machines virtuelles exécutant Docker.
C’est un script utilisé pour la création des machines virtuelles utilisant docker.
o Docker Swarm : un swarm est un groupe de machines exécutant Docker et appartenant à un Cluster.
o Docker Compose : outil permettant de définir le comportement de plusieurs conteneurs qui dépendent
les uns des autres et qui permet leur lancement.

==> Docker
Docker Compose

6 . Kubernetes

6 . Kubernetes
==> Motivation
Deux besoins majeurs :
1. Gestion des conteneurs en Cluster

 Besoin de gérer et configurer plusieurs conteneurs pour une application
 Répartition des conteneur sur un seul serveur : risque d’arrêt application si échec serveur
 Solution : déploiement des conteneurs en Cluster :
- Plusieurs serveurs en communication entre eux;
- Ensemble de machines configurées pour travailler ensemble et vues comme un système unique.
2. Orchestration des conteneurs

 Besoin d’appliquer des mises à jour sans interruption de l’application;
 Besoin de faire un monitoring continu et vérifier si les conteneurs sont fonctionnels;
 Relancer un conteneur si problème ou échec;
 Besoin de faire le déploiement rapide de nouveaux conteneurs en cas de besoin.

6 . Kubernetes
L'orchestration de conteneurs est l'automatisation d'une grande partie de l'effort opérationnel requis pour
exécuter des services conteneurisés : déploiement, le passage à l'échelle, la mise en réseau, équilibrage de
charge entre VMs, etc.
Kubernetes est la solution dominante d’orchestration de conteneurs développée

en Open Source au sein de la « Cloud Native Computing Foundation ».

6 . Kubernetes
==> Introduction
 Kubernetes est orchestrateur, une plateforme pour automatiser le déploiement, la mise à l'échelle et la
gestion des applications conteneurisées.
 Kubernetes a été développé et utilisé par Google

 Annoncé comme un outil open source à 2014
 Date de la première version Kubernetes v1.0 : 21-07-2015
 Autour de ce projet, Google s'est associé à la Linux Foundation pour former la « Cloud Native
Computing Foundation » qui comprend : Google, CoreOS, Mesosphere, Red Hat, Twitter, Huawei, Intel,
Cisco, IBM, Docker, Univa et VMware. Depuis, Kubernetes a été proposé comme technologie de base.
 Kubernetes prend en charge Docker et d’autres outils de conteneurisation.
 Kubernetes est disponible sur les plateformes Cloud : Google Container Engine, Azure, AWS EKS, etc

6 . Kubernetes
==> Introduction
 Il s’agit d’une solution robuste, structurante et open source qui se construit autour des objectifs de:
 Rapidité
 Scaling des logiciels et des équipes de développement
 Abstraction et uniformisation des infrastructures
 Le nom Kubernetes tire son origine du Grec ancien, signifiant capitaine ou pilote;
 K8s est l’abréviation dérivée par le remplacement des 8 lettres “ubernete” par “8” ;
 L’objectif de Kubernetes est d’automatiser le déploiement des applications conteneurisées dans un
cluster. Pour ce faire, Kubernetes utilise des outils d’orchestration : REST API, CLI et une interface web
graphique.
 Fonctionnalités Kubernetes :
 Provisionnement et déploiement des conteneurs  Augmenter la disponibilité des services
 Equilibrage de charge  Allocation des ressources entre conteneurs
 Passage à l’échelle : évolutivité  Assurer le monitoring

6 . Kubernetes
==> Architecture
 Kubernetes a une architecture master/worker

composés d’un control plane et de nœuds workers.
 Les pods Kubernetes servent à grouper des

conteneurs fortement couplés en unités d’application.
 Les deployments sont une abstraction pour créer ou

mettre à jour (ex : scaler) des groupes de pods.
 Enfin, les services sont des groupes de pods (des

deployments) exposés à l’intérieur ou à l’extérieur du
cluster.

6 . Kubernetes
==> Architecture
Kubernetes est formé de deux composants essentiels :
o Control Plane (Master Node) : héberge le contrôleur et le gestionnaire du système

Kubernetes complet
o Worker node(s) : hébergent les applications déployées

6 . Kubernetes
==> Architecture

6 . Kubernetes
==> Architecture
Kubernetes Control Plane (Master Node)
responsable de services qui gèrent les fonctionnalités d’orchestration.
==> Les composants du Master Node

1. API Server
 Représente le front-end du Master : point d’accès k8s (Entrypoint to k8s cluster).
 Gère toutes les communications internes et externes entre les différents composants.
2. Etcd
 Stockage permanent utilisé par Kubernetes pour enregistrer la configuration complète du Cluster.
 Conserve l’état actuel du Cluster : données de configuration, status des Worker nodes et de leurs
conteneurs (données) : conserve l’état actuel de chaque composant.
 Outil de restauration du Cluster complet.
3. Scheduler :
 Elément responsable de la planification et de l’organisation des applications.
 Fait l’affectation des charges de travail (conteneurs) selon la disponibilité des ressources dans les nœuds.
4. The controller manager : gère et supervise les composants configurés pour un cluster

6 . Kubernetes
==> Architecture
Worker Node
des machines physiques ou virtuelles (VMs) qui hébergent les instances des applications.
==> Les composants du Worker Node
1. Container Runtime :gère les opération sur les conteneurs à l’intérieur d’un noeud. Exemple : Docker
1. Kubelet
 Agent qui maintient le noeud et communique avec le Master via l’API Server.
 Supervise le fonctionnement des conteneurs : si un noeud tombe en panne, il sera détecté par
Kubelet et l’information sera transférée au Master.
2. Kube-proxy
 Responsable de la gestion du réseau des conteneurs telle que affectation des adresses IP, opération
de publication des ports, etc.

6 . Kubernetes
==> Architecture
Client Kubectl
o Outil CLI fournit par Kubernetes pour gérer le cluster.
o L’utilisateur utilise kubectl pour envoyer des commandes au cluster control plane (Master). À travers
une ligne de commande qui ressemble un peu à celle de Docker, on peut lister, créer, supprimer les
ressources, gérer les droits d’accès, etc
o Cet utilitaire s’installe avec un gestionnaire de paquet classique mais est souvent fourni directement par
une distribution de développement de kubernetes.
o Pour se connecter, kubectl a besoin de l’adresse de l’API Kubernetes, d’un nom d’utilisateur et d’un
certificat.
 Ces informations sont fournies sous forme d’un fichier de configuration YAML appelé
kubeconfig.
 Le fichier Kubeconfig se trouve par défaut sur Linux à l’emplacement ~/.kube/config

6 . Kubernetes
==> Architecture
Pod
o Représente la plus petite unité orchestrable de k8s seule : unité de base;
o Destiné à exécuter une instance unique d’une application : lors de la mise en échelle (élévation du
nombre des applications), on multiplie les Pods (1 pour chaque instance);
o Peut regrouper plusieurs conteneurs qui sont orchestrés sur un même hôte;
o Les conteneurs à l’intérieur d’un Pod fonctionnent ensemble ( start & stop);
o Le plus fréquent : un Pod englobe un seul conteneur.

6 . Kubernetes
==> Architecture
Deployment
o Le deployment définit un modèle (template) pour la du Pod
=> Définit le nombre de copies /instances d’une application,
c.à.d. le nombre des Pods
o Maintient les Pods en fonctionnement : si un Pod

s’arrête (dies), les services de ce dernier sont relayés à une
deuxième copie.

6 . Kubernetes
==> Architecture
Les Pods sont éphémères : meurent facilement lors d’un crash conteneur et ils seront remplacés par
“Deployment” par des nouveaux.
 Problème : Mise à jour de l’adresse IP à chaque fois??

 Solution : Création d’un service associé à un Pod qui maintient une adresse permanente pour
un Pod.
Un service
 est responsable de la création d’une address IP à un ensemble de Pods.
 lors de son création, un service est affecté à une seule adresse IP.
 Les cycles de vie Pod et Service ne sont pas connectés.

6 . Kubernetes
==> Déploiement des Applications
Pour exécuter une application sur Kubernetes, on doit :
1. Préparer les images nécessaires;

2. Faire le Push des images à un dépôt images : Registry;
3. Poster un descripteur de l’application à l’API Server via Kubect.
 Descripteur application
Contient des informations tels que : images, interactions entre les conteneurs, nombre de copies à
exécuter pour chaque image, etc. A noter que les conteneurs doivent s’exécuter sur le même nœud.
 Fonctionnement : L’API server procède par le traitement du descripteur :
o Le Scheduler planifie et répartie les groupes de conteneurs spécifiés sur les Worker Nodes
disponibles en se basant sur les ressources de calcul nécessaires pour chaque groupe et celles qui
sont disponibles au niveau de chaque Worker Node.
o Le Kubelet de chaque Worker Node informe le gestionnaire de conteneur (ContainerRuntime,
exemple Docker) pour faire le téléchargement des images nécessaires depuis le dépôt et leur
exécution sur des conteneurs.

6 . Kubernetes
==> Déploiement des Applications
Workflow Kubernetes
Developer

6 . Kubernetes
==> Installation
Pour installer un cluster de développement :
 solution officielle : Minikube, tourne dans Docker par défaut (ou dans des VMs)
 alternative qui possède de nombreux addons : microk8s
 avec Docker Desktop depuis peu (dans une VM aussi)
 un cluster léger avec k3s, de Rancher

6 . Kubernetes
==> Installation
Installer un cluster de production Kubernetes à la main est nettement plus complexe que mettre en
place un cluster Docker Swarm.
 Installer le dæmon Kubelet sur tous les noeuds

 Installer l’outil de gestion de cluster kubeadm sur un noeud master
 Générer les bons certificats avec kubeadm
 Installer un réseau CNI k8s comme flannel (d’autres sont possible et le choix vous revient)
 Déployer la base de données etcd avec kubeadm
 Connecter les nœuds worker au master.

6 . Kubernetes
==> Installation
Commander un cluster en tant que service (managed cluster) dans le cloud.
Tous les principaux provider de cloud fournissent depuis plus ou moins longtemps des solutions de
cluster gérées par eux :
 Google Cloud Plateform avec Google Kubernetes Engine (GKE) : très populaire car très flexible et
l’implémentation de référence de Kubernetes.
 AWS avec Elastic Kubernetes Services (EKS) : Kubernetes assez standard mais à la sauce Amazon
pour la gestion de l’accès, des loadbalancers ou du scaling.
 Microsoft Azure avec Azure Kubernetes Services (AKS) : axé sur l’intégration avec les services du
cloud Azure (stockage, registry, réseau, monitoring, services de calcul, loadbalancing, bases de
données…).
 DigitalOcean ou Scaleway : un peu moins de fonctions mais plus simple à appréhender.

6 . Kubernetes
==> Concepts de Base : Principes d’orchestration
1) Haute Disponibilité
 Faire en sorte qu’un service ait un “uptime” élevé.

 On veut que le service soit tout le temps accessible même lorsque certaines ressources manquent :
• elles tombent en panne
• elles sont sorties du service pour mise à jour, maintenance ou modification
• Pour cela on doit avoir des ressources multiples…
 Plusieurs serveurs
 Plusieurs versions des données
 Plusieurs accès réseau
 Il faut que les ressources disponibles prennent automatiquement le relais des ressources indisponibles.
Pour cela on utilise généralement:
• des “load balancers” : aiguillages réseau intelligents
• des “healthchecks” : une vérification de la santé des applications
• des réseaux de secours et des IP flottante fonctionnant comme des load balancers.

6 . Kubernetes
1) Haute Disponibilité
Kubernetes intègre automatiquement les principes de load balancing

et de healthcheck dans l’orchestration de conteneurs

6 . Kubernetes
2) Répartition de Charge (Load Balancing)
o Un load balancer : une sorte d'“aiguillage” de trafic réseau, typiquement HTTP(S) ou TCP.
o Un aiguillage intelligent qui se renseigne sur plusieurs critères avant de choisir la direction.
L’objectif est de permettre la haute disponibilité : on veut que notre service soit toujours disponible, même
en période de panne/maintenance.
 Donc on va dupliquer chaque partie de notre service et mettre les différentes instances derrière un
load balancer.
 Le load balancer va vérifier pour chaque backend s’il est disponible (healthcheck) avant de rediriger le
trafic.
 Répartition géographique : en fonction de la provenance des requêtes on va rediriger vers un

datacenter adapté (+ proche).

6 . Kubernetes
2) Répartition de Charge (Load Balancing)
Healthchecks
Fournir à l’application une façon d’indiquer qu’elle est disponible, c’est-à-dire :
 qu’elle est démarrée (liveness)
 qu’elle peut répondre aux requêtes (readiness).
Solutions de load balancing externe

 HAProxy : Le plus répandu en load balancing.
 Traefik : Simple à configurer et se fond dans l’écosystème des conteneurs Docker et Kubernetes.
 NGINX : Serveur web central qui a depuis quelques années des fonctions puissantes de load balancing
et TCP forwarding.

6 . Kubernetes
3) Découverte de service (service discovery)
 Classiquement, les applications ne sont pas informées du contexte dans lequel elles tournent : la
configuration doit être opérée de l’extérieur de l’application.
 par exemple avec des fichiers de configuration fournie via des volumes;
 ou via des variables d’environnement;
 Mais dans un environnement hautement dynamique comme Kubernetes, la configuration externe ne

suffit pas pour gérer des applications complexes distribuées qui doivent se déployer régulièrement, se
parler et parler avec l’extérieur.
 La découverte de service désigne généralement les méthodes qui permettent à un programme de
chercher autour de lui (généralement sur le réseau ou dans l’environnement) ce dont il a besoin.
 La mise en place d’un système de découverte de service permet de rendre les applications plus
autonomes dans leur (auto)configuration.
 Elles vont pouvoir récupérer des informations sur leur contexte (dev ou prod, Etats-Unis ou Europe ?)
 Ce type d’automatisation permet de limiter la complexité du déploiement.

6 . Kubernetes
3) Découverte de service (service discovery)
 Concrètement, au sein d’un orchestrateur, un système de découverte de service est un serveur qui est au
courant automatiquement :
o de chaque conteneur lancé.
o du contexte dans lequel chaque conteneur a été lancé.
 Ensuite il suffit aux applications de pouvoir interroger ce serveur pour s’auto-configurer.
 Un exemple historique de découverte de service est le DNS : on fait une requête vers un serveur spécial
pour retrouver une adresse IP (on découvre le serveur dont on a besoin). Cependant le DNS n’a pas été
pensé pour ça :
• certaines application ne rafraichissent pas assez souvent leurs enregistrements DNS en cache.
• le DNS devient trop complexe à partir de quelques dizaines d’enregistrements.
 Solutions de découverte de service : Consul (Hashicorp) et etcd

6 . Kubernetes
4) Stratégies de Déploiement
Il existe deux types de stratégies de rollout native à Kubernetes :

o Recreate : arrêter les pods avec l’ancienne version en même temps et créer les nouveaux
simultanément
o RollingUpdate : mise à jour continue, arrêt des anciens pods les uns après les autres et création des
nouveaux au fur et à mesure (paramétrable)
Mais il existe un panel de stratégies plus large pour updater ses apps :
• blue/green : publier une nouvelle version à côté de l’ancienne puis changer de trafic.
• canary : diffuser une nouvelle version à un sous-ensemble d’utilisateurs, puis procéder à un
déploiement complet.
• A/B testing : diffusion d’une nouvelle version à un sous-ensemble d’utilisateurs de manière précise
(en-têtes HTTP, cookie, région, etc.).
 pas possible par défaut avec Kubernetes, implique une infrastructure plus avancée avec
reverse proxy (Istio, Traefik, nginx/haproxy personnalisé, etc.).
6 . Kubernetes
==> Points Forts
o Open source et très actif.
o Une communauté très visible et présente dans l’évolution de l’informatique.
o Un standard collectif qui permet une certaine interopérabilité dans le cloud.
o Les pods tendent à se rapprocher plus d’une VM du point de vue de l’application (ressources de
calcul garanties, une ip joignable sur le réseau local, multiprocess).
o Hébergeable de façon quasi-identique dans le cloud, on-premise ou en mixte.
o Kubernetes a un flat network ce qui permet de faire des choses puissante facilement comme le
multi-datacenter.
o K8s est pensé pour la scalabilité et le calcul distribué.

6 . Kubernetes
==> Faiblesses
o Une difficulté à manier tout ce qui est stateful, comme des bases de données.
 …même si les Operators et les CRD (Custom Resources Definitions) permettent de combler cette lacune
dans la logique stateless de k8s
o Beaucoup de points sont laissés à la décision du fournisseur de cloud ou des admins système:
 Pas de solution de stockage par défaut, et parfois difficile de stocker “simplement” sans passer par les
fournisseurs de cloud, ou par une solution de stockage décentralisé à part entière (Ceph, Gluster,
Longhorn…). À noter que ces solutions sont souvent bien intégrées à k8s.
 Beaucoup de solutions de réseau qui se concurrencent, demandant un comparatif fastidieux.
 Pas de solution de loadbalancing par défaut : soit on se base sur le fournisseur de cloud, soit on
configure MetalLB

Conteneurisation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Conteneurisation

Uploaded by

Copyright:

Available Formats

M41 : Virtualisation et Cloud

Dr. Hind IDRISSI

PR. H.IDRISSI, ENSAK 2023 1

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 2

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 3

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 4

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 5

 Le monde informatique reste profondément organisé autour de l’aspect artisanal de la livraison du

Séparation des responsabilités dans une architecture à conteneurs

La technologie des conteneurs logiciels cherche à résoudre cette problématique.

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 6

Qu'est-ce que la conteneurisation ?

 La conteneurisation permet de réduire les charges au démarrage et de supprimer la nécessité de

 En raison de cette efficacité élevée, les développeurs de logiciels utilisent couramment la

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 7

Qu'est-ce que la conteneurisation ?

Un conteneur d'applications est un environnement informatique entièrement regroupé en package et

o La conteneurisation d'une application permet d'isoler le conteneur du système d'exploitation hôte,

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 8

À quoi sert la conteneurisation ?

 La conteneurisation permet aux développeurs de logiciels de créer et de déployer des applications de

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 9

À quoi sert la conteneurisation ?

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 10

- 1979 : Unix V7 chroot

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 11

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 12

 Pour comprendre la nécessité et la nature de la conteneurisation, commençons par la virtualisation et

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 13

 Manque de cohérence des environnements : Déploiement d'applications et de packages dans des

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 14

Architecture Traditionnelle [Problématiques]

 Interaction entre les différents logiciels est possible :

 La mise à jour du système d’exploitation / (d’un logiciel) va nécessairement

 Pour des logiciels fournis par des éditeurs différents, la cohabitation

Installation native de 3 logiciels sur même hôte

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 15

Virtualisation basée Hyperviseur [Problématiques]

 Émule un ordinateur complet : possibilité d’émuler d’autres

 Isolation des applications via les VMs :

 Nouveaux problèmes apparaissent :

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 16

Virtualisation basée Conteneur

 Couche de virtualisation sans hyperviseur

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 17

Virtualisation basée Conteneur

 Une architecture qui permet au développeur d’embarquer l’ensemble des dépendances

 Stockage très léger : le conteneur s’appuie sur le noyau du système hôte.

 Côté Cloud : offre des performances meilleures

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 18

Les technologies de conteneurisation et de virtualisation entrainent une amélioration importante de

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 19

La virtualisation permet à plusieurs systèmes d'exploitation et applications logicielles de fonctionner

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 20

La conteneurisation utilise les ressources informatiques de manière efficace. Un conteneur crée un

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 21

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 22

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 23

La commande “jail” :: chroot

 chroot fournit un espace disque isolé pour chaque processus;

 chroot peut prévenir les logiciels malveillants de

 chroot n’offre aucun autre mécanisme d’isolation

PR. H.IDRISSI, ENSAK 2023 M41 : VIRTUALISATION & CLOUD COMPUTING 24

Contrôle de ressources : cgroups (Control Groups)