Cours Devops Finale - Sesame [PDF]

Zitiervorschau

DevOps Dr. Ahmed Badreddine

2

Principe de qualité logiciel (1/3)

Qualité logicielle Quoi

Comment

Qualité produit (Architecture)

Qualité process (Code source)

Architectes

3

Dev

Test

Stage Pré-prod

Prod

Architecture Logicielle

4

Principe de qualité logiciel • Environnement • Dépendances • librairies

• Environnement • Dépendances • librairies

• Environnement • Dépendances • librairies

• Environnement • Dépendances • librairies

Dev = Agile

• Test continu • Intégration continue • Déploiement continu

Test

5

Stage Pré-prod

Prod

(Test, Stage et Prod) = Non AGILE

Qualité produit vs Qualité Process Dev-test-Prod

- un nombre réduit de Framwork - Architecture Simple - Une configuration par couche Product owner

Test 6

Stage Pré-prod

Prod

Qualité produit vs Qualité Process Product owner

7

Scalabilité

8

Qualité des produits (Architecture Logicielle)

Migration

monolithique

9

Micro-service

Qualité produit vs Qualité Process

- Plusieurs Framework - Architecture complexe et distribué - Plusieurs configuration Product owner

Test 10

Stage Pré-prod

Prod

Qualité produit vs Qualité Process

11

Principe de qualité logiciel (3/3) ❑ La phase de Développement (Dev) est bien Agile

❑ Comment rendre les phases de (Test, Stage et Prod)/Ops agiles ? Ops

Dev

Agile

+

Agile

• Virtualisation des applications • Intégration continue • Flexibilité au niveau de production 12

Pourquoi la virtualisation des application

Comment assurer des tests de Plusieurs application différentes ? Comment gérer les dépendances de plusieurs application ?

Avec un même Système 13

Pourquoi l’intégration continue

Comment gérer des demandes fréquentes de test et de mise en production ? Minimiser le temps de livraison de l’application? Comment identifier les bugs au plutôt

Avec des sprints très courts (micro-services) 14

Pourquoi la Flexibilité au niveau de production

Comment optimiser la gestion des ressources au niveau production? Comment assurer un niveau de disponibilité élevé?

Avec des demandes variables 15

DevOps : défintion

16

DevOps : quelques outils et produits

17

Partie 1 Docker: virtualisation des applications (processus)

18

Des concepts utiles (1/4) Les containers Linux : qu’est ce que c’est ?

19

Des concepts utiles (2/4) Les containers Linux : Namespaces

20

Des concepts utiles (3/4) Les containers Linux : Control Groups (cgroups)

21

Des concepts utiles (4/4) Virtualisation: VM Vs. Container

22

Présentation de la plateforme Docker Définition •

Docker est un projet open-source qui automatise le déploiement d'applications à l'intérieur des conteneurs de logiciels.

•

Plate-forme légère, ouverte et sécurisée.

•

Fournir une couche supplémentaire d'abstraction et d'automatisation de la virtualisation au niveau du système d'exploitation sous Linux.

•

Fonctionne sur des machines de développement Windows ou Mac (avec une machine virtuelle).

•

S'appuie sur les «images » et les « containers ».

•

Fonctionne en mode natif sur Linux ou Windows Server.

23

Architecture de la plateforme Docker (1/4) Architecture Client / serveur

24

Architecture de la plateforme Docker (2/4) Docker Client

25

Architecture de la plateforme Docker (3/4) Docker Daemon

26

Architecture de la plateforme Docker (4/4) Docker Registry

• Un registre qui stocke des images Docker. • Docker Hub est un registre public que tout le monde peut l’utiliser. •

27

Docker est configuré pour rechercher des images sur Docker Hub par défaut. Vous pouvez même gérer votre propre registre privé.

Les containers avec Docker Définition

28

Les containers avec Docker Création d’un container : isolation des ressources

29

Les containers avec Docker Création d’un container : sélection d’une image

30

Les containers avec Docker Création d’un container: téléchargement de l’image « hello world »

31

Les containers avec Docker Création d’un container avec l’image « Hello world »: exécution

32

Les containers avec Docker Création d’un container : mode interactif

33

Les containers avec Docker Création d’un container : Foreground Vs Backgroud

34

Les containers avec Docker Création d’un container : publication d’un port

35

Les containers avec Docker Création d’un container : publication d’un port

36

Les containers avec Docker Création d’un container : Bind-mount

37

Les containers avec Docker Création d’un container : Bind-mount – définition

38

Les containers avec Docker Création d’un container : Bind-mount - socket var/run/docker.sock (1/4)

39

Les containers avec Docker Création d’un container : Bind-mount - socket var/run/docker.sock (2/4)

40

Les containers avec Docker Création d’un container : Bind-mount - socket var/run/docker.sock (3/4)

Dr. A.Badreddine

41

Les containers avec Docker Création d’un container : Bind-mount - socket var/run/docker.sock (4/4)

42

Les containers avec Docker Création d’un container : Bind-mount – supression d’un fichier sur la machine hôte

Dr. A.Badreddine

43

Les containers avec Docker Création d’un container : limitation des ressources

Dr. A.Badreddine

44

Les containers avec Docker Création d’un container : les droits d’un container

45

Les containers avec Docker Création d’un container : les droits d’un container

Dr. A.Badreddine

46

Les containers avec Docker Création d’un container : des options utiles

47

Les containers avec Docker Création d’un container : les commandes de base

48

Les containers avec Docker Les images Docker : définition

49

Les containers avec Docker Les images Docker : le contenu d’une image

50

