DevOps : Développement et Opération

Prof. Samya Bouhaddour

1
A.U. : 2023-2024
 PLAN
• Introduction au concept DevOps • Outil de conteneurisation ‘Docker ’
o Introduction à DevOps o Le concept de la virtualisation
o Introduction à la plateforme Azure o Définition d’outil d’orchestration des
DevOps conteneurs
• Contrôleur de code source GIT o Dockerfile
o Définition d’un contrôleur de code o Docker-image
source o Conteneur Docker
o Application de commandes de base o Crétaion des images
GIT o Docker-Compose
o Partage d’un répertoire distanciel o Kubernetes
o Gestion des branches • Gestion de pipeline
o Fast-Forward / No-Fast-Forward
o Rebase / Rebase Interactif
• Planification
o Utilisation d’Azure Board S. BOUHADDOUR 2
Introduction à DevOps

S. BOUHADDOUR 3
SDLC : Software Development Lice Cycle

S. BOUHADDOUR 4
WATERFULL : MODÈLE EN CASCADE

S. BOUHADDOUR 5
AGILE

S. BOUHADDOUR 6
Le terme génie logiciel désigne l’ensemble des méthodes*, des techniques* et outils*
concourant à la production d’un logiciel, au delà de la seule activité de programmation.

Ensemble des méthodes, des techniques et outils * : Le génie logiciel ne se limite pas à une
seule approche ou méthode. Il englobe un large éventail de méthodes, de techniques et d'outils
utilisés pour développer un logiciel de manière efficace et de haute qualité. Cela comprend la
planification, la conception, la construction, les tests, la maintenance et la gestion de projet.

S. BOUHADDOUR 7
LES DÉFIS

La taille des projets: pour certains, des millions de ligne de code (MLOC)

Contribution à des projets existants

• Peu de projets démarrés from scratch

• Plus de valeur d’ajouter 100 LOCs à un grand projet largement utilisé que d’écrire
10000 LOCs dans son coin. Exemples de ces projets : systèmes d'exploitation, bases
de données massives, ERP, plateformes de médias sociaux, etc.
• La taille des projets impacte divers aspects : complexité du développement,
ressources requises, planification, gestion du code et des versions, performances et
maintenance.
• Gérer efficacement de grands projets exige une planification minutieuse, une
coordination d'équipe efficace, ainsi que des outils et des processus appropriés.
S. BOUHADDOUR 8
LES DÉFIS

Réutilisation de code existant

Est ce que le concepteur d’une voiture commence par réinventer la roue?

• Pratique courante et bénéfique dans le développement logiciel.

• Évite de réinventer la roue à chaque projet.
• Recherche et utilisation de bibliothèques, frameworks et modules existants.
• Permet d'économiser du temps et des ressources.
• Favorise la cohérence, la fiabilité et la qualité du logiciel.
• Utilisation de composants éprouvés et souvent maintenus par une communauté plus
large.

S. BOUHADDOUR 9
LES DÉFIS

Collaboration avec d’autres développeurs

Comment interagir?
• Utilisation d'outils de gestion de versions comme Git.
• Plateformes de gestion de projets telles que GitHub ou GitLab.
• Communication via des forums de discussion et des réunions virtuelles.

Comment fournir du code réutilisable?

• Assurer une documentation claire et complète du code.
• Adopter une conception modulaire et bien encapsulée.
• Publier le code sur des plateformes accessibles aux autres développeurs.
• Encourager une communication ouverte sur les normes de codage et les bonnes
pratiques.
S. BOUHADDOUR 10
LES DÉFIS

Utilisateurs/Clients :

• Compréhension des besoins et des attentes des utilisateurs.

• Collecte de retours d'expérience et de feedbacks.
• Validation des fonctionnalités du logiciel en collaboration avec les utilisateurs.
• Développement de produits offrant une valeur réelle et une expérience utilisateur
positive.

S. BOUHADDOUR 11
LES ENJEUX

L’industrie du logiciel, c’est 5% de projets “from scratch” et 95% de projets existants.

Le travail consiste alors à:

 Réutiliser : Utiliser des composants existants pour éviter de recréer des fonctionnalités déjà
développées.
 Faire évoluer : Ajouter de nouvelles fonctionnalités ou améliorer les existantes pour répondre
aux besoins changeants.
 Etendre : Augmenter les capacités ou la portée d'un système pour inclure de nouveaux cas
d'utilisation.
 Adapter : Modifier un logiciel pour qu'il fonctionne dans de nouveaux environnements ou avec
de nouvelles technologies.
 Maintenir : Assurer le bon fonctionnement du logiciel en appliquant des correctifs et en
fournissant un support continu.
 Réorganiser : Restructurer le code existant pour améliorer sa qualité et sa facilité de
maintenance. S. BOUHADDOUR 12
DEVOPS

Définition simple :
Ensemble de techniques et d’outils facilitant le passage du développement à la production.

Bien plus que ça:

• Modèle de fonctionnement de l’entreprise

• Modèle d’interactions entre les équipes
• Intégration du retour sur expérience
• Une “culture”
Nous en resterons à la définition simple !

S. BOUHADDOUR 13
DEVOPS

Relation entre Dev et Ops

Dev: Equipes de développeurs logiciels

Ops: Equipes en charge de la mise en production des produits

Antagonisme fort
Dev: Modifications aux moindres coûts, le plus rapidement possible
Ops: Stabilité du système, qualité

L’automatisation est au cœur de l’approche DevOps !

S. BOUHADDOUR 14
Le DevOps est un ensemble de pratiques qui met l'emphase sur l'automatisation des
processus entre les équipes de développement, et les équipes en charge du maintien en
conditions opérationnelles de l'application développée.

• gain de confiance des équipes entre elles ;

• accélération des livraisons et des déploiements ;
• résolution des tickets plus rapide ;
• gestion plus efficace des tâches non planifiées…

Méthodes agiles

S. BOUHADDOUR 15
 DevOps : Automatisation

Livraison continue
Intégration continu Déploiement continue
- Déploiement rapide et fiable des
- Intégration automatique des - Automatisation totale du
modifications validées.
modifications du code. processus de mise en production.
- Livraison sans délai excessif ni
- Reconstruire et tester le logiciel - Mise à jour en temps réel de
risque.
à chaque modification. l'application.
- Réactivité accrue aux besoins des
- Détection rapide des - Pas de temps d'arrêt ni de risque
utilisateurs.
problèmes. d'erreur humaine.
- Amélioration continue de
- Amélioration de la qualité du - Agilité maximale dans les mises
l'application.
code. à jour.
- Réduction des délais entre
- Réduction des conflits - Capacité à répondre rapidement
développement et mise en
d'intégration aux évolutions du marché
production

Une approche dans laquelle l'intégration Une approche dans laquelle chaque
Une méthode de développement logiciel
continue associée à des techniques de modification apportée par un programmeur
dans laquelle le logiciel est reconstruit et
déploiement automatiques assurent une passe automatiquement toute la chaîne
testé à chaque modification apportée
mise en production rapide et fiable du allant des tests à la mise en production. Il
par un programmeur
logiciel. n'y a plus d'intervention humaine
S. BOUHADDOUR 16
L'intégration continue

L'intégration continue se réfère à plusieurs pratiques :

Construire une version fonctionnelle chaque jour :
Garantit la disponibilité d'une version testable du logiciel quotidiennement.
Assure une vision claire de l'état du prototype.
Exécuter les tests quotidiennement :
Permet de détecter rapidement les erreurs et les problèmes de compatibilité.
Réduit les risques d'introduire des défauts majeurs.
Commiter les changements quotidiennement :
Favorise une approche incrémentale du développement.
Facilite la collaboration et la gestion des versions.
Système d'observation des changements :
Automatise la vérification des modifications dans le dépôt.
Réalise des actions en réponse aux changements détectés.
S. BOUHADDOUR 17
La livraison continue

