Présentation
●
●
●
●
●
Treeptik, issue du monde Java, adopte une démarche DevOps dans son organisation et son
offre de services
Actuellement 35 salariés
Créateur du PaaS CloudUnit à destination des développeurs Java
Partenaire historique Docker depuis 2014
Treeptik intervient chez ses clients en fonction du besoin :
○ Prestations d’assistance technique
○ Formations (Certifiantes Docker, Java JEE)
○ Missions de conseil (audit, accompagnement dans l’industrialisation des
développements)
○ Missions d’expertise produit : CloudUnit, Docker Datacenter, Rancher, Atomic
Objectif de la formation
Pourquoi
Docker ?
Les cas
d’utilisation
de Docker
La montée en
compétence
technique
La Stack
applicative
Docker
3
La dream team
Personnes à impliquer sur le projet en mesure de valider la réussite du projet.
➔
Infrastructure
➔
Sécurité
➔
Développeurs
➔
Architecture
➔
Ops
4
Docker
la génèse
Avant docker...
Dotcloud fondé en 2009
Opensource Docker en 2013
Levées de fonds
Normalisation
6
Pourquoi Docker !
L’industrie logicielle a changée
Fin des grosses applications monolithiques
Micro-services
Processus de déploiements
7
L’écosystème
Official Repositories
Infrastructure & Service Providers
Networking
Dev Tools
Clustering & Scheduling
Operating Systems
Storage
Big Data
Management
Service Discovery
Security
Build / Continuous Integration
Configuration Management
8
Storage
Monitoring & Logging
Consulting &Training
8
Un problème vrai en 2017
Qui risque de l’être en 2018
9
Un problème vrai en 2017
Qui risque de l’être en 2018
10
La logistique navale
11
La logistique navale
12
La logistique navale
13
La logistique navale
14
La logistique navale
15
DockerCon Keynote Amsterdam 2014
In this keynote, Henk Kolk, Chief Architect at ING, talks about Continuous Delivery in a large
financial services company. Kolk details the business benefits of ING’s DevOps transformation
and highlights the role Docker played in speeding up innovation cycles.
https://blog.docker.com/2014/12/dockercon-europe-keynote-continuous-delivery-in-the-enterprise-by-henk-kolk-ing/
16
Les principes Unix
Chacun fait ce qu’il a à faire
Simple et composable
Ecosystème riche et concurrent
Pas de compromis
17
Un langage atypique
Héritier du C
Docker engine / client / machine...
18
Un langage atypique
Héritier du C
Docker engine / client / machine...
Protocole HTTP(S) / TLS
19
Un langage atypique
Héritier du C
Docker engine / client / machine...
Protocole HTTP(S) / TLS
Architecture REST
20
Un langage atypique
Héritier du C
Docker engine / client / machine...
Protocole HTTP(S) / TLS
Architecture REST
Cross compilation
21
Use Cases
CRÉATION, GESTION ET
DEPLOIEMENT
Image
A
Push
Docker
image
registry
Search
Pull
Source
code
repository
Dockerfile
for A
Run
Cont A
Build
Docker Engine
Docker Engine
Host 1 OS
Host 2 OS
Le container
Introduction aux containers
Un peu d’histoire...
●
●
●
La containerisation utilise le kernel du système hôte pour démarrer de multiples systèmes de
fichiers racine
Chaque système de fichier racine est appelé container
Chaque container possède ses propres processus, mémoires, carte réseau
Application
Application
Application
Bins/Libs
Bins/Libs
Bins/Libs
Docker Engine
Host OS
Server
26
Comparaison Containers / VM
Host hardware
App 3
App 2
App 1
App 3
App 1
Kernel
Docker
Engine
App 6
App 5
App 4
App 3
App 2
App 1
container
App 2
Full virtualization
Docker
containers
Guest OS
Guest OS
virt.
virt.
Hypervisor
Host OS
Host hardware
VM
And the winner is...
Great isolation but overhead
Less isolation but less overhead
Conclusion
Avantages et limitations des VM
Les bénéfices:
●
Un serveur physique est divisé en plusieurs machines virtuelles
●
Plus facile à mettre à l’échelle qu’un serveur physique
●
Modèle de Cloud et paiement à la demande (AWS, Azure, Rackspace..)
Les limitations:
●
Chaque VM nécessite une allocation de CPU, de stockage dédié, de RAM et un OS complet
●
Modèle linéaire: l’augmentation du nombre de VM nécessite des ressource supplémentaires
●
L’utilisation d’un système hôte complet entraîne une surcharge
●
La portabilité des applications n’est toujours pas garantie
29
Historique du modèle
Virtualisation de processus
●
UNIX chroot (1979-1982)
●
BSD Jail (1998)
●
Parallels Virtuozzo (2001)
●
Solaris Containers (2005)
●
Linux LXC (2008)
●
Docker (2013)
Docker est une évolution de LXC qui a permis de rendre le container utilisable par un plus grand
nombre d’utilisateurs grâce à son API et son client convivial.
30
Pourquoi utiliser les containers ?
●
Les containers sont plus légers et rapides que les VMs
●
Pas besoin d’installer un système d’exploitation complet
●
En conséquence, les besoins en CPU, RAM et stockage sont moins contraignants
●
On peut faire tourner bien plus de containers sur un serveur que de VMs
●
Le concept assure une meilleure portabilité
●
Les containers représentent une meilleure solution pour développer et déployer des
applications microservices
31
La mission de docker
La mission de Docker
32
Concepts clés du container
Docker et le noyau Linux
Le Docker Engine est l’application qui active les containers destinés à être exécutés
Il utilise plusieurs fonctionnalités “natives” du noyau Linux.
Les NAMESPACES permettent:
● l’isolation des processus et du système de fichier
● l’isolation réseau et de disposer de ses propre interfaces
Les CGROUPS (Control Groups) permettent:
● de mesurer et limiter les ressources (RAM, CPU, block I/O, network)
● de donner l’accès au différents périphériques (/dev/*)
Les règles IPTABLES permettent:
● d’assurer la communication entre containers sur le même hôte
● d’assurer d’éventuelles communication entre les containers et l’extérieur
33
Cycle de vie d’un container
Le cycle de vie d’un container diffère de celui d’une VM
A l’opposé d’une VM, le conteneur n’est pas destiné à une existence perpétuelle.
L’orchestrateur se chargera de redémarrer le container sur un autre hôte en cas de défaillance.
Cycle de vie basique d’un container:
●
Création d’un container à partir d’une image
●
Démarrage d’un container avec un processus
●
Le processus se termine et le container s’arrête
●
Le container est détruit
34
Gestion des containers Linux
Création et démarrage d’un container
Pour démarrer un container nous utiliserons la commande docker run
Cette commande effectue les deux actions suivantes:
● Crée un container en utilisant l’image spécifiée
● Démarre le container
Syntaxe: docker run [options] [image] [command] [args]
L’image est spécifiée de cette manière: repository:tag
$ docker run ubuntu:14.04 echo "hello world"
$ docker run ubuntu:14.04 ps -ef
35
Gestion des containers Linux
Lister et repérer ses containers
Pour lister les containers démarrés, nous utiliserons la commande docker ps
Le flag –a permet de lister tous les containers (y compris les containers arrêtés)
$ docker ps
$ docker ps -a
36
Gestion des containers Linux
Accès au terminal d’un container
Accéder au terminal
Utilisez les flags -i et -t flags avec la commande docker run
● Le flag -i demande à docker de se connecter à l’entrée standard STDIN du container
● Le flag -t demande l’accès à un pseudo-terminal
Note: Nous devons également démarrer un terminal comme commande par défaut (e.g. bash)
Sortir du terminal
En tapant exit nous quittons le terminal et revenons sur l’hôte mais le container est aussi arrêté.
Pour se détacher du Terminal sans arrêter le container, presser CTRL + P + Q simultanément.
Exercice:
$ docker run -i -t ubuntu:14.04 bash
$ touch test
$ ls
$ docker run -i -t ubuntu:14.04 bash
$ ls
37
Gestion des containers Linux
Containers et processus
●
Un container tourne tant que le processus
qui a été spécifié lors de son démarrage
tourne encore
●
Le processus de la commande principale
aura toujours le PID numéro 1 à l’intérieur
du container
●
Ci-contre un arbre de processus expliquant
l’héritage des processus du container visà-vis du système hôte
38
Gestion des containers Linux
Containers et processus
●
Démarrez un container Ubuntu avec un processus bash comme commande principale
●
Exécutez un ps -ef et vérifiez le PID du processus bash
●
Sortez du container sans l’éteindre avec les touches CTRL + P + Q
●
Exécutez un ps -ef | grep bash sur le système hôte et observez le processus bash
●
Notez le PID du processus parent de chaque process bash
●
Trouvez le processus parent que vous avez noté
●
Que constatez-vous ?
39
Gestion des containers Linux
Mode détaché
Ce mode permet de faire tourner un container en arrière plan
On utilisera le flag -d pour utiliser ce mode lors du lancement
Pour observer la sortie, on utilisera la commande docker logs [container id]
Exercice:
$ docker run -d centos:7 ping 127.0.0.1 –c 50
$ docker ps
Après quelques minutes:
$ docker ps
40
Gestion des containers Linux
Démarrage d’un container applicatif
Nous allons maintenant démarrer un container applicatif.
On utilisera le flag -P pour mapper les ports du container vers des ports de l’hôte
Exercice:
$ docker run -d -P nginx
$ docker ps
Rendez-vous sur l’URL publiée
service
http://IP_SYSTEME_HOTE:PORT
pour
vérifier
le
fonctionnement
du
41
Gestion des containers Linux
Attachement et détachement
Détachement
La combinaison CTRL + P + Q ne fonctionne que si les conditions suivantes sont réunies:
● l’entrée standard du container est connectée
● le container a été démarrée avec un Terminal
● par exemple: docker run -it ubuntu
Dans ces conditions, CTRL+C terminera le processus en cours donc terminera également le
container.
Attachement
Permet d’accéder à un container qui tourne en arrière plan
La sortie standard du PID 1 du container sera affichée
Pour cela on utilisera la commande docker attach en spécifiant un id ou nom de container
Attention: l’attachement à un container peut-être source d’erreur car si vous pressez par
accident CTRL+C, le container se terminera
42
Gestion des containers Linux
La commande “docker exec”
●
●
●
●
La commande docker exec permet d’éxécuter un processus additionnel dans un container
On l’utilise communément pour accéder au terminal d’un container
la syntaxe est docker exec -it [container ID] bash
De cette façon, en quittant le terminal, le container ne s’arrêtera pas
Exercice:
$ docker run -d -P nginx
$ docker exec -it <container id> bash
Quittez le terminal en cours et vérifiez que le container tourne
$ docker ps
43
Gestion des containers Linux
Arrêt, démarrage de container
Pour cela deux commandes peuvent être utilisées:
- docker stop
- docker kill
docker stop envoie un SIGTERM au processus principal du container
- le processus reçoit ensuite un SIGKILL après une période de grâce
- cette période de grâce peut-être spécifiée avec le flag -t (par défaut à 10s)
docker kill envoie un SIGKILL directement au processus principal du container
docker start permet de redémarrer un container qui a été arrêté.
Le container redémarrera avec les mêmes options qui ont été spécifiées lors de son
lancement.
44
Gestion des containers Linux
Inspection de containers
La commande docker inspect affiche tous les détails à propos d’un container
L’affichage des détails est présenté sous la forme d’un objet JSON
45
Gestion des containers Linux
Inspection de containers, récupération d’une propriété spécifique
La récupération d’une propriété spécifique via un pipe et grep n’est pas idéale.
C’est pourquoi il est possible d’utiliser l’option --format avec la commande docker inspect
La syntaxe est la suivante:
docker inspect --format='{{.<field1>.<field2>>}}' <container id>
Exercice:
$ docker run -d tomcat
$ docker inspect --format='{{.Config.Cmd}}' <container name>
$ docker inspect -- format='{{.NetworkSettings.IPAddress}}'<container name>
Pour récupérer les clés et les valeurs d’une section entière, on utilisera:
$ docker inspect --format='{{json .Config}}' <container name>
46
Gestion des containers Linux
Suppression d'un ou plusieurs containers
On ne peut stopper qu’un container arrêté.
On utilisera la commande docker rm en spécifiant un id de container ou un nom.
On peut tout de même supprimer un container démarré avec l’option -f
Pour supprimer tous les containers, on utilisera une combinaison de commandes.
Exercice:
$ docker rm <container id>
Pour supprimer le dernier container démarré:
$ docker rm $(docker ps -ql)
Pour supprimer tous les containers:
$ docker rm $(docker ps -aq)
47
Création d'images de containers
Comprendre le système de couches dans Docker
●
●
●
●
●
●
●
Une image est une collection de fichiers
et de metadatas
Les images sont constituées de multiple
couches
Une couche n’est rien d’autre qu’une
autre image
Chaque image contient l’ensemble des
applications dont nous avons besoin
Chaque image contient une couche ou
image de base
Docker utilise un système de “copy on
write” pour gérer les couches d’images
Les couches sont en lecture seule
48
Création d'images de containers
Partage de couches
●
●
Les images peuvent partager des couches dans le but d’optimiser les temps de transfert et
la gestion de la mémoire et de l’espace disque.
Les images parentes qui existent déjà sur le système hôte n’ont pas besoin d’être
téléchargées.
49
Création d'images de containers
La couche d’écriture du container
●
●
●
●
Docker crée une couche d’écriture qui se
situe au dessus de toutes les autres
couches.
Les images parentes sont en lecture seule
Tous les changements apportés au
container sont enregistrés sur la couche d’
écriture.
Lorsque l’on change un fichier présent sur
une couche en lecture seule, le système
de “copy on write” copie ce fichier sur la
couche d’écriture et masque l’ancien
fichier.
50
Création d'images de containers
Méthodes de création d’image
Il existe trois méthodes de création d’image
●
La méthode de “commit” qui consiste à enregistrer les changements comme une nouvelle
image. Elle permet de construire une image de manière interactive mais ne permet pas
d’automatiser le build. Elle est idéale par exemple en phase de construction de Dockerfile afin
d’identifier tous étapes de RUN par exemple.
●
La méthode de build à partir d’un Dockerfile. Il s’agit d’un fichier de recette dans laquelle nous
décrivons à partir de quelle image de base nous allons travailler et les instructions
d’installation dans cette image ainsi que la commande a exécuter lors de son lancement.
Cette méthode permet une automatisation du build (pour des cycles de CI/CD par exemple).
●
L’import d’un fichier TAR dans Docker comme seule image de base. Cette méthode permet
par exemple de restaurer un backup d’image mais crée une image d’une seule couche.
51
Gestion des containers Linux
Créer une image de manière interactive
Exercice:
$ docker run -it centos bash
A l’intérieur du container, on installe les paquets nécessaires:
# yum update -y
# yum install -y httpd vim
# exit
Repérez le container arrêté pour le “commiter”
$ docker ps -a
$ docker commit c16378f943fe centos-httpd
$ docker images
A voir aussi: docker history / docker diff
52
Gestion des containers Linux
Créer une image à partir d’un Dockerfile
Exercice:
On crée un dossier de travail pour le Dockerfile et les fichiers:
$ mkdir httpd && cd httpd && touch index.html
On édite un fichier nommé Dockerfile, puis on liste les instructions:
FROM fedora
RUN yum update -y
RUN yum install -y httpd && yum clean all
COPY index.html /var/www/html
EXPOSE 80
ENTRYPOINT [ "/usr/sbin/httpd" ]
CMD [ "-D", "FOREGROUND" ]
Pour finir on lance le build de l’image en taggant au passage:
$ docker build -t monsite .
$ docker run -dP monsite
A voir aussi: cache et commandes courantes
53
Gestion des containers Linux
Choix d’un driver storage pour le daemon Docker
A voir aussi: http://www.projectatomic.io/docs/filesystems/
54
Publication d’images sur Registry
Présentation et installation de la registry Docker
●
Par défaut, lorsque l’on démarre un container, nous utilisons des images issues du Docker
Hub ou de notre banque d’image locale.
●
La centralisation de ces images sur votre propre infrastructure vous permettra d’assurer
sécurité, disponibilité, vitesse, facilité d’intégration et de s’interfacer avec votre système
d’intégration/déploiement continue.
Nous allons démarrer une registry Docker à l’aide de l’image publiée sur le Docker Hub.
Exercice:
On crée un container en mappant manuellement ses ports sur l’hôte:
$ docker run -d -p 5000:5000 --restart always --name registry registry:2
55
Docker
en production
Les questions à se poser
Quel orchestrateur choisir ?
Caas commercial ou opensource ?
Des distributions dédiés : CoreOS ou RancherOS
OS
Registry
Comment Distribuer les images
Choisir le bon produit opensource ou commercial
Héberger soi-même sa registry
rité
Sécu
Après le DevOps, le SecOps !
Docker Silverbullet pour la sécurité ?
Unusable security is not security
Monit
oring
Monitoring global
Mise à jour de la supervision
Nécessité d’une métrologie forte
57
Les contraintes et les KPI
Et bien plus encore
Les contraintes existantes liées à l’environnement représentent les critères d’acceptation minimale pour que la PoC soit
acceptée. Il est aussi important de définir des indicateurs de performance (KPI) qui justifie le changement de technologies
et le passage à Docker.
Les contrainte technique
Les indicateurs
➔
Gestion des logs
➔
Fréquence de déploiement
➔
Chiffrement des communications
➔
Rapidité des déploiements
➔
Scalabilité
➔
Qualité des déploiements
➔
Clustering
➔
Temps de reprise
➔
Back-up
➔
Densification des serveurs
➔
…..
➔
…..
58
Quel orchestrateur choisir ?
Les solutions CaaS à retenir
Docker SWARM
CaaS opensource
Produit opensource
Nos consultants sont certifiés et habilités à
animer les formations officielles.
Docker Datacenter
Support
CaaS commercial production ready
Treeptik est le seul partenaire français certifié et
en mesure d’apporter ce niveau de conseil
Support
Nos consultants sont certifiés pour déployer et
supporter l’offre à licence Docker Datacenter
59
Les containers : la bonne idée !
Les idées les plus simples sont souvent les meilleures !
La portabilité est enfin une réalité
L'application est assemblée avec toutes ses dépendances
dans un container et peut être exécutée sur n’importe quel
cloud ou serveur !
Déploiement accéléré
Les containers contiennent le minimum nécessaire au
démarrage de l'application, ce qui réduit leur taille et
permet des déploiements très rapides.
L’intégration continue boostée
L’intégration continue peut enfin simplement tester
l’application dans son intégralité. Le déploiement en
continu est enfin accessible.
L’innovation décuplée
Les containers duplicables, jetables et partageables
facilement, ce qui simplifie les processus
d’innovations
60
Offres concurrentes
Aperçu et positionnement
De manière générale, le container Docker est devenu LE standard d’isolation
A l’exception de quelques irréductibles comme RKT, tous les orchestrateurs s’appuient sur la
technologie Docker.
61
Comment choisir son orchestrateur ?
Combien de machines avez vous ?
Une seule par application ou par
environnement
Un peu...
Jusqu’à une dizaine
Beaucoup (quelques centaines)
L’intégration continue peut enfin simplement tester
l’application dans son intégralité. Le déploiement en
continu est enfin accessible.
Des milliers
62
Comment distributer ses images ?
Choix de l’hébergement
Docker Registry
Opensource
Docker Trusted
Registry
Production ready
loadbalanced
Sonatype
Artefacts Maven, nodeJS...
GitLab
Le petit dernier
63
Préoccupation fondamentale
Docker Baseline
64
Questions à se poser
Du DevOps à SecOps
➔
Comment forcer les développeurs à faire de la sécurité ? Mauvaise question...
➔
Comment donner aux développeurs les bons outils pour la sécurité ?
Isolation des container linux
●
●
●
●
●
●
pid namespace
mnt namespace
net namespace
uts namespace
ipc namespace
user namespace
●
●
●
●
●
●
●
pivot_root
uid/gid drop
cap drop
all cgroups
selinux
apparmor
seccomp
65
Trusted registry
Du DevOps à SecOps
Utilisation systématique de TLS
Identification des layers (MiM)
Authentification AD, LDAP...
66
Notary
Du DevOps à SecOps
Système de signature d’images et de
validation
Vérification de l’auteur
Non altération du contenu
Support physique pour les clés
67
Nautilus
Du DevOps à SecOps
Scanner d’images Docker
Vulnérabilité (CVE Check)
Validation des licences
Optimisation des images
68
Java Friendly
Pour 2017 !
69
// DockerCon 2016 :: des chiffres
●
Docker est présent dans 50% des mises en place des principes du
Continuous Delivery,
●
dans 47% des nouvelles applications microservices,
●
dans 43% des migrations d’applications legacy vers une architecture
microservices,
●
dans 41% des solutions d’intégration continue,
●
dans 39% des transformations DevOps,
●
et dans 37% des conteneurisations des applications Legacy.
// DockerCon 2017 ::
●
Oracle a annoncé la mise à disposition de ses produits dans le Docker Store
●
Microsoft supporte maintenant l’isolation de container Linux sur Hyper-V
●
IBM offre dorénavant la capacité de faire tourner des containers dans Docker
Enterprise Edition sous IBM z Systems, LinuxONE and Power Systems
●
Cisco propose désormais une couche réseau dédiée aux container
●
Docker annonce de Linux Kit (OS immutable dédié au containers)
●
Docker annonce le projet Moby (modularité des composants Docker)
Cycle de vie
NOUVEAUTÉS
Docker 1.12 et 1.13
Nouveautés Docker 1.12
Swarm Mode et orchestration
Liste des nouveautés pour cette version:
● Intégration de Swarm dans le Docker Engine (Swarm mode)
● Concept de “service” qui permet d’orchestrer une application sur un cluster Docker
● Fonction de “healthcheck” qui teste l’état d’un container
● Load balancing (routing mesh) automatique
● Mise à niveau progressive et transparente d’une stack d’applications
74
Nouveautés Docker 1.13
Consolidation des features de la version 1.12
Liste des nouveautés pour cette version:
● Fichiers Compose désormais utilisables en mode service Swarm
● Fonctions de purge et nettoyage
● Analyse de logs d’un service complet
● Docker pour AWS et Microsoft Azure permet d’étendre sa plateforme sur des cloud publics
75
Linux vs Microsoft
Containers
Présentation
Docker + Microsoft
Docker Linux vs Docker windows
77
Microsoft Container
Docker Linux vs Docker windows
● Linux Container dans Hyper-V
● Microsoft Light Container
● Microsoft Heavy Container
78
DOCKER
DATACENTER
Présentation
Docker Containers-As-A-Service
Présentation des concepts à l’origine de l’offre commerciale Docker Datacenter
80
Docker Datacenter overview
Présentation des composants de la plateforme
81
Docker Datacenter features
Des fonctionnalités d’intégration en entreprise
Liste des fonctionnalités principales:
● Sécurité complète de la plateforme et des échanges
● Plateforme agnostique (déploiement sur bare-metal, machine virtuelle ou cloud public)
● Management de cluster d’hôtes Docker et supervision
● Interfaces web de gestion
● Gestion de rôles multi-tenant et mappage LDAP
● Gestion de backends de stockage d’entreprise
● Gestion de clusters en version Swarm classique et Swarm mode 1.12
● Processus d’installation simplifiés
82
Docker Universal Control Plane
Capture d’écran du panneau de gestion
83
Docker Trusted Registry
Capture d’écran de la banque d’images
84
Twelve factors
Applications
Introduction
Méthologie pour concevoir les logiciels en tant que services (webapp, saas…)
●
●
●
●
●
Utiliser des formats déclaratifs pour automatiser
Offrir une portabilité maximum entre les environnements
Etre adapté aux plateformes clouds publics et privés pour grossir horizontalement
Minimiser la divergence entre développement et déploiement
Pouvoir grossir verticalement sans changement significatif dans l’architecture
Quelque soit le langage et quelque soit les services externes utilisées
86
1. Base de code
-et déploiements...
Une base de code est suivie avec un système de contrôle de version
Une base de code correspond à un dépôt (svn, git, mercurial…)
● Une unique base de code par application
● Si une application utilise plusieurs base de code,
ce n’est pas une application mais un système distribué
Interdit de partager du code entre plusieurs applications
● Besoin de factoriser et d’utiliser des librairies à partager
● de donner l’accès au différents périphériques (/dev/*)
Un déploiement est une instance en fonctionnement de l’application
87
2. Dépendances
Déclarez explicitement et isolez les dépendances
Ne jamais dépendre de l’existence implicite de packages au niveau système
● Les dépendances doivent être déclarées à travers un manifeste
● Favoriser les outils de gestion de dépendances
Il faut simplifier la mise en place des environnements de développements et production
Ne jamais dépendre d’outils système tels que ImageMagick par exemple
● Aucune garantie de compatibilité de version
● Si besoin fournir le binaire avec l’application
88
3. Configuration
Stockez la configuration dans l’environnement
La configuration d’une application est tout de varier entre des déploiements (dev, qa, recettes, …)
● Ressources gérées par la base de données
● Les identifiants pour des services externes (amazon par exemple)
● Les valeurs spécifiques au déploiement (urls par exemple)
Stricte séparation du code et de la configuration
Puis je rendre mon application opensource sans compromission ?
Puis je rendre mon application innersource sans compromission ?
Utiliser des outils dédiés à cet usage : consul, etcd...
89
4. Services externes
Traitez les services externes comme des ressources attachées
90
5. Assemblez, publiez, éxecutez
Séparer strictement les étapes d’assemblage et d’exécution
Une base de code est transformée en suivant les étapes :
●
●
●
Le build : compile les binaires et les ressources
La release : combine le binaire du build avec la configuration de déploiement
Le runtime : lance l’application dans l’environnement d’exécution
91
6. Processus
Exécutez l’application comme un ou plusieurs processus sans état
Les processus sont sans état et ne partagent rien !
●
Toute donnée qui doit être persistée doit être stockée dans un service externe stateful,
typiquement une base de données
●
Le FS peut être utilisé comme cache temporaire
●
Les sessions persistentes (données de session utilisateur) doivent être externalisés.
Datastore avec date d’expiration comme redis ou memcached par exemple
92
7. Association de ports
Exportez les services via des associations de ports
●
Déclaration de dépendances dans l’espace de l’utilisateur
●
Tout service doit être exposé via des ports. Pas seulement HTTP
Presque tout serveur peut fonctionner à travers l’association à un port et écouter les requêtes
entrantes. Redis par exemple
●
Inversement toute application peut devenir le service externe d’une autre application en
fournissant son url dans la configuratio de l’application qui la consomme
93
8. Concurrence
Grossissez à l’aide du modèle de processus
●
●
●
●
●
●
●
Grossir verticalement est vite limitant.
Il faut grossir horizontalement
Pour cela, multipliez les processus
Même les JMV qui gèrent des threads
Utiliser des Events !
Utiliser la gestionnaire de processus pour
la relance ou la distribution
Ne jamais utiliser de daemons
94
9. Jetable
Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux
On doit démarrer et arrêter les processus rapidement
●
●
●
Minimiser le temps de démarrage
Savoir répondre aux signaux SIGTERM
Les processus doivent être robustes face aux morts subites
○ panne du hardware sous-javent par exemple.
○ utiliser des files de messages
Crash-only software is software that crashes safely and recovers quickly
95
10. Parité dev / prod
Gardez les environnements aussi proches que possible
Utiliser le CD pour réduire le fossé entre les environnements
●
●
●
Fossé temporel : un développeur peut développer et déployer du code dans les heures ou
minutes qui suivent
Fossé humain : les personnes qui écrivent le code sont impliqués dans son déploiement et
pour surveiller son comportement en production
Fossé technique : environnement, outils, versions...
96
11. Logs
Traitez les logs comme des flux d’évènements
Ne plus s’inquiètez du routage ou du stockage des flux de sortie
●
●
●
Voir les logs comme des flux d’évènements
Ce n’est pas à l’application de gérer ses logs
Tout doit aller vers stdout
○ En développement, le dev regarde son terminale
○ En production, Les flux seront capturés par leur environnement d’éxecution
●
Idéalement, les flux doivent être envoyés vers des outils d’indexation et d’archivage
○ Trouver un évènement dans le passé
○ Faire des graphiques à échelle des tendances (nb de requêtes, nb d’exception…)
○ Lever des alertes à partir d’heuristiques définie par l’utilisateur
97
12. Processus d’administration
Lancer les comme des one-off-processes
Environnement identique à ceux des processus standard de l’application
●
Exemple de Use Cases
○ Migration de données dans la BDD
○ Lancer une console, un REPL…
○ Exécuter des scripts
●
●
●
Ils doivent s’éxecuter sur une release
Préférer les langages avec un REPL. Cool Java9 en aura un !
Sinon SSH
98
Back to
Docker
Les corvées des sysadmins
Petits échantillons...
Sauvegardes
Gestion des Logs
Accès distants
100
Sauvegardes
Choix du COW : AUFS, BTRFS… LVM
Drivers Storage : NFS, Ceph...
Infinit Storage Platform
Dernière acquisition
101
Infinit storage platform
102
Gestions des logs
103
Gestions des logs
104
Gestions des logs
105
Workflow
de Mise en production
Transformation
Evolutions des pratiques
107
Use case #1
108
Use case #2
109
Use case #3
110
Use case #4 (RancherOS)
111
Use case #5
112
Use case #6
113
Use case #7
114
DevOpSec,
la sécurité
au coeur du DevOps
Contrôles de sécurité obligatoires
Analyse de code
Test d’intrusion
Web Application Firewall
116
5 étapes à prendre en compte
Plan de sécurité
Engager les développeurs
Armer les développeurs
Automatiser les process *
Utiliser les mécanismes classiques *
117
Automatiser les process :: qualité
118
Sécurité avec la CI / CD
119
Les mécanismes classiques
Test intrusion automatisé pour les versions mineures
Test intrusion manuel pour les versions majeures
WAF avec une configuration générique
Utiliser Sonar pour les vulnérabilités
120
ZERO DOWNTIME
DEPLOYMENT
LinuxKit
122
Moby
123
Container Pipeline Release
DEV
Version Control
Continuous
Integration
Staging
Deployment
Blue
Deployment
Repository
QA
Deployment
NON PROD
Green
Deployment
PRODUCTION
Demo Time
Demo :: Maven
mvn clean package docker:build -DpushImage
BLUE GREEN DEPLOYMENT
127
CANARY RELEASE
128
Live Demo
Swarm
●
●
●
●
●
Python webapp which lets you vote between two options
Redis queue which collects new votes
.NET worker which consumes votes and stores them in…
Postgres database backed by a Docker volume
Node.js webapp which shows the results of the voting in real time
130
Docker UseCases
Simplifier configuration
Management Code Pipeline
Productivité développeur
Isolation Application
Consolidation Serveur
Debugging
Multi-tenant
Déploiement rapide
131