Les containers avec Docker Les images Docker : Dockerfile

51

Les containers avec Docker Les images Docker : Dockerfile - exemple

52

Les containers avec Docker Les images Docker : Dockerfile – les instructions principales

53

Chaque instruction est responsable de créer une couche

Vocabulaires Docker Docker Image La base d'un conteneur Docker. Représente une application complète Docker Container L'unité standard dans laquelle le service d'application est résidé et exécuté

Docker Engine Crée, expédie et exécute des conteneurs Docker déployables sur une hôte physique ou virtuel, en local, dans un centre de données ou un fournisseur de services cloud Registry Service (Docker Hub(Public) or Docker Trusted Registry(Private)) Service de stockage et de distribution pour vos images basé sur le cloud ou sur un serveur

54

Docker in DevOps (1/3)

55

Docker in DevOps (2/3)

56

Docker in DevOps (3/3)

57

Let’s try together….!

58

Let’s try together….!

59

Let’s try together….!

60

Let’s try together….!

61

Let’s try together….!

62

Partie 2 Docker Compose & Registry

63

Docker Compose Présentation

64

Docker Compose Docker-compose.yml: structure

65

Docker Compose Docker-compose.yml: exemple

66

Docker Compose Docker-compose.yml: exemple

67

Docker Compose Docker-compose.yml: exemple

68

Docker Compose Docker-compose.yml: exemple

69

Docker Compose Docker-compose.yml: exemple

70

Docker Compose Docker-compose.yml: exemple

71

Docker Compose Docker-compose.yml: définition d’un service

72

Docker Compose Docker-compose.yml: développement/production

73

Docker Compose Le binaire Docker-compose

74

Docker Compose Le binaire Docker-compose

75

Docker Compose Service discovery

76

Docker Compose

77

Annexes

78

Les containers avec Docker Création d’un container : les commandes de base - ls

79

Les containers avec Docker Création d’un container : les commandes de base - inspect

Dr. A.Badreddine

80

Les containers avec Docker Création d’un container : les commandes de base - inspect

81

Les containers avec Docker Création d’un container : les commandes de base - logs

82

Les containers avec Docker Création d’un container : les commandes de base - exec

Dr. A.Badreddine

83

Les containers avec Docker Création d’un container : les commandes de base - stop

84

Les containers avec Docker Création d’un container : les commandes de base - stop

85

Les containers avec Docker Création d’un container : les commandes de base - rm

86

Les containers avec Docker Création d’un container : des alias utiles

Dr. A.Badreddine

87

Les containers avec Docker Création d’un container : des alias utiles

88

Les containers avec Docker DockerFile : ENV

89

Les containers avec Docker DockerFile : COPY/ADD

90

Les containers avec Docker DockerFile RUN

91

Les containers avec Docker DockerFile: EXPOSE

92

Les containers avec Docker DockerFile: VOLUME

93

Les containers avec Docker DockerFile: USER

94

Les containers avec Docker DockerFile: HEALTHCHECK

95

Les containers avec Docker DockerFile: ENTRYPOINT/CMD

96

Partie 2

Jenkins: Intégration continue

97

C’EST QUOI?

98

C’EST QUOI?

99

A quoi cela sert-il ?

•

A intégrer de façon continue les modifications apporté au logiciel • A effectuer systématiquement : 1. La compilation 2. Test 3. Du reporting (vérification du code) 4. Le déploiement

100

Pourquoi

Pour améliorer la qualité du code et de l’application • Pour détecter au plus tôt 1. Les problèmes de compilation 2. Les régressions 3. La vérification de la qualités

101

Principe

102

Git Flow

103

GIT Flow

104

Branches develop et master

105

Branches develop et master

106

Branches de fonctionnalité

107

Terminer une branche de fonctionnalité

108

Branches de livraison

109

Branches de livraison

110

Branches de livraison

111

Branche Hotfix

112

Branche Hotfix

113

Résumé

114

Intégration continue

115

Jenkins Pipeline

• •

116

Jenkins Pipeline est une combinaison de tâches permettant de fournir des logiciels en continu en utilisant Jenkins. Un pipeline Jenkins se compose de plusieurs états ou étapes, et ils sont exécutés dans une séquence l'un après l'autre. JenkinsFile est un simple fichier texte utilisé pour créer un pipeline sous forme de code dans Jenkins. Il contient du code en langage spécifique au domaine Groovy (DSL)

Jenkins Pipeline

Il existe deux façons de créer un pipeline à l'aide de Jenkins. • Déclaratif - une nouvelle façon de créer Jenkins Pipeline. Ici, vous écrivez du code groovy contenant des blocs «pipeline», qui est archivé dans un SCM (Source Code Management) • Scripté - manière d'écrire du code groovy où le code est défini à l'intérieur de blocs «noeud».

117

Jenkins Pipeline Les scripts Pipeline apportent les grandes notions suivantes : • un pipeline est l’ensemble du processus à exécuter ; • un nœud (node) représente un environnement pouvant exécuter un pipeline (une machine esclave) ; • un niveau (stage) représente un ensemble d’étapes de votre processus (par exemple, la récupération des sources, la compilation…) ; • une étape (step) représente ce qu’il y a à faire à un moment donné (l’action à proprement parler, comme make).

118

Pipeline scripté

119

Pipeline declarative

120

Intégration continue

121

Partie 3

Docker Swarm: Flexibilité au niveau de production

122

Rappel : des microservices aux conteneurs…

123

123

Rappel : des microservices aux conteneurs… •

Principe des architectures microservices : diviser pour mieux scaler

•

