class: center, middle, inverse # Cloisonner pour mieux partager ## Wilfried OLLIVIER - PSESHSF 2016 #### Juillet 2016 #### <i class="fa fa-envelope"></i> [wollivier@bearstech.com](wollivier@bearstech.com) #### <i class="fa fa-twitter"></i> [@MarcelMonfort](https://twitter.com/marcelmonfort) --- class: center, middle # Qui suis-je ? ## Élève ingénieur : informatique & sécurité -- ### **Ourson**, bien au chaud, chez [Bearstech](http://bearstech.com) -- ### **Container enthusiast** <center> <img src="./images/containerfail.png" alt="Oops !" height="200" /> </center> ??? - 5ème et denière année == sécurité des SI - Mission : étude et création d'une plateforme d'hébergement utilisant les conteneurs - Construire, casser, tester les conteneurs --- class: center, middle, inverse # I. Introduction ??? - Présentation et rappels de notions pour comprendre --- class: center, middle # Cloisonner ## des processus -- # Pour partager ## des ressources ??? - Informatiquement parlant --- # Un processus (Unix) - Systèmes **multi-tâches** - Plusieurs programmes peuvent s'exécuter (presque) **simultanément** -- - Un processus est une **instance** d'un programme -- # Des ressources - Mémoire, _CPU_, _I/O_, Réseau - Gestion par l'**ordonnanceur** (_scheduler_) ??? - Processus - Exemple : navigateur web + lecteur de musique - Processus utilise des ressources - Ressources - Mémoire vive - CPU : calcul et exécution des programmes - I/O : lecture et écriture sur le disque - Ordonnanceur : chef d'orchestre - Distribution du temps CPU --- class: mlddle # Illustration ```bash [papey@mario ~]$ ps au USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND papey 979 0.0 0.1 39796 6252 tty1 Ss 09:24 0:00 -zsh papey 1066 0.0 0.0 13648 3104 tty1 S+ 09:24 0:00 /bin/sh /usr/bin/startx papey 1088 0.0 0.0 15948 964 tty1 S+ 09:24 0:00 xinit /home/papey/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -auth /tmp/serverauth.yS3iaHEFON papey 1097 0.0 0.0 45748 5772 tty1 S 09:24 0:05 herbstluftwm papey 3194 0.0 0.1 39792 6604 pts/2 Ss 10:06 0:00 -zsh [...] papey 25918 1.2 1.1 2597600 72484 pts/6 Sl+ 10:31 1:49 vim PSES_2016.html papey 26903 0.0 0.1 65308 7820 pts/1 Ss+ 09:30 0:01 mutt papey 30098 0.0 0.0 37420 6048 pts/7 Ss 12:49 0:00 -zsh ``` ??? - Multiples lignes **==** multiples processus - Utilise un % de ram et de CPU - CPU **==** Ordonnanceur --- class: center, middle # Les conteneurs ## Une **Prison**, un **Bac à sable** ## dédié aux processus --- # Que contiennent-ils ? - Un environnement **isolé** du système **hôte** - Exécutant un programme (**un processus**) - Différents degrés d'isolation possibles <center> <img class="image-border" src="./images/container-terminal.gif" alt="Containers FTW !" height="200" /> </center> ??? - Utilité : environnement différent du système hôte (version de librairies, logiciels, très mobile) - bac à sable - isolation --- class: center # Machines Virtuelles **vs** Conteneurs <center> <img class="imager" src="./images/vs.jpg" alt="Containers vs VMs" height="300" /> </center> ??? - Sensations similaires - Un shell, du réseau, un fs **distinct** du système hôte - Fondamentalement différents - Notion de couches d'ordonnancement - VM à gauche - Hôte + son ordonnanceur - Gestion de l'hyperviseur - Création du réseau, mémoire, cpu - Accueil d'un système hôte **complet** - Seconde couche d'ordonnancement - Gestion des processus dans la machine virtuelle - Conteneur à droite - Noyau (et donc ordonnanceur) partagé - Proximité avec le système hôte - 4 **vs** 1 - Implications au niveau de la sécurité et du partage des ressources - Isolation plus lourde, plus sécurisé - Légère, donc plus flexible pour la gestion des ressources --- # Analogie .left-column[ <center> <img src="./images/immeuble.jpg" alt="Analogie" height="250" /> </center> ] .right-column[ ### Isolation - Immeuble **==** Machine physique - Extension de l'immeuble **==** Machine Virtuelle - Appartement **==** Conteneur ### Ressources - Température **==** CPU ] ??? - Notion de granularité - Contrôle plus fin --- # De l'histoire des conteneurs - **1979** : Chroot syscall - **2000** : Jails, _FreeBSD_ - **2001** : VServer - **2004** : Zones, _Open Solaris_ - **2005** : OpenVZ, _Open Virtuzzo_ ??? - Chroot : filesystem - Jails : ajout user, réseau, limitation de l'utilisateur root (administrateur) - Vserver : Jails sous Linux - Zones : Open Solaris + snapshot / clonage avec ZFS - OpenVZ : très utilisé en production de jusqu'en 2010 -- ## Solutions aux capacités limitées - Le **chroot** == **filesystem** - Linux Vserser, difficultés pour limiter les ressources -- ## Des besoins (trop) spécifiques - Un OS particulier - Un **kernel** patché ??? - Kernel patché : différent du kernel _mainstream_ - Lenteur dans l'intégration de nouveautées --- class: center, middle, inverse # II. 2006, la (re)naissance --- # Les besoins du géant - [Large-scale cluster management at Google with Borg - Google Inc.](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43438.pdf) ```sh Google’s Borg system is a cluster manager that runs hundreds of thousands of jobs, from many thousands of different applications, across a number of clusters each with up to tens of thousands of machines. ``` ??? - Des milliers de serveur, d'applications, de services - Distribués, automatisés, grande echelle -- ## Densité **Quantité** de services disponibles et déployés -- ## Contrôle et orchestration Où, quand et comment **déployer** ??? - Besoin simples - Utiliser l'intégralité de l'infra, au max, 100% du temps - Pourquoi ? pour rentabiliser les serveurs - Changement au bout d'un temps fixé - Répondre efficaceemnt aux demandes - 2 type de processus - jobs : long tache de maintenance, nettoyage - quantité prévisible - processus courts : réponses au requètes - quantité inconnue - ajustement la Distribution des ressources pour répondre au besoins - Manque dans les solutions actuelles, création d'outils --- # Cgroups - **2006** : _process groups_, développé par __Google__ - **2007** : intégration dans la _mainline_ du noyau __Linux__ -- - Outil de **mesure** et de **limitation** des ressources - Différents sous-systèmes : - CPU - Réseau - Mémoire - I/O --- # Cgroups, la hiérarchie - Chaque sous-système possède un arbre **hiérarchique** - Indépendants - Un processus appartient à **une seule branche** de cet arbre - Tous les processus d'une branche sont contraints aux **mêmes limitations** -- - Tous les processus sont, par défaut, dans un **cgroup racine** - Les fils d'un processus partagent, par défaut, le **même** cgroup ??? Cgroup racine = présent mais innactif (dormant) --- # Namespaces - **2002**, **2013** (Kernel 3.6) - **Isoler** la **vision** du système d'un processus -- - Différents _namespaces_ - pid - net - mnt - uts - user - ipc ??? - IPC = communication inter processs --- # Chroot + Cgroups + Namespaces ## Cgroups **Limiter**, mesurer les ressources ## Namespaces **Isoler** la vue des ressources ## Pour résumer - Un **chroot**, astuces _filesystem_, outils du noyau ??? - Un large panel de solution c'est construit avec ces briques de base --- class: center, middle, inverse # III. Container Wars --- # Fat containers - LXC - Ensemble d'outils proposé dans l'__userland__ - **PID 1** - Notion de multi-process - Proche d'une **machine virtuelle** - **Granularité** faible ??? - Stéphane Graber, Ubuntu - Analogie : LXC **==** un étage --- # Micro & nano containers - Un **processus**, un **conteneur** - Docker (runc), CoreOS (rkt) - **SPECS** - Uniformisation - Durable - OCI (runc) vs APPC (rkt) - **CNCF** : Cloud Native Computing Foundation - Compatibilité - Volonté commune d'harmonisation ??? - Docker construit avec paradigme - Usage qui peuvent passer outre - Run-time + outils - CoreOS - OS dédié au conteneur utilisant le run-time rkt - Coup de gueule, fork de Docker - Création de SPECS (APPC) - Docker répond, OCI, runc - Specs, volonté d'harmonisation, durabilité - Histoire de runc - Docker, LXC - Docker, libcontainer - Specs, runc - Docker (1.11), runc --- # Sécurité - Existante, efficiente - Peut et **doit** être renforcée - GRSEC - **MAC** : AppArmor, SELinux - Seccomp - Capabilities <center> <img src="./images/fail.jpg" alt="Security Fail !" height="200" /> </center> ??? - GRSEC, noyau - MAC : Mandatory Access Control - Seccomp : limiter les actions d'un programme pendant sont exécution - Capabilities : granularité de l'utilisateur root --- class: center, middle, inverse # VI. Vers l'infini et au-delà --- # Moderniser l'hébergement ## Vocation des conteneurs - Déterministe - Reproductible - Ubiquité - **12** factors apps ??? - Déterministe : construction automatisé, figée pour une version - Reproductible : le déterminisme + répétition - Ubiquité : Déterministe + Reproductible - 12 factors - Liste de principes, inspirée de Joel Spolsky - Comment dev une app morderne -- ## Harmoniser la "chaîne de production" ??? - Les principes ci-dessus + env jetable / bac à sable - env dev == env test == env prod --- class: center, middle # Pets vs cattle ??? - Terminologie américaine, violente, je l'adapte --- class: center, middle <center> <img src="./images/doat.jpg" alt="Good" height="220" /> </center> ## VS <center> <img src="./images/goats.jpg" alt="Bad" height="220" /> </center> ??? - De plus en plus de machine, de plus en plus de services - Besoin d'une gestion par lot - Pour être efficace, meta-administration - Créer des outils d'administration de plus haut niveau - Cas par cas **==** possibilités d'oublis - On se retrouve dans la situation du dessus --- # Changement d'échelle - S'adapter à une demande - Réponse **efficace** && **mesurée** ??? - Redéfinir la scalabilité - Système distribué - Meta administration == **OBLIGATOIRE** - Conteneur + 12 factors + sys dis -- - Systèmes distribués, **complexes** mais : - Réduction du **MTTR** - Renforcement de la résilience -- # Contrôle des ressources - Granularité **fine**, contrôle efficient - Limitations **flexibles** ??? - Grande marge pour ajuster en direct et répondre efficacement --- # Full cycle again .left-column[ <center> <img src="./images/fullcycle.jpg" alt="JCVD" height="300" /> </center> ] ??? - Parole d'un grand : JCVD, FULL CYCLE -- .right-column[ 1. Écriture du code 2. Construction du conteneur 3. Tests (automatisés) 4. Validation (humaine) 5. Commit (sur une branche particulière) 6. Tests d'intégration - **SUCCESS** : _push to prod_ - **FAIL** : _rollback_ 7. Études des logs 8. Évolutions && corrections (GOTO 1.) ] ??? - FULL CYCLE --- class: center, middle, inverse # Conclusion & Questions ? <center> <img class="image-circle" src="./images/containers.gif" alt="Containers FTW !" height="200" /> </center> ??? - Outils récent - Modulables - S'adaptent au nouvelles pratiques de sysadmin et de dev - Isolation, contrôle - Ne pas négliger la sécurité - Bye