Les étapes principales d'une procédure de livraison continue sont:

[Link] d'une modification
[Link]écution des tests unitaires (Intégration continue)
[Link] de validation fonctionnelle (acceptance test)
Tests black-box
Testent si le logiciel répond bien au besoin du client
Peuvent aussi être automatisés
[Link] de performances
Testent si le logiciel peut répondre à la charge
Performance et passage à l’échelle
[Link] exploratoires
Tests non-automatisés effectués par des experts
[Link] déploiement en production
S. BOUHADDOUR 18
 Définition
Diminution du temps de cycle, réduction des
coûts de livraisons, réduction des erreurs,
diminution du stress des équipe, processus de
Automatisation
livraison fiable et rapide

Etre tous orientés vers une

Favoriser le mode projet,
même cible, cible partagée l’agilité, la créativité et la
entre business , développement Partage Devops Culture mise en avant des
et exploitation. Développer le compétences de chaque
«tous ensemble»
membres des équipes

Détecter les incidents pro

Mesure activement, anticiper pour
mieux respecter coûts, délais,
périmètre

S. BOUHADDOUR 19
S. BOUHADDOUR 20
Avantages à adopter l’approche DevOps

• Accélération et amélioration de la fourniture des produits

• Résolution plus rapide des problèmes et complexité réduite
• Stabilité accrue des environnements d'exploitation
• Meilleure utilisation des ressources
• Automatisation accrue
• Meilleure visibilité sur les résultats du système
• Innovation renforcée

S. BOUHADDOUR 21
Introduction à AZURE DevOps

S. BOUHADDOUR 22
Définition

• Azure DevOps fournit des services de développement pour aider les équipes à planifier le
travail, à collaborer au développement de code et à créer et déployer des applications.
• Azure DevOps fournit des fonctionnalités intégrées auxquelles vous pouvez accéder via
votre navigateur Web ([Link]) ou votre client IDE (VS).

• Azure Repos : Pour le partage du code source.

• Azure Boards: Outils de la planification.
• Azure Pipelines : Workflow de build et déploiement.
• Azure Test Plans : Automatisation et exécution des tests.
• Azure Artifacts: Création de package pour déploiement.

S. BOUHADDOUR 23
Azure Boards
Suivez le travail effectué avec des tableaux Kanban configurables, des backlogs interactifs et des outils de planification
puissants.
Grâce à une traçabilité et à des rapports inégalés, Boards est la solution idéale pour toutes vos idées, petites ou grandes.

S. BOUHADDOUR 24
Azure Repos
Suivez le travail effectué avec des tableaux Kanban configurables, des backlogs interactifs et des outils de planification
puissants.
Grâce à une traçabilité et à des rapports inégalés, Boards est la solution idéale pour toutes vos idées, petites ou grandes.

S. BOUHADDOUR 25
Contrôleur de code source

S. BOUHADDOUR 26
LES DÉFIS

Comment gérez-vous actuellement un projet ?

 L’envoyer à travers un message sur Facebook, ... (Très mauvaise idée)

 L’envoyer par mail (Un peu moins)
 Utiliser une Dropbox, Google Drive, ... (Déjà mieux mais toujours risqué ou
manque de fonctionnalités)

SOLUTION

UTILISER UN SYSTÈME DE GESTION DE VERSION DÉCENTRALISÉ

S. BOUHADDOUR 27
S. BOUHADDOUR 28
 DÉFINITION

• Source contrôle est la pratique du suivi et de la gestion des modifications du code

• Les sources contrôles fournissent un historique de développement du code et aident à
résoudre les conflits lors de la fusion de contributions provenant de plusieurs sources.
• Le contrôle des sources protège le code source des dégradations occasionnelles suite aux
erreurs humaines.
• Les avantages incluent: la réutilisabilité, la traçabilité, portabilité, l'efficacité, la
collaboration et l'apprentissage.

S. BOUHADDOUR 29
CE QUE PERMET DE FAIRE UN SYSTÈME DE CONTRÔLE DU CODE SOURCE

• Conserver tout le code source

• Prendre note de tous les changements effectués au code source et à sa documentation
=> permet de retourner à une version antérieure (qui, elle, fonctionnait ! !)
• Identifier quels fichiers ont été modifiés
• Déterminer qui a modifié un bout de code
• Comparer des versions
• Fusionner des versions développées de façon concurrente
• Identifier et gérer les releases*, les versions**, les branches de développement ***

Release* : des versions stables et officielles du logiciel, généralement destinées à être utilisées par les utilisateurs finaux
Versions** : Les versions correspondent à différentes itérations du logiciel, avec des fonctionnalités ajoutées, des bogues corrigés, etc.
Branches de développement ***: sont des versions du code source qui évoluent séparément les unes des autres.
Par exemple, il peut y avoir une branche de développement pour travailler sur de nouvelles fonctionnalités tandis qu'une autre branche est dédiée à la
correction de bugs. Un système de contrôle de code source permet de gérer ces différentes entités de manière organisée, en les identifiant clairement et en
facilitant leur gestion.
S. BOUHADDOUR 30
LES DIFFÉRENTS SCCS : SCCS CENTRALISÉ VS. SCCS DISTRIBUÉ

SCCS Centralisé
Tout l’historique des changements est conservé sur un serveur central (distant), duquel
n’importe qui peut obtenir la version la plus récente ou envoyer les changements les plus
récents.

SCCS distribué
Chaque usager a une copie locale de tout l’historique des changements. Il n’est donc pas
nécessaire d’être connecté à un réseau/serveur pour sauvegarder des changements. En outre,
n’importe quel usager peut se synchroniser avec n’importe quel autre.

S. BOUHADDOUR 31
Les différents SCCS : SCCS Centralisé vs. SCCS Distribué

S. BOUHADDOUR 32
LES AVANTAGES ET LES INCONVÉNIENTS DU SCCS DISTRIBUÉ

AVANATGES
• Chaque développeur a son espace privé — son sandbox
• On peut travailler — et faire des commits ! — hors ligne
• Plusieurs opérations sont très rapides — exécution locale
• La création et fusion de branches est efficace

INCONVÉNIENTS

• Quand même préférable d’avoir un dépôt central (sauvegarde)

• Pas nécessairement «une» version «la plus récente»

S. BOUHADDOUR 33
DÉMARRER AVEC GIT

 Git est un système de contrôle de version distribué gratuit qui permet aux programmeurs de
suivre les modifications du code, via des "instantanés" (commits), dans leur état actuel.
 L'utilisation de validations permet aux programmeurs de tester, déboguer et créer de
nouvelles fonctionnalités en collaboration. Tous les commits sont conservés dans ce que l'on
appelle un « référentiel Git » pouvant être hébergé sur votre ordinateur, des serveurs privés
ou des sites Web open source, tels que Github.
 Git permet également aux utilisateurs de créer de nouvelles "branches" du code, ce qui
permet aux différentes versions du code de cohabiter.

S. BOUHADDOUR 34
LES CONCEPTS DU GIT

 Espace de travail : C'est l'endroit où vous travaillez sur vos fichiers. Il s'agit simplement des
fichiers et répertoires que vous voyez et manipulez sur votre ordinateur. Ils n'ont rien de
spécial par rapport à d'autres dossiers sur votre ordinateur.
 Dépôt local: Il s'agit de votre espace de travail associé à l'historique des modifications. C'est
là que Git enregistre toutes les modifications que vous avez apportées au fil du temps.
 Commit : Un commit représente une version spécifique de votre projet à un moment donné.