Un des intérêts principaux de Docker et des conteneurs en général est de: • Favoriser les architectures microservices • Permettre la scalabilité horizontale des

applications en multipliant les conteneurs.

124

124

Rappel : des microservices aux conteneurs…

125

125

Rappel : des microservices aux conteneurs… Et maintenant ? On a un problème ?

126

126

Rappel : des microservices aux conteneurs… A partir d’une certaine échelle, il n’est plus question de gérer les serveurs et leurs conteneurs à la main !

U n e seul e sol uti on ...

127

127

Et bien d’autres problèmes… Comment identifier les services?

Comment gérer la multiplication du nombre de composants à déployer? Comment assurer la communication entre conteneurs pouvant changer de machine à tout moment ?

Que se passe-t-il si deux conteneurs nécessitent l'exécution du même port? Comment pouvons-nous nous assurer que les services fonctionnent toujours et qu'ils ont toujours suffisamment de ressources ? Comment gérer les mises à jour de vos composants? Comment gérer les containers arrêtés suite à une erreur?

Comment gérer les mises à l'échelle (scale up/down)? Comment s'assurer de ne pas surcharger une machine et d'en négliger une autre?

Comment gérer les pannes des hosts? Comment gérer la maintenance de vos hosts? 128

128

Le besoin d’un outillage dédié à l'écosystème Docker Problèmes • Comment identifier les services? • Comment assurer la communication entre conteneurs pouvant changer de machine à tout moment?

Solution

Service discovery

• Comment pouvons-nous nous assurer que les services fonctionnent toujours et qu'ils ont toujours suffisamment de ressources ?

High availability

• Comment puis-je être sûr que le conteneur fonctionnera correctement avec les ressources nécessaires ? • Comment s'assurer de ne pas surcharger une machine et d'en négliger une autre? (partage de ressources)

Resources management

• Que se passe-t-il si deux conteneurs nécessitent l'exécution du même port? • Ont-ils besoin de fonctionner sur des machines différentes ou peuvent-ils coexister?

Port management

Docker ne peut être implémenté qu'avec une solution d'orchestration ! 129

129

Fonctionnalités d’une solution d’orchestration Problématique : gérer la scalabilité d'un ensemble de conteneurs sur plusieurs machines / hôtes entre plusieurs clusters.

➢Les solutions d'orchestration résolvent ce problème et embarquent un ensemble d'outils et de composants pour faciliter la gestion des applications conteneurisées mais aussi pour assurer certaines fonctionnalités telles que l'équilibrage de charge, le scaling, la découverte de services, les mises à jour à chaud, le health-checking etc. Fonctionnalités d’une solution d’orchestration Container management (scheduling) • •

Host/cluster management

Sélectionne l'hôte approprié selon la stratégie établie.

•

Gestion des groupes d'hôtes et des conteneurs

•

Ajout, suppression d’un hôte d'un cluster

Définit comment le conteneur doit être exécuté sur un nœud disponible.

•

Informations sur l'état de l'hôte et de ses conteneurs (healths reports)

•

Démarrer ou arrêter un processus

Provisioning

•

Allocation automatique des ressources nécessaires en fonction de la demande et de la configuration

Monitoring Service discovery

130

130

Container Scheduling - déploiement

deploy Scheduler

A

C

131

B

131

Container Scheduling - déploiement

Scheduler

A

deploy

C

132

B

132

Container Scheduling - scaling

scale Scheduler

A

C

133

B

133

Container Scheduling - scaling

Scheduler

A

scale

C

134

B

134

Vue globale Docker + Orchestrateur Project Teams Development

Orchestrateur Manager Cluster out of production

YAML

+

1 app

Manager Cluster in production

Binary repository (Nexus, ...)

Publication

1 Docker file per image to build

Deployment & Execution (RUN)

Server 1 Container Engine and cluster node

Out-of-production servers Server 2 Container Engine and cluster node

Server 3 Container Engine and cluster node

Deployment descriptor

1 Descriptor per app

Sources repository (

Server 4

1 application package

YAML

Images repository (Registry)

Production servers

+

+ Applicative code

Container Engine and cluster node YAML

, …)

+

Publication N Images Containe r

Construction (BUILD)

Application Container Instance in "Docker" Format

Image YAML

135

Application Descriptor (yaml)

+ Applicative code

N times

Dockerfile

135

Différents Orchestrateurs existent sur le marché… •

Kubernetes

•

Docker Swarm Mesos + Marathon Rancher

•

Nomad

•

Titus (Mesos + Mantis [scheduling/job mgmt] + Titan)

•

Mantl (Mesos + Marathon and Kubernetes) Openshift V3 (Kubernetes)

•

CloudFoundry

•

...

136

136

Container-as-a-Service: comparaison des fournisseurs Critère de sélection General Availability (GA) Base technique (performance) Mémoire des objets Outil standard pour l‘orchestration Administration de la plateforme de conteneurs

Amazon EC2 Container Service (ECS) Avril 2015

Google Container Engine (GKE)

Août 2015 Nouds et clusters de Google Instances EC2 Compute Engine (GCE) Amazon S3 (Simple Storage Service) Google Cloud Storage Outil de gestion propriétaire

Kubernetes

ECS-GUI et CLI

Gestion de clusters via Google Cloud Gestion des conteneurs via le tableau de bord de Kubernetes

