Cloisonner pour mieux partager

# 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)

---

# Qui suis-je ?

## Élève ingénieur : informatique & sécurité

### **Ourson**, bien au chaud, chez [Bearstech](http://bearstech.com)

### **Container enthusiast**

???

- 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

---

# I. Introduction

???

- Présentation et rappels de notions pour comprendre

---

# 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

---

# 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

---

# 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

???

- Utilité : environnement différent du système hôte (version de librairies, logiciels, très mobile)
            - bac à sable
            - isolation

---

# Machines Virtuelles **vs** Conteneurs

???

- 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

---

# 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

---

# 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

???

- GRSEC, noyau
        - MAC : Mandatory Access Control
        - Seccomp : limiter les actions d'un programme pendant sont exécution
        - Capabilities : granularité de l'utilisateur root

---

# 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

---

# Pets vs cattle

???

- Terminologie américaine, violente, je l'adapte

---

## VS

???

- 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

---

# Conclusion & Questions ?

???

- 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