Chaque commit est comme une "capture d'écran" de l'état de vos fichiers à un moment
précis. Il contient les modifications que vous avez apportées ainsi qu'un message descriptif.
 Historique : C'est la "chaîne" de tous les commits, du plus ancien au plus récent. Cet
historique vous permet de voir l'évolution de votre projet au fil du temps.
 Dépôt distant : C'est un dépôt Git qui se trouve sur un serveur distant, comme GitHub. Il est
souvent utilisé pour collaborer avec d'autres personnes sur un projet ou pour sauvegarder
votre code.
S. BOUHADDOUR 35
LES ZONES DU GIT

Git a 3 "zones" différentes pour votre code:

 Répertoire de travail : zone dans laquelle vous allez travailler (création, modification,
suppression et organisation des fichiers)
 Zone de transit : la zone dans laquelle vous listerez les modifications apportées au répertoire
de travail
 Référentiel : où Git stocke en permanence les modifications que vous avez apportées sous
différentes versions du projet

S. BOUHADDOUR 36
CONTRÔLE WORKFLOW

Le contrôle de version a un flux de travail général que la plupart des développeurs utilisent
pour écrire du code et le partager avec l'équipe

 Obtenez une copie locale du code s'ils n'en ont pas encore.
 Apportez des modifications au code pour corriger les bogues ou ajouter de nouvelles
fonctionnalités.
 Une fois le code prêt, rendez-le disponible pour examen par votre équipe (Pull
Request).
 Une fois le code révisé, fusionnez-le dans la base de code partagée de l'équipe.

S. BOUHADDOUR 37
 ACTIONS AVEC GIT

• Créer un dépôt sur GitHub.

• Cloner (faire une copie d’) un dépôt de GitHub sur son PC: Git clone URL_Repo
• Ajouter un fichier modifié : il sera pris en compte dans le prochain commit: Git
add nom_fichier / . / -a / *
• Faire un commit : créer une nouvelle version, qui contient tous les fichiers ajoutés.
On y ajoute un commentaire (qui décrit les changements): Git commit –m « message
du commit »

S. BOUHADDOUR 38
 ACTIONS AVEC GIT

• Consulter un historique: Git log

• Push : envoyer ses nouveaux commits sur GitHub: Git push
• Pull : récupérer des changements (qui ont été envoyés par quelqu’un d’autre) depuis
GitHub: Git pull
• Branches :
• Créer une branche: Git branch nom_branche
• Basculer entre les branches: Git checkout nom_branche
• Lister les branches: Git branch –a
• Supprimer une branche: Git branch –d nom_branch
• Merge : quand on Pull et qu’on a aussi des nouveaux commits sur son PC. Git essaye de
fusionner automatiquement ; s’il ne sait pas le faire, il demande à l’utilisateur: Git merge

S. BOUHADDOUR 39
Bonnes pratiques pour le contrôle des sources

• Faites de petits changements, avec des commit régulières.

• Ne pas comité des fichiers personnels.
• Mettre à jour souvent et juste avant de pousser pour éviter les conflits de fusion.
• Vérifiez votre changement de code avant de le pousser dans un référentiel, assurez-
vous qu'il compile et que les tests réussissent.
• Portez une attention particulière à la validation des messages car ceux-ci vous
indiqueront pourquoi un changement a été effectué.
• Lier les modifications de code aux éléments de travail (WorkItem).

S. BOUHADDOUR 40
Gestion des Branches

S. BOUHADDOUR 41
Motivations

Une équipe de développeurs participe à la réalisation d’une application:

• Comment conserver un historique?
• Comment revenir en arrière?
• Comment travailler à plusieurs en parallèle sur le même code?
• Comment gérer plusieurs versions du code à la fois?
• Comment savoir ce qui a modifié et par qui (et pourquoi)?

S. BOUHADDOUR 42
La notion d’historique