Formats de conteneurs pour les Docker-Container Docker-Container systèmes de production Un Overlay-Networking Fonctions réseau via libnetwork n’est pas pris en Réseau basé sur Kubernetes charge Intégration avec des systèmes Assistance Docker-Volume (avec des Kubernetes Persistent Volume de stockage externes pilotes limités) Docker Registry Docker Registry Registry Amazon EC2 Container Registry Google Container Registry Gestion des identités et des Oui Oui accès Prise en charge Cloud hybride Non Oui Enregistrement et surveillance Oui Oui Mise à l’échelle automatique Oui Oui Elastic Load Balancing, Elastic Block Cloud IAM Store Intégration avec d’autres Stackdriver Monitoring Virtual Private Cloud, AWS IAM, services Cloud Stackdriver Logging AWS CloudTrail, AWS Container Builder CloudFormation Exploitation de conteneurs sur des clusters standard jusqu’à cinq ECS est un service gratuit. Les nœuds : gratuit utilisateurs ne paient que les Coûts Opération conteneurisée sur des ressources utilisées par la plateforme clusters standard avec six nœuds Cloud AWS. ou plus : facturation forfaitaire par 137 cluster par heure

Microsoft Azure Container Service (ACS) Avril 2016 Machines virtuelles et groupes d’échelles pour les machines virtuelles Blob Storage Outils open source au choix : Mesos, Swarm, Kubernetes

IONOS Container Cluster Janvier 2018 VM de la plateforme IONOS laaS Non Kubernetes

Gestion des clusters via Azure Gestion des conteneurs via DockerTools

Via IONOS Cloud Panel

Docker-Container

Docker Container

Overlay-Networking via libnetwork et Container Network Model (CNM) Docker Volume Driver via Azure File Storage Docker Registry Azure Container Registry

Réseau sur la base de Kubernetes

Kubernetes Cloud Backup Docker Registry

Oui

Non

Oui Oui Oui Azure-Portal, Azure Resource Manager (ARM) Azure Active Directory, Azure Stack Microsoft Operations Management; Suite (OMS)

Oui Oui Oui Intégration dans la plateforme IONOS laaS

L’utilisation d’ACS est gratuite. Les utilisateurs ne paient que pour les Pilotage centrale via le ressources utilisées par la plateforme IONOS Cloud Panel de cloud computing sous-jacente Azure.

137

Focus sur Docker SWARM

138

138

Docker Swarm • Swarm est l’outil de gestion et d’orchestration natif développé par Docker Inc. autour du Docker engine pour déployer et orchestrer des clusters Docker. ✓ Gestion centralisée de plusieurs hôtes docker == transformer un ensemble d’hôtes Docker en un unique hôte virtuel Docker ✓ Exécution de conteneurs sur plusieurs machines et haute-disponibilité

• Depuis 2017 (v > 1.12), Docker Swarm est intégré directement dans le docker engine, on parle de Swarm mode de Docker.

• Docker Swarm est donc facile à mettre en place et intégré au workflow docker ✓ Il s’intègre très bien avec les autres commandes Docker classiques (on a même pas l’impression de faire du clustering). ✓ Swarm utilise l’API standard du Docker Engine ✓ Il permet de gérer de très grosses productions Docker. 139•

SWARM vous permet de vous concentrer sur le développement votre application et de ne pas vous

•

3000 commits

•

71 contributeurs

•

Développé en Go

•

Géré par Docker Inc

139

Architecture de Docker Swarm ▪ Un Swarm est un groupe de machines exécutant le moteur Docker et faisant partie du même cluster. ▪ Quand des machines rejoignent un Swarm, elles sont appelés nœuds. On a des Noeuds Manager et Worker pour une architecture “maitre/esclaves”

Docker deamon node-1

Docker deamon node-2

Docker deamon node-3

▪ Docker Swarm vous permet de lancer des commandes Docker auxquelles vous êtes habitué sur un cluster depuis la machine maître Swarm Manager. ▪

Noeuds Workers : noeuds chargés de faire tourner les conteneurs. Ils ne sont là que pour fournir de la capacité et n'ont pas le pouvoir d'ordonner à une autre machine ce qu'elle peut ou ne peut pas faire.

▪

Nœud Managers : seules machines du Swarm pouvant exécuter des commandes Docker et autoriser d’autres machines à se joindre au Swarm en tant que workers.

NB : les noeuds Manager et Worker sont en fait identique c’est leur rôles qui varient. On peut prendre un noeud Worker et le promouvoir en manager et inversement.

140

Le cluster de machines hébergeant docker Engine sont connectées par un réseau Overlay

140

Dans le vocabulaire de SWARM : Services et Tasks ▪ Dans le vocabulaire Swarm nous ne parlons plus vraiment de conteneurs mais plutôt de services = description du comportement et état souhaités pour vos conteneurs. ➢ ➢

Une fois le service lancé, une tâche est alors attribuée à chaque nœud afin d'effectuer le travail demandé par le service Tous les services sont constamment monitorés par Swarm, il compare en permanence l'état désiré avec l'état actuel. Si il y a un écart, Swarm entreprend les actions correctrices dans les plus brefs délais !!

▪ Un service décrit donc le comportement et état pour un conteneur : ✓ ✓ ✓ ✓ ✓ ✓

Le nom de l'image et le tag que les conteneurs du nœud doivent exécuter. Combien de conteneurs participent au service. Les ports à exposer à l'extérieur du cluster Swarm. Comment doit agir le conteneur suite à une erreur. Les caractéristiques des nœuds sur lesquels le service peut s'exécuter (telles que des contraintes de ressources et ou de préférence de placement sur tel ou tel nœud). Etc.

▪ Toutes les opérations de scaling, rolling upgrades ou rollbacks se feront sur les services

141

141

SWARM : Services et Tasks ▪

Illustration du processus de déploiement des conteneurs d’une applications Web dans un Cluster Swarm. 1.

Créer un service consiste à spécifier quelle image sera utilisée et quelles seront les caractéristiques et les états de vos conteneurs qui seront en cours d'exécution. a. Les conteneurs se baseront sur l'image httpd b. 3 conteneurs minimums afin de supporter les charges de travail c. Une utilisation maximale de 100 Mo de mémoire pour chaque conteneur d. Le port 8080 sera mappé sur le port 80 e. Redémarrer automatiquement les conteneurs s'ils se ferment suite à une erreur

142

2.

Par la suite quand vous exécuterez votre service la demande sera ensuite envoyée au manager Swarm (leader) qui planifie l'exécution du service sur les nœuds

3.

Chaque nœud se voit assigné une ou plusieurs tâche(s) jusqu'à satisfaire les besoins définit par votre service.

4.

Chaque tâche aura un cycle de vie, avec des états comme NEW, PENDING, COMPLETE gérés par le manager qui va jouer un vrai rôle de chef d’orchestre

5.

Un équilibreur de charge sera mis en place automatiquement par votre manager afin de supporter les charges de travail

142

Services globaux Vs répliqués Swarm supporte deux modes dans lesquelles les services Swarm sont définis : ▪Replicated (Services répliqués): un service répliqué s’exécute avec un un nombre de répliques défini par l’utilisateur. Chaque réplique est une instance du conteneur Docker défini dans le service. Les services répliqués peuvent être mis à l’échelle en créant des répliques supplémentaires. Par exemple, un serveur Web comme NGINX peut être mis à l’échelle à 2,4 ou 100 instances avec une seule ligne de commande.

▪Global (Services globaux) : lorsqu’un service s’exécute en mode global, chaque nœud disponible dans le cluster démarre une tâche pour le service correspondant (autrement dit si la tache consiste à créer un conteneur il y en aura un sur chaque nœud…). Lorsqu’un nouveau nœud est ajouté au cluster, le manager Swarm lui assigne immédiatement les tâches des services « Global »

143

Des similarités avec Docker-Compose…?! Similarités

1. Ils prennent tous les deux en entrée fichiers YAML de description de votre stack 2. Ils gèrent tous les deux les applications multiconteneurs (architectures microservices) 3. Ils ont tous deux un paramètre « scale » permettant d'exécuter plusieurs conteneurs de la même image, ce qui permet à votre microservice de se mettre à l'échelle horizontalement 4. Ils sont tous deux gérés par la même société, à savoir Docker, Inc.

144

Différences

1. Docker Swarm est utilisé pour mettre à l’échelle (scaling) votre application multi-conteneurs sur un ou plusieurs serveurs hôtes Docker alors que Docker-compose se limite à un seul hôte Docker (beaucoup plus utile pour tester la scalabilité dans des environnements de développement / tests…) 2. Swarm offre des mécanismes de haute disponibilité et de tolérance aux pannes avancés 3. Les commandes de Docker Swarm sont intégrés dans le CLI Docker, elles font partie du binaire Docker (projet en GO) à l’inverse de Docker-Compose qui est un binaire indépendant/autonome (projet en Python).

Architecture recommandée pour Docker Swarm ▪

Afin d’assurer une architecture en haute-disponibilité pour votre cluster SWARM il est fortement conseillé de mettre en place 3 managers

▪

Lorsque le cluster possède plusieurs managers , un seul (le leader) gère la configuration du cluster et les autres (followers) sont disponibles pour remplacer le leader en cas de défaillance (raft consensus)

▪

La configuration et l’état de Swarm sont maintenu dans une database distribuée (etcd) stockée sur chaque Manager mais le statut est géré par le « leader »

▪

Automatisation de la sécurité avec Docker SWARM puisque “out-of-the-box” vous avez une application qui gère automatiquement le protocole TLS pour le chiffrement des communication et la gestion des nœuds autorisés ▪ ▪ ▪

▪

145

La rotation des certificats entre les différents nœuds est automatique dans Swarm et s'effectue tous les 90 jours. Le manager ou le leader dans le cas ou nous avons plusieurs managers sera considéré comme "le root CA". Si vous suspectez que les certificats de un ou plusieurs de vos noeuds ont été compromis vous pouvez les révoquer très simplement.

L’ouverture des ports suivantes doit être effectuée sur chaque hôte : •Port TCP 2377 pour les communications de gestion du cluster (communication des nœuds avec le manager) •Port TCP et UDP 7946 pour la communication entre les nœuds •Port UDP 4789 pour le trafic du réseau de superposition (network overlay)

145

TPs : premiers pas avec Docker SWARM

146

146

Création d’un cluster Swarm : création des nœuds et activation du mode swarm Réutiliser Docker Machine pour créer deux VMs avec le driver virtualbox nommées mymanager et worker : docker-machine create --driver virtualbox mymanager docker-machine create --driver virtualbox worker

Récupérer les IPs de ces nouvelles machines à l'aide de la commande : docker-machine ls

Activer le mode Swarm sur la machine Docker mymanager (nous utilisions des commandes Docker en ssh afin de les exécuter sur le nœud manager) :

docker-machine ssh mymanager "docker swarm init --advertise-addr 192.168.99.100"

Votre cluster Swarm est prêt à accueillir de nouvelles machines. De plus, le résultat nous indique comment rajouter un nœud (worker ou manager) à notre Swarm et décrit le Token Worker d’accès au cluster ainsi que l’adressee sous laquelle le Swarm Manager est disponible (port 2377 du management)

147