• L’historique est un graphe orienté composé d’un ensemble de versions pouvant être
recalculées à partir des versions adjacentes en appliquant les patchs.
• L’historique peut inclure plusieurs branches, c’est-`a-dire des sous-graphes qui
évoluent en parallèle.

S. BOUHADDOUR 43
Historique: les merges

On appelle merge toute version ayant un degré sortant strictement supérieur à 1.

Cette version correspond alors à la fusion des patchs de plusieurs branches.

S. BOUHADDOUR 44
Gestion des accès concurrents

Gestion pessimiste
• Un seul contributeur à accès en écriture à un fichier
• Pas de conflits
• Pas pratique

Gestion optimiste
• Chaque développeur peut modifier sa copie locale en parallèle
• Risques de conflits
▶ Modifications concurrentes de la même zone de texte

S. BOUHADDOUR 45
Les objets dans Git

• Blobs
• Tree
• Commit
• Tag

S. BOUHADDOUR 46
Blob « Binary Large Object »

On appelle Blob, l’élément de base qui permet de stocker le contenu d’un fichier.
C'est simplement le contenu d'un fichier, stocké de manière compressée dans la base de
données Git. Les blobs sont identifiés par des clés SHA-1 qui sont calculées à partir de
leur contenu.
• Chaque Blob est identifié de manière unique par sa clé
• A chaque révision du fichier correspond un nouveau Blob
 Le blob stocke le contenu entier du fichier
Le Blob ne dépend pas du nom ou de l’emplacement
 Si un fichier est renommé, pas de nouveau Blob
 Si un fichier est déplacé, pas de nouveau Blob
• Le contenu du Blob est compressé avec zlib. Il contient:
 Le type d’objet (blob)
 La taille du fichier initial
 Le contenu du fichier
S. BOUHADDOUR 47
Tree

• Un arbre représente un répertoire (ou dossier) dans un projet Git.

• Chaque arbre contient des entrées qui pointent vers des blobs correspondant aux
fichiers présents dans ce répertoire, ainsi que vers d'autres sous-arbres pour les
sous-répertoires.
• L'entrée d'un arbre contient des métadonnées telles que le nom du fichier ou du
sous-répertoire, le mode (permissions), et l'identifiant SHA-1 du blob ou de l'arbre
auquel elle pointe.

S. BOUHADDOUR 48
Tree et Blob: Exemple

S. BOUHADDOUR 49
Commit

Un Commit stocke l’état d’une partie du dépôt à un instant donné.

Il contient :
• Un pointeur vers un Tree (arbre racine) dont on souhaite sauver l’état.
• Un pointeur vers un ou plusieurs autres Commits pour constituer un historique.
• Les informations sur l’auteur du Commit.
• Une description sous forme d’une chaîne de caractères.

S. BOUHADDOUR 50
Le cycle de vie d’un fichier

S. BOUHADDOUR 51
Les branches

Dans Git
• Une branche est un pointeur sur un commit
• Chaque commit pointe vers son prédécesseur
• La variable HEAD pointe sur la branche sur laquelle on travaille actuellement.

S. BOUHADDOUR 52
Les branches – Les commandes

S. BOUHADDOUR 53
Les Merges

$ git checkout brancheDestination

$ git merge brangeSource
• Crée un commit qui a pour parent les deux branches
• La branche courante avance à ce commit
• La source ne bouge pas, mais devient un fils du nouveau commit

S. BOUHADDOUR 54
S. BOUHADDOUR 55
S. BOUHADDOUR 56
S. BOUHADDOUR 57
S. BOUHADDOUR 58
S. BOUHADDOUR 59
S. BOUHADDOUR 60
S. BOUHADDOUR 61
S. BOUHADDOUR 62
S. BOUHADDOUR 63
S. BOUHADDOUR 64
 Rebase
• Autre manière de fusionner 2 branches
• Permet de simplifier l’historique
• Fusion (merge) : Lorsque vous fusionnez deux branches avec git merge, Git combine
l'historique des deux branches pour créer un nouveau commit de fusion. Ce nouveau
commit de fusion a deux parents, représentant les commits les plus récents de chaque
branche. En d'autres termes, Git prend tous les changements effectués dans les deux
branches et les intègre dans un nouveau commit de fusion. Cela signifie que l'historique de
développement de chaque branche est préservé.
• Réalignement (rebase) : Lorsque vous réalignez une branche avec une autre branche à
l'aide de git rebase, Git déplace les commits de la branche en cours de réalignement
pour qu'ils apparaissent au-dessus des commits de l'autre branche. Cela récrit
essentiellement l'historique de la branche en cours sur le dessus de l'autre branche.
Contrairement à la fusion, le réalignement n'ajoute pas de commit de fusion
supplémentaire. Au lieu de cela, il réorganise l'historique de manière à ce que l'historique
semble linéaire, ce qui peut rendre l'historique du projet plus clair.
S. BOUHADDOUR 65
GIT MERGE VS GIT REBASE

S. BOUHADDOUR 66
GIT MERGE VS GIT REBASE

S. BOUHADDOUR 67
 Rebase interactif

• Permet de réécrire l’historique en partant de CommitID

• Principales actions possibles
o reword: editer le message du commit
o squash: fondre le commit dans le commit précédent
o drop: supprimer le commit

S. BOUHADDOUR 68
 Message de commit

Le plus important
• Décrire quoi et pourquoi et pas comment
• Ne pas décrire les modifications qui sont faites (informations disponibles avec un diff)
• Décrire les fonctionnalités ajoutées
Exemple
• Bad: Modifie la fonction f pour tester la variable a
• Good: Vérifie les droits de l’utilisateur avant d’exécuter l’action X

S. BOUHADDOUR 69
Azure Boards

S. BOUHADDOUR 70
C’EST QUOI LA RELATION ENTRE AZURE
ET DEVOPS?

S. BOUHADDOUR 71
Définition d’Azure Microsoft
Azure est une plateforme de Cloud qui dispose de tout ce dont une entreprise a besoin pour
gérer virtuellement une partie ou la totalité de ses opérations informatiques : serveurs,
stockage, bases de données, réseaux, statistiques et bien plus encore.

Définition d’Azure Devops

La plateforme Azure DevOps, facilite la collaboration entre deux métiers qui travaillaient
auparavant séparément : le développeur de programmes et de logiciels (le dev) et le
responsable des infrastructures informatiques chargé de la mise en production (l’Ops ou
opérateur).
Azure DevOps dispose d'intégrations robustes avec Azure, ainsi que d'une suite complète de
technologies qui vous permettent de fournir des logiciels rapidement et en toute sécurité.
S. BOUHADDOUR 72
AVANTAGES DE DEVOPS SUR AZURE

S. BOUHADDOUR 73
CONCEPTS DE DEVOPS

S. BOUHADDOUR 74
LES PRINCIPAUX CONCEPTS D'AZURE BOARDS
 Boards ‘Tableau’
Il s’agit des espaces de travail visuels où les équipes peuvent organiser leurs travaux en
utilisant des colonnes personnalisables, souvent représentant l'état de progression des tâches (à
faire, en cours, terminé, etc.).
 Work item ‘Eléments du travail’
C’est une unité de tâche, de problème, de fonctionnalité ou d'autres éléments à gérer.
Il s'agit de travaux individuels qui doivent être réalisés.
 Backlog
Le backlog peut être composé de différents types d'éléments, tels que des user stories, des
bugs, des tâches, etc. Les éléments du backlog sont généralement triés par ordre de priorité et
sont planifiés pour être réalisés au fil du temps
 Sprint
Un sprint est une période de temps définie, généralement de deux à quatre semaines, pendant
laquelle une équipe de développement travaille sur un ensemble spécifique de tâches et de
fonctionnalités.
S. BOUHADDOUR 75
LES PRINCIPAUX CONCEPTS D'AZURE BOARDS

 Queries
Les requêtes (queries) dans Azure DevOps permettent de filtrer et d'interroger les données, y
compris les éléments du backlog. Vous pouvez créer des requêtes pour afficher des sous-
ensembles spécifiques du backlog, comme les éléments affectés à une personne particulière,
les éléments qui n'ont pas encore été planifiés pour un sprint, etc.

S. BOUHADDOUR 76
 LES DIFFÉRENTS WORK ITEM PROCESS

 Basic est le plus léger et se trouve dans un

aperçu sélectif.
 Scrum est le deuxième plus léger.
 Agile prend en charge de nombreux termes de
méthode Agile.
 CMMI fournit le plus grand support pour les
processus formels et la gestion du changement.

S. BOUHADDOUR 77
WORK ITEM PROCESS : AGILE

Choisissez Agile lorsque votre équipe utilise des méthodes de planification Agile et suit
séparément les activités de développement et de test.
Ce processus fonctionne très bien si vous souhaitez suivre les user stories et
(éventuellement) les bugs et/ou les tâches.

S. BOUHADDOUR 78
Work item process : AGILE

S. BOUHADDOUR 79
Hiérarchie des éléments de travail dans Azure Boards - AGILE

 Epic (Épopée) :
Un "épic" représente un grand ensemble de fonctionnalités ou de tâches. C'est une unité de travail de haut niveau qui
peut être divisée en fonctionnalités plus petites ou en user stories. Les épics fournissent une vue d'ensemble des
objectifs à long terme du projet.

 Feature (Fonctionnalité) :
Une "fonctionnalité" est une unité de travail plus petite que l'épic, mais plus grande que l'user story. Elle représente
une partie spécifique d'un épic. Les fonctionnalités sont souvent des ensembles cohérents de fonctionnalités liées
entre elles.

 Issue (Problème) :
Une "Issue" est un élément de suivi qui représente un problème, un bogue, une amélioration ou toute autre tâche à
résoudre dans le cadre d'un projet.
Il peut être utilisée pour signaler des problèmes techniques, des obstacles, des retards ou des demandes de
fonctionnalités.
Les issues peuvent être assignées à des membres de l'équipe pour résolution et suivi.
Ils peuvent également être liés à d'autres éléments de travail pour montrer leur impact sur le projet en cours.
S. BOUHADDOUR 80
 User Story :
C’est une unité de travail centrée sur l'utilisateur. Elle décrit une fonctionnalité du point de vue de l'utilisateur final
et fournit des détails sur ce que l'utilisateur souhaite accomplir.

 Task (Tâche) :
Une "tâche" est une unité de travail encore plus petite, souvent associée à une user story. Les tâches décrivent les
actions spécifiques nécessaires pour réaliser une user story. Elles sont généralement assignées à des membres de
l'équipe et sont suivies pour surveiller l'avancement du travail.

 Test Case (Cas de Test) :

Un test case est une documentation décrivant une série d'étapes spécifiques à suivre, ainsi que les conditions
préalables et les résultats attendus, pour tester une fonctionnalité particulière d'un logiciel.

S. BOUHADDOUR 81
 Work item process : AGILE

Le schéma suivant montre le processus Agile :

 Les Users Story et les Tasks sont utilisés
pour le suivi du travail.
 Les Bugs sont utilisés pour les defects.
 Epics et Features sont utilisés pour suivre le
travail des gros scénario

S. BOUHADDOUR 82
WORK ITEM PROCESS : BASIC

Choisissez BASIC lorsque votre équipe souhaite le modèle le plus simple qui
utilise les problèmes, les tâches et les Epics pour suivre le travail.
Les tâches prennent en charge le suivi du travail restant.

S. BOUHADDOUR 83
Work item process : BASIC

S. BOUHADDOUR 84
 Work item process : BASIC

Le schéma suivant montre le processus Basic :

 Les Issues et les Tasks sont utilisés pour le
suivi du travail.
 Epics sont utilisés pour suivre le travail des
gros scénario

S. BOUHADDOUR 85
 WORK ITEM PROCESS : CMMI

Choisissez CMMI lorsque votre équipe suit des méthodes de projet plus formelles qui
nécessitent un cadre d'amélioration des processus et un enregistrement vérifiable des décisions.
Avec ce processus, suivez les exigences, les demandes de modification, les risques et les avis.
Ce processus prend en charge les activités formelles de gestion du changement . Les tâches
prennent en charge le suivi de l'estimation initiale, du travail restant et du travail terminé.

S. BOUHADDOUR 86
Work item process : CMMI

S. BOUHADDOUR 87
Hiérarchie des éléments de travail dans Azure Boards - CMMI

 Epic (Épopée)
 Fonctionnalité (Feature)
 Exigence (Requirement)
Dans le contexte de CMMI, une exigence peut être considérée comme un synonyme d'une user story ou d'une
fonctionnalité.
 Revue (Review)
Une activité de validation où le travail accompli est examiné et évalué par l'équipe et les parties prenantes.
 Risque (Risk)
Un élément potentiellement négatif ou une incertitude qui pourrait affecter le succès du projet.
 Tâche (Task)
 Cas de Test (Test Case) :

S. BOUHADDOUR 88
 Work item process : CMMI

Le schéma suivant montre le processus CMMI :

 Les Requirement et les Tasks sont utilisés
pour le suivi du travail.
 Les Bugs pour le code defects (anomalie).
 Epics et Feature sont utilisés pour suivre le
travail des gros scénario (Niveau Portfolio
Backlog).

S. BOUHADDOUR 89
 WORK ITEM PROCESS : SCRUM

Choisissez Scrum lorsque votre équipe pratique Scrum. Ce processus fonctionne très bien
pour suivre les éléments du backlog de produit (PBI) et les bogues. Décomposez également les
PBI et les bogues en tâches sur le tableau des tâches.

S. BOUHADDOUR 90
Work item process : SCRUM

S. BOUHADDOUR 91
Hiérarchie des éléments de travail dans Azure Boards - SCRUM

 Épic (Epic)
 Fonctionnalité (Feature)
 Obstacle (Impediment)
Un élément qui entrave ou bloque le progrès de l'équipe. Les obstacles doivent être résolus rapidement pour
assurer un flux de travail efficace.
 Product Backlog
Une liste ordonnée de toutes les fonctionnalités, exigences, améliorations et bugs potentiels du produit. Il est
priorisé par le Product Owner et est continuellement raffiné et mis à jour.
 Tâche (Task)
 Cas de Test (Test Case)

S. BOUHADDOUR 92
 Work item process : SCRUM

Le schéma suivant montre le processus SCRUM :

 Les Product Backlog Item et les Tasks sont

utilisés pour le suivi du travail.
 Les Bugs pour le code defects (anomalie).
 Epics et Feature sont utilisés pour suivre le
travail des gros scénario (Niveau Portfolio
Backlog).

S. BOUHADDOUR 93
DOCKER

S. BOUHADDOUR 94
 DÉFINITION DU CLOUD

Le terme « cloud » désigne les serveurs

accessibles sur Internet, ainsi que les logiciels et
bases de données qui fonctionnent sur ces
serveurs. Les serveurs situés dans le cloud sont
hébergés au sein de datacenters répartis dans le
monde entier. L'utilisation du cloud computing
permet aux utilisateurs et aux entreprises de
s'affranchir de la nécessité de gérer des serveurs
physiques eux-mêmes ou d'exécuter des
applications logicielles sur leurs propres
équipements.
S. BOUHADDOUR 95
 LA VIRTUALISATION

• La virtualisation est un mécanisme informatique qui consiste à faire fonctionner plusieurs

systèmes, serveurs ou applications, sur un même serveur physique.
• La virtualisation est une technologie qui permet de créer et d’exécuter une version virtuelle
des machines physiques, ainsi que des ressources associées.

S. BOUHADDOUR 96
 LA VIRTUALISATION

La virtualisation est une technologie qui vous permet de créer plusieurs environnements
simulés ou ressources dédiées à partir d'un seul système physique.
Son logiciel, appelé hyperviseur, est directement relié au matériel et vous permet de
fragmenter ce système unique en plusieurs environnements sécurisés distincts. C'est ce que
l'on appelle les machines virtuelles.

S. BOUHADDOUR 97
LA VIRTUALISATION

S. BOUHADDOUR 98
 LA VIRTUALISATION ≠ CLOUD COMPUTING

Si le Cloud Computing s’appuie sur la virtualisation, les deux concepts diffèrent :

• la virtualisation permet de désolidariser les environnements informatiques de leurs

machines. Comment? => Chaque machine virtuelle dispose de ses propres ressources
allouées, telles que la mémoire, le processeur, le stockage, etc

• le Cloud Computing consiste à héberger et exploiter des données sur des serveurs distants,
par le biais du réseau internet. Comment ? => Cloud Computing vise à fournir des services
informatiques à la demande sur Internet

S. BOUHADDOUR 99
 LE CLOUD COMPUTING

• Le cloud computing désigne un ensemble de principes et d'approches visant à mettre à la

disposition d'utilisateurs qui en font la demande, quel que soit le réseau, des ressources
de calcul, de réseau et de stockage, ainsi que des services, des plateformes et des
applications.
• Ces ressources d'infrastructure, services et applications proviennent d'un cloud, c'est-à-dire
d'un pool de ressources virtuelles orchestrées par des logiciels de gestion et
d'automatisation et accessibles à la demande.

S. BOUHADDOUR 100
LA VIRTUALISATION ≠ CLOUD COMPUTING

Virtualisation Cloud Computing

Objet Créer plusieurs environnements simulés Regrouper et automatiser des
à partir d'un même système physique ressources virtuelles pour une
utilisation à la demande
Utilisation Fournir des ressources en paquets à des Fournir des ressources
utilisateurs spécifiques pour une tâche variables à des groupes
spécifique d'utilisateurs pour diverses
tâches
Configuration À partir d'une image A partir d’un modèle
Durée Années (long terme) Heure ou mois (court terme)

S. BOUHADDOUR 101
 MACHINES VIRTUELLES ≠ CONTENEURS

• La notion de conteneur est aussi souvent rapprochée de celle de virtualisation. Mais une
fois de plus, des différences existent.
• Comme son nom l’indique, une machine virtuelle est l’imitation virtuelle d’un appareil
informatique créée, dans le cadre de la virtualisation, à l’aide d’un logiciel hyperviseur,
et doté d’un système d’exploitation (ou OS) complet.

• La virtualisation par conteneurisation, quant à elle, consiste à cloisonner directement au

niveau du système d’exploitation. Ainsi, chaque conteneur exécute son environnement,
mais partage le même OS hôte. C’est pour cette raison que les conteneurs servent
généralement à la virtualisation d’un programme, et non d’un serveur dans son intégralité

S. BOUHADDOUR 102
MACHINES VIRTUELLES ≠ CONTENEURS

S. BOUHADDOUR 103
MACHINES VIRTUELLES ≠ CONTENEURS

Dans le cas de la virtualisation traditionnelle avec des

machines virtuelles, chaque machine virtuelle dispose
de son propre système d'exploitation. Ainsi, lors de
l'exécution d'applications intégrées à des machines
Machine Virtuelle
virtuelles, l'utilisation de la mémoire peut être
supérieure à ce qui est nécessaire et les machines
virtuelles peuvent commencer à utiliser les ressources
requises par l'hôte.
Contrairement aux applications classiques, les
applications conteneurisées partagent un
environnement de système d'exploitation (noyau),
Conteneur
elles utilisent donc moins de ressources que des
machines virtuelles complètes et réduisent la pression
sur la mémoire de l'hôte

S. BOUHADDOUR 104
MACHINES VIRTUELLES ≠ CONTENEURS

S. BOUHADDOUR 105
MACHINES VIRTUELLES ≠ CONTENEURS

Les machines virtuelles traditionnelles peuvent

occuper beaucoup d’espace disque: elles contiennent
Machine Virtuelle un système d’exploitation complet et les outils
associés, en plus de l’application hébergée par la
machine virtuelle.
Les conteneurs sont relativement légers: ils ne
contiennent que les bibliothèques et les outils
Conteneur nécessaires à l'exécution de l'application
conteneurisée. Ils sont donc plus compacts que les
machines virtuelles et démarrent plus rapidement.

S. BOUHADDOUR 106
MACHINES VIRTUELLES ≠ CONTENEURS

S. BOUHADDOUR 107
MACHINES VIRTUELLES ≠ CONTENEURS

En ce qui concerne la mise à jour ou la correction du

système d'exploitation, les machines traditionnelles
Machine Virtuelle doivent être mises à jour une par une: chaque
système d'exploitation invité doit être corrigé
séparément.
Avec les conteneurs, seul le système d'exploitation de
l'hôte du conteneur (la machine hébergeant les
Conteneur
conteneurs) doit être mis à jour. Cela simplifie
considérablement la maintenance.

S. BOUHADDOUR 108
MACHINES VIRTUELLES ≠ CONTENEURS

S. BOUHADDOUR 109
AVANTAGES DU CONTENEURS

• Meilleures performances
Accès direct au matériel
• Démarrage beaucoup plus rapide
Pas besoin de démarrer un système complet
• Images plus légères
Ne contient que les informations en lien avec l'application
Moins coûteux en terme d'espace de stockage
Plus rapide à transférer

S. BOUHADDOUR 110
S. BOUHADDOUR 111
 DEFINITION

Docker est une plateforme de conteneurs ayant largement contribué à la démocratisation de la

conteneurisation.
Elle permet de créer facilement des conteneurs et des applications basées sur les conteneurs. Il
en existe d’autres, mais celle-ci est la plus utilisée. Elle est par ailleurs plus facile à déployer
et à utiliser que ses concurrentes.

Il s’agit d’une plateforme logicielle open source permettant de

Créer,
Déployer
Gérer des containers d’applications virtualisées sur un système d’exploitation.

S. BOUHADDOUR 112
 DEFINITION

Docker est composé de trois éléments :

• le daemon Docker qui s’exécute en arrière-plan et qui s’occupe de gérer les conteneurs
(Containerd avec runC)
• une API de type REST qui permet de communiquer avec le daemon
• Le client en CLI (command line interface) : commande docker

S. BOUHADDOUR 113
S. BOUHADDOUR 114
Fichier DOCKER

Il s'agit d'un fichier texte simple contenant une collection de commandes ou de procédures.
Ces commandes et directives que nous exécutons agissent sur l'image de base configurée pour
créer une nouvelle image Docker.
Un Dockerfile est le code source de l'image Docker. Un Dockerfile est un fichier texte
contenant diverses instructions et configurations. La commande FROM dans un Dockerfile
identifie l'image de base à partir de laquelle vous construisez.

S. BOUHADDOUR 115
Les images DOCKER

Les images sont des plans en lecture seule qui incluent des instructions de création de
conteneurs. Une image Docker est un conteneur créé pour fonctionner sur le framework
Docker. Considérez une image comme un plan ou une image de ce qu’il y aura dans un
conteneur lorsqu’il sera opérationnel.

S. BOUHADDOUR 116
LES CONTENEURS

Les conteneurs sont des environnements d'exécution compacts et virtualisés utilisés pour
exécuter des applications. Chaque conteneur est un progiciel* comprenant tous les fichiers de
configuration, dépendances, outils système, bibliothèques et code source requis pour exécuter
une certaine application. Ils sont distincts de l'hôte et de toute autre instance exécutée sur
l'hôte.

*Ensemble de logiciels munis d'une documentation, conçus pour répondre à des besoins spécifiques et permettre une utilisation autonome.

S. BOUHADDOUR 117
DOCKER HUB

Docker HUB : Dépôt public d’images mises à disposition par Docker

S. BOUHADDOUR 118
•Créez un fichier Docker et incluez les instructions pour créer votre image Docker.
•Exécutez la commande docker build pour créer votre image Docker.
•Utilisez la commande docker run pour créer des conteneurs maintenant que l'image docker est
prête à être utilisée.

S. BOUHADDOUR 119
PRINCIPES DE FONCTIONNEMENT DE DOCKER

S. BOUHADDOUR 120
DOCKER: LES BRIQUES PRINCIPALES

Docker engine
Un environnement d'exécution et un ensemble de services pour manipuler des conteneurs
docker sur une machine.
Une application client-serveur
Le serveur -- Un daemon (processus persistant) qui gère les conteneurs sur une machine
Le client -- Une interface en ligne de commande
Un/des registres d'images docker
Bibliothèque d'images disponibles
Docker Hub

S. BOUHADDOUR 121
 PRINCIPES DES IMAGES DOCKER

Fondé sur l'utilisation d'un Union File System

• Crée la vision d'un système de fichier cohérent à partir de fichiers/répertoires appartenant à
des systèmes de fichiers différents

Un ensemble de couches
• Une image est composée d'un ensemble de couches (layers)
• L'Union File System est utilisé pour combiner ces couches
• Le file system utilisé par défaut s'appelle overlay2
• Chaque couche correspond à une instruction dans le fichier Dockerfile décrivant l'image.

Un système de fichiers Union, dans le contexte de Docker et de la conteneurisation, est une technologie qui permet de combiner
plusieurs couches de systèmes de fichiers en une seule vue unifiée.

S. BOUHADDOUR 122
S. BOUHADDOUR 123
S. BOUHADDOUR 124
S. BOUHADDOUR 125
Exemple d’un Dockerfile

S. BOUHADDOUR 126
Les autres couches

• Les couches correspondent aux différentes modifications qui sont faites pour construire
l'image à partir de l'image de base.
• Pour sauvegarder une nouvelle image, il suffit de sauvegarder les nouvelles couches qui
ont été créées au dessus de l'image de base.
• Dans un conteneur en cours d'exécution, il existe une couche supplémentaire accessible en
écriture
• Toutes les écritures vers le système de fichier faites à l'exécution du conteneur sont
stockées dans cette couche.
• Les autres couches, définies au sein de l'image utilisée pour instancier le conteneur, ne sont
accessibles qu'en lecture.
• Cette couche est supprimée à la suppression du conteneur
Optimisation des performances

• Partage des couches identiques entre conteneurs diminue l'espace de stockage utilisé par les
conteneurs.
S. BOUHADDOUR 127
Affichage de l'ensemble des couches d'une image

Avantages liés aux mécanismes de couches

Chaque couche est stockée une seule fois localement
Si certaines couches nécessaires pour une image à télécharger sont déjà présentes,
pas besoin de les télécharger à nouveau.
Réduction de l'espace de stockage
Optimisations à l'exécution
Démarrage rapide
Démarrer un conteneur nécessite simplement de créer la couche accessible
en écriture
Faible utilisation de l'espace disque
Si plusieurs containers sont instanciés à partir de la même image, ils partagent les
couches en lecture seule.
S. BOUHADDOUR 128
Identification des couches/images

Dans la version courante de Docker :

• Chaque couche est identifiée par un digest qui est un hash du contenu de la couche
• Une image est définie par un ensemble de metadonnées (principalement la liste ordonnée
des identifiants des couches constituant l'image)
• L'identifiant de l'image est créé en calculant un hash de ces metadonnées

S. BOUHADDOUR 129
CRÉER DES IMAGES
Interactivement

2 manières

En utilisant un Dockerfile

S. BOUHADDOUR 130
 Avant de commencer: Premiers pas avec docker

L'outil à la ligne de commande pour exécuter des commandes Docker :

Docker : Nous voulons exécuter une commande docker

Run : Commande pour créer et exécuter un conteneur docker
hello-world: Nom de l'image à partir de laquelle est construit le conteneur
docker pull: télécharge une image explicitement
docker run: Commande servant à créer un conteneur à partir d'une image. Télécharge l'image si elle n'est pas présente
localement.

S. BOUHADDOUR 131
Que va-t-il se passer?

L'image à charger est hello-world:latest

Vérification: est ce que l'image est présente localement?
Sinon, télécharger l'image depuis Docker Hub
Charger l'image dans le conteneur et exécuter la commande par défaut définie pour ce
conteneur

S. BOUHADDOUR 132
Construire une image interactivement

Objectifs
Créer une image à partir d'une image de base dans laquelle nous allons installer cowsay
Les étapes
1. Créer un conteneur à partir de l'image de base
2. Installer le logiciel manuellement dans le conteneur et en faire une nouvelle image
3. Jouer avec:
docker commit
docker tag
docker diff

S. BOUHADDOUR 133
 Configuration du conteneur
Démarrer un conteneur Ubuntu

f461e2e7afff est l'id du conteneur créé

Installer le programme dans le conteneur

S. BOUHADDOUR 134
 Configuration du conteneur
Quitter la session interactive

Inspecter les changements

C: fichier ou répertoire modifié

A: fichier ou répertoire ajouté

S. BOUHADDOUR 135
Sauvegarder les changements dans une nouvelle image

Exécution de la nouvelle image

Tagger une image

On peut tagger une image pour lui associer un nom (plus facile à manipuler qu'un identifiant)

S. BOUHADDOUR 136
Les Dockerfile

• Un Dockerfile est une recette décrivant comment construire une image

• Contient une suite d'instructions
• La commande docker build permet de créer une image à partir d'un Dockerfile

S. BOUHADDOUR 137
 Éléments de syntaxe

• FROM: Définit l'image à partir de laquelle la nouvelle image est créée

• LABEL: Associe des meta-données à la nouvelle image (par exemple, l'auteur de l'image)
• RUN: Définie une commande exécutée dans la couche au dessus de l'image courante lors
de la construction de l'image
• CMD: Définie la commande exécutée au démarrage du conteneur
• EXPOSE: Informe docker que le conteneur va écouter sur le port réseau défini
• COPY: Copier un fichier/répertoire depuis le contexte de construction de l'image vers la
nouvelle couche

Les commandes de Dockerfile ne sont pas sensibles à la casse. On les note en majuscule par
convention (facilite la lecture)

S. BOUHADDOUR 138
 Notre premier Dockerfile

1- La création d'un Dockerfile doit se faire dans un nouveau répertoire vide

2- Créer le Dockerfile

S. BOUHADDOUR 139
3- Construire notre image

-t permet de tagger avec un nom l'image qui va être créée

. indique le contexte de construction de l'image (où se trouve le Dockerfile)
4- Que se passe-t-il?

S. BOUHADDOUR 140
 Le build context est envoyé vers le démon docker (contenu du répertoir .)
A chaque étape:
Un conteneur est créé pour exécuter l'étape (Running in ...)
Les modifications sont committées dans une nouvelle image (---> ...)
Le conteneur est supprimé
La nouvelle image est utilisée pour la prochaine étape

5- Construction de l’image
docker build
Crée une image à partir d'un ficher Dockerfile

Crée l'image docker-whale avec le contexte correspondant au répertoire courant (le ‘.’ est
nécessaire)
Par défaut, le Dockerfile est cherché à la racine du contexte
S. BOUHADDOUR 141
 DOCKER-COMPOSE

• On sait créer des images

de manière manuelle
de manière automatisée
• On sait lancer des conteneurs

PROBLÈMES :

• On veut coordonner des conteneurs

• On veut simplifier la gestion multi-conteneurs

S. BOUHADDOUR 142
 DOCKER-COMPOSE

COMMENT FAIRE POUR

• Gérer les deux conteneurs à la volée?

• Gérer des volumes?
• Gérer des ports différents?
• Me souvenir de ces commandes?

S. BOUHADDOUR 143
 DOCKER-COMPOSE

SOLUTION

• Compose vous permet d’éviter de gérer individuellement des conteneurs qui forment
les différents services de votre application.
• Outil qui définit et exécute des applications multi-conteneurs
• Utilise un fichier de configuration dans lequel vous définissez les services de
l’application
• A l’aide d’une simple commande, vous contrôlez le cycle de vie de tous les conteneurs
qui exécutent les différents services de l’application.

S. BOUHADDOUR 144
 DOCKER-COMPOSE

UTILISATION

• Vous définissez l’environnement de votre application pour qu’il soit possible de la

générer de n’importe où
o à l’aide de Dockerfile
o à l’aide d’image officielle
• Vous définissez vos services dans un fichier [Link] pour les exécuter et les
isoler.
• Exécutez docker-compose qui se chargera d’exécuter l’ensemble de votre application

S. BOUHADDOUR 145
 DOCKER-COMPOSE

Qu'est ce que Docker Compose?

• Un outil complémentaire du Docker Engine

présenté dans les versions récentes comme un plugin de Docker Engine
Ancienne syntaxe: docker-compose command
Nouvelle syntaxe: docker compose command
• Permet de décrire une application construite à base de conteneurs dans un fichier YAML
• Docker permet d’implémenter des micro-services, cela signifie que les conteneurs se
limitent souvent à une tâche simple.

S. BOUHADDOUR 146
 DOCKER-COMPOSE

Les principes du Docker-compose

• L'utilisateur décrit son application (multi) conteneurs dans un fichier YAML appelé
[Link]
• Exécuter docker-compose up pour démarrer l'application
Compose télécharge automatique les images, les build (si nécessaire), et démarre les
conteneurs
Compose peut configurer des volumes, le réseau, et toutes autres options liées à
Docker

S. BOUHADDOUR 147
Exemple du fichier [Link]

S. BOUHADDOUR 148
Exemple du fichier [Link]

• 2 services: web et redis

 Par défaut, Compose créé un réseau bridge indépendant du réseau par défaut
 La découverte de service fonctionne sur ce réseau
web peut contacter redis en utilisant son nom
• Un conteneur pour chaque service est créé
 Pour web, une image est d'abord recréé à partir du Dockerfile présent dans le
répertoire courant
 Pour redis, l'image redis est récupérée depuis Docker Hub
• Configuration du réseau
 Le port 5000 de la machine hote est associé au port 5000 du conteneur web

S. BOUHADDOUR 149
Exemple 2 du fichier [Link]

S. BOUHADDOUR 150
Exemple 2 du fichier [Link] :
Démarrage d’une application

Les différents services qui composent mon application ont été démarrés, avec la configuration et
l’environnement qui va bien.
Information de mon application
On utilise la commande ps de Compose:

S. BOUHADDOUR 151
Exemple 2 du fichier [Link] :
Conteneurs Classiques

Les services s’exécutent via des conteneurs sur l’hôte. Les commandes docker classiques sont toujours
fonctionnelles.
Passage à l’échelle
On peut passer à l’échelle un service. Autrement dit, on peut augmenter/diminuer le nombre de conteneurs
exécutant un service. Par défaut, Compose exécute chaque service avec un conteneur.
On utilise la commande scale pour changer le nombre de réplicas d’un service:

S. BOUHADDOUR 152
A RETENIR

 Compose est un outil pour définir, lancer et gérer des services qui sont définis comme une
ou plusieurs instances d’un conteneur,
 Compose utilise un fichier de configuration YAML comme définition de l’environnement,
 Avec docker-compose on peut générer des images, lancer et gérer des services, …
 Certaines commandes de docker-compose sont équivalentes à l’outil docker, mais
s’appliquent seulement aux conteneurs de la configuration de compose.

S. BOUHADDOUR 153
 LES KUBERNETES

Problématique

Comment gérer des containers qui sont dispersés dans un grand nombre de machines ?
Dans le cas où il y a un container qui pose un problème, comment le détecter ?
Lequel aurait besoin de plus de réplications pour subvenir à une subite augmentation de
la charge ?
Solution

L’équipe opérationnelle monitore les serveurs et si un de ces derniers tombe en panne, il devra
créer de nouveaux containers avec les services déchus dans un autre serveur.
Solution automatisée

Kubernetes permet justement d’automatiser le déploiement, la gestion de demande de

puissance et la gestion des applications containerisées.
S. BOUHADDOUR 154
 LES KUBERNETES

• Kubernetes est un orchestrateur de multiples conteneurs notamment des conteneurs

dockers.
• Sa responsabilité est de surveiller les différentes instances de micro containers qu’il
supervise et d’en réguler la réplication sur différentes machines en fonction de la montée
en charge des requêtes.
• Maintenir la haute disponibilité (maintenir les conteneurs up et assurer l’état des services
qui ont été décrits).

S. BOUHADDOUR 155
 LES KUBERNETES

• Docker est une technologie d'exécution de conteneurs qui vous permet de créer, tester et
déployer des applications plus rapidement qu'avec des méthodes traditionnelles.
• Kubernetes est un outil d'orchestration de conteneurs qui vous permet de mettre à
l'échelle vos systèmes de conteneurs afin que vous puissiez gérer, coordonner et planifier
les conteneurs à grande échelle.

S. BOUHADDOUR 156
Architecture maître-esclave du Kubernetes

• Kubernetes suit l’architecture maître-esclave:

• Le maître plus communément appelé master existe principalement pour gérer votre
cluster Kubernetes.
• Les esclaves sont quant à eux plus connus sous le nom de workers (on les appellent
aussi minions ) et ne sont là que pour fournir de la capacité et n'ont pas le pouvoir
d'ordonner à une autre nœud ce qu'il peut ou ne peut pas faire.

S. BOUHADDOUR 157
L’architecture de Kubernetes
• Volumes (persistent ou non persistent) :
Ils constituent les lieux d’échange entre les pods
Persistent dans ce cas on va les stocker à l’extérieur des pods
Non persistent à l’intérieur des pods.
• Déploiements :
Gestion de création/suppression des pods
Gestion des nom de réplicas (les réplicas sets)
Assurer du respect des descriptions des relations entre conteneurs
• Namespaces :
Cluster virtuel (ensemble de services) à l’intérieur de KBS
Cloisonner à l’intérieur de notre cluster pour des services qui ne travaillent pas
ensemble et avoir une cohérence des droits des utilisateurs pour accès aux services qui
travaillent ensemble et gérer le cloisonnement si on a des services totalement différents.
Segmenter les pods

S. BOUHADDOUR 158
Architecture maître-esclave du Kubernetes

• Un cluster Kubernetes est une forme d'architecture de déploiement Kubernetes.

L'architecture de base de Kubernetes existe en deux parties :
Le plan de contrôle et les nœuds ou machines de calcul.
• Chaque nœud peut être une machine physique ou virtuelle et constitue son propre
environnement Linux. Chaque nœud exécute également des pods, composés de conteneurs.

S. BOUHADDOUR 159
Les notions et concepts de Kubernetes

• Pods: une instance de KBS : entité de référence de k8s :

- Chaque pod contient un fichier « descriptor » qui indique les paramètres
d’installation du pod
- Kubernetes ne fonctionne pas en interagissant directement avec les containers
mais avec des pods.
- Fournir un ensemble cohérent de conteneurs qui peut être un ou plusieurs conteneurs
docker ou autre.

S. BOUHADDOUR 160
Les notions et concepts de Kubernetes

• Services:
Le service se place au dessus des pods ce qui permet de faire une abstraction des pods.
Le service évite la communication par IP comme dans le cas des docker (IP peut
changer puisqu’on travaille avec les conteneurs ).
Un service est compose d’un couple IP + Port fixe , qui permet de communiquer avec
des conteneurs

S. BOUHADDOUR 161
Architecture de kubernetes

Kubernetes obéit à l’architecture maitre/esclave.

o Les composants de kubernetes sont divisés en composants de kubernetes master et ceux de
kubenetes worker.
o Kubernetes master est une unité de contrôle qui charge la répartition de la charge de travail
sur les pods, et dirige les communications dans le système et contrôle la santé des nœuds.
o Dès qu’il y a une panne dans pod il va arrêter et démarrer dans un autre nœud.
o Le kubernetes master comporte plusieurs composants et dans ce cas on a le choix d’installer
ses composants sur une seul machine du cluster ou d’un ensemble de machines du cluster
pour permettre la haute disponibilité.

S. BOUHADDOUR 162
Architecture du Kubernetes

S. BOUHADDOUR 163
Master Node

Le master node a la responsabilité d’administrer le cluster. Il coordonne les activités

telles que la mise en échelle des applications, la maintenance des applications à l’état désiré et
la propagation des mises à jour.

S. BOUHADDOUR 164
Kubernetes Master

Les composants déployés du plan de contrôle

de kubernetes:
• Etcd: SGBD interne distribué et persistant qui
stocke l’état du cluster (tous les évènement sui
se produisent)
• API Server: conteneur web avec une API
REST qui gère la communication avec les
composants internes et externes
• Scheduler: l’ordonnanceur qui perme de
déterminer la machine la moins chargé pour
déployer le pod, donc il doit envoyer toutes les
informations sur les nœuds (processus,
mémoire…)

S. BOUHADDOUR 165
Worker Node

Un worker node (WN) est une machine physique ou une VM qui détient toutes les ressources
nécessaires afin de garantir l’exécution d’un ou plusieurs pods. Cette entité va héberger tous
les services qu’un développeur aura décidé de déployer.

S. BOUHADDOUR 166
Kubernetes Node

• Le Node appelé aussi Worker est une

machine unique (ou une machine virtuelle)
ou des conteneurs (les services sous forme
de charges de travail) sont deployés sous
forme de pod (les pods regroupent des
conteneurs).
• Puisque les nodes contiennent des pods,
donc chaque node du cluster doit exécuter le
programme de conteneurisation de docker
(Docker Engine)

S. BOUHADDOUR 167
Les Composants d’un Worker Node

Les composants d’un worker node sont responsables du déploiement des pods, et conteneurs,
en plus, disposent des composants par default qui sont:
• Kubelet: Responsable de l’état d’exécution du nœud (c’est-à-dire, d’assurer que tous les
conteneurs sur un nœud sont bien organisés en Pods et envoyer des informations en
permanence au kubernetes master (plan de contrôle).
• Kube-proxy: Responsable d’effectuer le routage du trafic vers le conteneur approprié
(sélectionné pour exécuter cette tâche) en se basant sur l’adresse IP et le numéro de port de
la requête entrante (service demandé par l’utilisateur)
• cAdvisor: Agent qui surveille et récupère les données de consommation des ressources
locales des performances comme le processeur, la mémoire, ainsi que l’utilisation disque et
reseau des conteneurs du Node et envoyer ses données au composant scheduler
(ordonnanceur) dans le composant master qui va se charger de repartir les charges selon
l’état des ressources des nœuds.
S. BOUHADDOUR 168