147

Création d’un cluster Swarm : joindre une machine au cluster Swarm Pour ajouter un travailleur à un swarm, exécutez la commande suivante : docker-machine ssh worker "docker swarm join --token SWMTKN-1-1a29tk2imc4mrg2756n5nzytwt4da7sdh80lcj73cfaf7s9nwn8lfgyilxjy6l8l2704qy8oczr 192.168.99.100:2377"

Voici la commande qui permet d'afficher les différents nœuds de votre Swarm : docker-machine ssh mymanager "docker node ls"

Rappel : seuls les managers du Swarm comme mymanager exécutent les commandes Docker, les workers ne sont là juste pour fournir de la capacité.

Vous venez de créer votre premier cluster Swarm !

148

Création d’un cluster Swarm : configurer le shell de notre manager Swarm Charger les variables d'environnements de notre leader Swarm sur notre shell courant, dès lors toutes les prochaines commandes docker lancées depuis le shell courant s'exécuteront directement sur la machine mymanager. Pour cela récupérer les variables d'environnements de notre nœud mymanager : docker-machine env mymanager

La commande suivante, permet de configurer votre shell pour lui permettre de communiquer avec le nœud mymanager :

eval $(docker-machine env mymanager) Vérifier que c'est bien le nœud mymanager qui est actif : docker-machine active

Dorénavant, plus besoin de lancer vos commandes en ssh depuis votre shell courant pour communiquer avec le nœud mymanager.

149

Déployer une app à service individuel avec Docker Service - créer un service La commande docker service est utilisée lors de la gestion d'un service individuel dans un cluster Swarm. Donc si on souhaite spécifier les comportements suivants : • • • • •

Un conteneur qui se base sur l’image apache (httpd) Trois conteneurs doivent être exécutés au minimum. Redémarrez le conteneur s'il se ferme suite à une erreur. Limiter l'utilisation de la mémoire à 100 Mo Mapper le porte 5001 sur le port 5000

Ci-dessous la commande qui crée un service avec ses options respectant les caractéristiques définis plus haut : docker service create --name httpdc \ --replicas 3 \ --publish published=5001,target=5000 \ --restart-condition=on-failure \ --limit-memory 100M \ httpd

NB : si vous remplaçez « --replicas 3 » par « --mode global » vous définissez alors un service de type « Global »

Vérifier l'état d'avancement du service dans votre Swarm en lançant la commande suivante :

docker service ls

vous pouvez considérer que la commande docker service est semblable à la commande docker run … 150

Déployer une app à service individuel avec Docker Service Vous pouvez lister les différentes tâches de votre service afin de vérifier par exemple sur quel nœud s'est exécutée votre tâche : docker service ps httpdc

Ici nous avons 2 répliques dans le nœud worker et une seule réplique dans le nœud manager (cela aurait pu être l’inverse). Et nos 3 conteneurs qui tournent au sein du cluster Swarm bénéficient d’un load-balancing géré automatiquement par Swarm == ils sont appelés de manière aléatoire grâce à l'équilibreur de charge mis en place par Swarm.

Afficher l'ID des conteneurs des 2 nœuds : docker ps docker-machine ssh worker "docker ps"

151

Déployer une app à service individuel - mettre à l’échelle un service (scaling) Voici la commande qui permet de scaler automatiquement vos conteneurs sans les redémarrer : docker service scale httpdc=5

NB : les 2 commandes suivantes via update permettent de faire la même chose

Vérifier le nombre de tâches de nos nœuds afin de s'assurer du nombre de répliques docker service ps httpdc

Nous avons bien cinq répliques et non plus trois…

152

docker service update --replicas=5 httpdc docker service update –replicas 5 httpdc

Déployer une app à service individuel - mettre à jour et supprimer un service Il est possible de mettre à jour votre application depuis votre nouvelle image sans interruption de service. Je vais simuler une nouvelle version de notre application en changeant le tag de l’image présente dans le Docker Hub : docker service update --image httpd:alpine httpdc

Sans aucune interruption de service, nous avons pu mettre à jour nos conteneurs déployés sur différents nœuds et ceci depuis une seule commande !

Voici la commande qui permet de supprimer un service si vous n’en avez plus besoin : docker service rm httpdc

153

Déployer une app à service individuel - mettre à jour et supprimer un service

Il est possible de définir des configurations plus élaborées avec par exemple un délais de mise à jour du service sur les nœuds avec la commande : docker service update [OPTIONS] --update-parallelism N --update-delay T service On définit un rolling upgrade qui mettra les tâches à jour N par N toutes les T secondes.

• --update-parallelism uint : Maximum number of tasks updated simultaneously (0 to update all at once)

Par exemple :

• --update-delay duration : Delay between updates (ns|us|ms|s|m|h)

docker service update --update-parallelism 2 --update-delay 15s httpdc

154

154

Déployer une application multi-services avec Docker stack Docker Stack peut être utilisée pour gérer une application multi-services dans votre cluster Swarm (comparable à la commande docker-compose de Docker Compose qui permettait de déployer des applications multi-conteneurs pour rappel…) Commençons par définir les différentes caractéristiques de nos conteneurs : • • • • •

Deux API sous forme de deux services différents. Trois conteneurs par service doivent être exécutés au minimum. Redémarrez les services s'il se ferme suite à une erreur. Limiter l'utilisation de la mémoire à 50 MO. La première API écoute sur le port 5000 mais la deuxième API utilise le port 5001 comme port cible et le port 5000 comme port source.

Pour créer nos services on réutilise le même type de fichier .yml vu précédemment dans le chapitre Docker Compose, donc créons un fichier docker-compose.yml

Voici la commande qui permet de déployer votre application multi-services dans votre Swarm == votre stack « api-app »: docker stack deploy -c docker-compose.yml api-app

155

Vérifier le statut des 2 services crées via la commande :

version: "3.8" services: api1: image: hajdaini/flask:api1 deploy: replicas: 3 resources: limits: memory: 50M restart_policy: condition: on-failure ports: - "5000:5000" api2: image: hajdaini/flask:api2 deploy: replicas: 3 resources: limits: memory: 50M restart_policy: condition: on-failure ports: - "5001:5000"

docker stack services api-app

155

Une confusion qui s’installe en Docker-compose et swarm ☺ ? ▪

Les 2 commandes se ressemblent certes et prennent en input le même fichier docker-compose.yml….

docker-compose –f docker-compose.yml up docker stack deploy -c docker-compose.yml somestackname

… les 2 commandes vont mettre en place les services décrits dans les fichiers docker-compose.yml, les volumes, les réseaux etc… alors en quoi « docker stack » diffère-t-il de « docker-compose » ? Quelques différences à (re)avoir en tête : – Docker stack ignore les instructions de “build”. Vous ne pouvez pas créer de nouvelles images à l'aide de cette commande. Docker stack a besoin d'images pré-construites pour exister. Ce qui fait que docker-compose est mieux adapté aux scénarios de développement/tests. – (rappel) la fonctionnalité Docker Stack est incluse avec le moteur Docker (mode swarm activé), vous n'avez pas besoin d'installer de packages supplémentaires pour l'utiliser comme pour Docker-compose – / ! \ Docker stack ne prend pas en charge les fichiers docker-compose.yml qui sont écrits selon la spécification de la version 2 mais uniquement à partir de la version 3 (la plus récente). Docker Compose peut toujours gérer les versions 2 et 3 sans problème.

156

Déployer une application multi-services avec Docker stack Lister les différentes tâches dans votre Swarm avec la commande suivante : docker stack ps api-app

Nous avons bien deux services distincts avec trois répliques pour chaque service ! Pour accéder à nos services on peut utiliser soit l'adresse IP du nœud mymanager ou l'IP du nœud worker : curl http://192.168.99.100:5000/api1 curl http://192.168.99.100:5001/api2 Voici la commande qui permet de supprimer une Stack si vous n’en avez plus besoin :

docker stack rm api-app

157

NB : si vous rajoutez une nouvelle machine dans votre Swarm, il suffit de relancer la commande docker stack deploy pour que votre application tire parti des nouvelles ressources de votre nouveau nœud.

157

Inspecter un nœud, drainer un nœud Vous pouvez inspecter les nœuds à tout moment via la commande d’inspection de nœud docker node inspect worker Si le nœud est ACTIF, il est prêt à accepter des tâches provenant du maître, c’est-à-dire le manager. Par exemple vous pouvez voir la liste des nœuds et leur statut en entrant la commande suivante sur le nœud manager : docker node ls

Lorsqu’un nœud est actif (READY), il peut recevoir de nouvelles tâches mais parfois vous devez mettre le nœud en « pause » pour des raisons de maintenance et cela revient à mettre le nœud en mode « DRAIN » docker node update --availability drain worker

158

Si vous faites un état de processus pour le service vous pouvez voir que les conteneurs sur le worker (que vous avez demandé à être drainé) sont reprogrammés sur d’autres « workers » et dans notre cas il n y a que le manager

Memo commandes # Activer le mode Swarm docker swarm init # Joindre une machine au cluster Swarm docker swarm join --token :

# Gestion du cluster Swarm docker swarm # Gestion des conteneurs uni-service docker service # Gestion des conteneurs multi-services docker stack

# Créer un service docker service create --name : nom du service --replicas : nombre de tâches --publish published=,target= : mapper un port --restart-condition= : condition de redémarrage en cas d'erreur --limit-memory : limiter l'utilisation de la mémoire --limit-cpu : limiter l'utilisation du CPU # Visualiser l'état d'avancement de vos services Swarm docker service ls # lister les différentes tâches de votre service docker service ps # Mise en échelle des répliques de votre service docker service scale =

# Gestion des nœuds docker node

# Mise à jour de des conteneurs de votre service docker service update --image :

# Lister les différents nœuds de votre Swarm docker node ls

# Supprimer un service docker service rm

# Inspecter un nœud docker node inspect

# Ajouter / supprimer un secret à un service existant docker service update --secret-add secret_name service_name service --secret-rm secret_name service_name #docker Déployer uneupdate nouvelle pile ou met à jour une pile existante

# Retirer un nœud de votre Swarm (ne supprime pas la VM) docker node rm # mettre un nœud de votre Swarm en Drain Mode docker node update –availabiblity drain worker # réactiver un nœud de votre Swarm qui était en Drain Mode docker node update --availability active worker

159

docker stack deploy -c # Lister tous les services de votre pile docker stack services

# Répertorier les tâches de la pile docker stack ps # Supprimer tous les services de votre pile docker stack rm # Lister le nombre de services de votre pile docker stack ls

159

Bénéfices de Docker et son écosystème …

160

160

Conclusion – synthèse des principaux bénéfices de Docker Agilité

Portabilité

• Réduction du time to market • Disparition du problème « chez moi, ça marche »

Cycle de déploiement d’un conteneur

• Plus de flexibilité pour les Devs et de stabilité pour les Ops • Une gestion l’infrastructure simplifiée

Utiliser Docker pour builder et/ou exécuter des applications

de

Conteneur App 1

Build

Conteneur App 3

App 2

Bins/libs

Bins/lib s

Conteneur Engine

Optimisation

Serveur PHY ou VM

• Compatibilité avec du cloud public ou privé, serveur physique ou virtuel

Ship

Intégrer Docker dans le process d’intégration continue et homogénéiser les environnements (dév, recette, prod)

Docker : un standard • Une grande communauté autour de la technologie Docker

• Un faible overhead : une baisse de la consommation de RAM 4 à 30 fois

161

• Migration d’une plateforme à une autre de manière transparente et indépendamment de la configuration des serveurs

OS hôte

• Rationalisation des coûts (moins de licences et d’OS)

• Des mises à jours simplifiées et sans temps d’arrêt

• Facilite l’hybridation

Run Déployer des services avec une scalabilité accrue en implémentant une solution d’orchestration

• Une évolution rapide : une adoption multipliée par 5 entre 2014 et 2015 • Adopté par les plus grands acteurs du Cloud

161

L’écosystème Docker en 1 illustration…

162

162

L’écosystème Docker en 1 illustration…

163

163

Bonnes pratiques Docker … en complément des recommandations de sécurité

164

164

Les principales bonnes pratiques Docker…(1/3) Le DockerFile doit être considéré comme un fichier source et donc versionné •

Le DockerFile est un document qui décrit le contenu structuré d'une image Docker et donne l'emplacement des sources utilisées. Il doit donc être versionné afin d'assurer la traçabilité des modifications apportées et stocké dans un outil de versionnage (ex : SVN)

Vous ne ferez pas de modification sur un conteneur •

Les conteneurs sont des instances éphémères de l'application, qui peuvent être arrêtées ou redémarrées n'importe où et à tout moment. Toute modification de l'application doit être effectuée sur l'image qui sert de modèle pour le conteneur.

Préférez, sur le long terme, le BUILD automatique d’images •

Il est recommandé d'utiliser le manuel BUILD uniquement au début de l'installation de Docker pour se faire la main. Le BUILD automatique doit être mis en place assez rapidement pour assurer la standardisation des versions de Docker utilisées pour construire les images (ex : via un serveur d’intégration continue comme Jenkins)

Utilisez des tags pour toutes les images produites. •

•

165

Les tags Docker vous permettent d'ajouter des informations supplémentaires à une image et de faciliter la recherche d'une image dans un registre d'images. Il est donc recommandé de marquer chaque nouvelle image créée avec la version de l'image produite. Par défaut, si aucune balise n'est spécifiée, la balise « latest » est ajoutée à l'image.

165

Les principales bonnes pratiques Docker…(2/3) Définissez une checklist de validation d'image / DockerFile et déroulez-la pour chaque nouvelle image créée. •

Objectif : s'assurer du respect des contraintes définies par l'organisation (sécurité, nomenclature, politique de droit d'accès, etc.).

Validez les images externes avant utilisation, quel que soit l'environnement (dev., Rec., Prod., Etc.) •

Les équipes doivent s'assurer que les images externes sont conformes au niveau d'exigences de sécurité de l'organisation, que les équipes pourront garder un contrôle total sur l'image et ses mises à jour, sont configurables selon les besoins

Référencez toutes les images dans un seul registre et mettre en œuvre Content Trust •

Toutes les images, qu'elles aient été construites en interne (images privées) ou extraites d'une source externe et validées par des équipes internes, doivent être référencées dans un registre unique permettant de centraliser et faciliter la gestion du cycle de vie des images (mise à disposition, publication etc.)

Reconstruisez régulièrement les images pour intégrer les correctifs d'évolution et de sécurité. •

166

Chaque nouveau patch doit aboutir à la génération d'une nouvelle image, une fois référencée, la nouvelle image peut être déployée dans un nouveau conteneur pour remplacer la version précédente (via Rolling update).

166

Les principales bonnes pratiques Docker…(3/3) Vos conteneurs seront stateless •

Cela signifie qu'ils ne stockeront pas des informations qui doivent persister. Le conteneur peut être arrêté à tout moment et les informations qu'il a stockée seront perdues. Si un conteneur doit stocker des informations, elles doivent se trouver dans un stockage externe partagée par tous les autres conteneurs.

Vos conteneurs doivent être « lights » et démarreront en moins de 10 secondes •

Il s'agit plutôt d'une règle empirique et, malheureusement, dans de nombreux cas, cette règle n'est pas respectée. Mais un conteneur qui démarre en plus de 10 secondes ne vous permettra pas de profiter pleinement des avantages de la conteneurisation.

Préférez les middlewares-ready containers (nginx, nodejs, tomcat…) • •

Cad des middlewares qui s’instancient très rapidement lorsque le conteneur est déployé, consomment peu de ressources et sont de petite taille, sont adaptés au modèle de résilience basé sur une architecture distribuée, sont plutôt Open Source avec des modèles de licence adaptés à une utilisation conteneurisée Certains middlewares ne sont pas adaptés aux conteneurs pour diverses raisons (taille, licence, ...) comme JBoss, IBM WebSphere, ...

Les bases de données dites «classiques» (principalement relationnelles) ne sont pas forcement adaptées à à la conteneurisation en production •

167

C’est acceptable à des fins de développements ou tests mais les BDD doivent être Container Ready pour être conteneurisées en production. Elles doivent donc avoir les mêmes caractéristiques que les middlewares adaptés pour les conteneurs et doivent garantir leur résilience dans les architectures distribuées et conteneurisées (ex : MongoDB, Redis)

168

168

Merci de votre attention