fixup! First part wip

slides/Makefile

@@ -1,4 +1,4 @@
-SOURCES		= slides.md intro.md os.md containers.md apps.md
+SOURCES		= slides.md intro.md os.md containers.md apps.md conclusion.md
 HEADER		= header.tex
 TEMPLATE	= CambridgeUS
 COLORTHEME	= beaver

slides/apps.md

@@ -2,35 +2,50 @@
 
 ## Grandes idées
 
+----
+
 TODO une image représentant les conteneurs applicatifs
 
 ----
 
-TODO une image pour expliquer UnionFS
+![](logo-docker.png)
 
 ----
 
 TODO une image d'architecture nginx/php-fpm
 
-----
-
-TODO logo Docker
-
-----
-
-TODO image tetris, illustration ordonnancement
-
 
 ## Quelques bonnes pratiques
 
-### Garder les couches propres
+----
 
-### Séparer les données du système
+#### Ne pas mettre à jour ou patcher une image
 
-TODO image représentant les data only container
+. . .
 
-### Prendre les arguments depuis l'environnement
+#### Garder les couches propres
 
-### Ne pas installer syslog, utiliser `docker logs`
+* `apt-get clean`
+* `docker squash`
 
-### Ne pas containeriser des applications intégrant déjà cette notion
+. . .
+
+#### Séparer les données du système
+
+Cf. Data Only Container
+
+. . .
+
+#### Prendre les arguments depuis l'environnement
+
+* Config DB ;
+* config application ;
+* config système.
+
+. . .
+
+#### Ne pas installer `syslog`, utiliser `docker logs`
+
+. . .
+
+#### Ne pas containeriser des applications intégrant déjà cette notion

slides/conclusion.md

@@ -0,0 +1,13 @@
+## Et maintenant ?
+
+### Quelle est la problématique ?
+
+#### Sécurité
+
+Cf. conteneurs chez Amazon
+
+. . .
+
+#### Ordonancement des ressources
+
+TODO image tetris, illustration ordonnancement

slides/containers.md

@@ -20,12 +20,10 @@
 
 ### Pour cette mission, vous disposerez de ...
 
-TODO screen drôle de Spy 2015
+![](armory.jpg)
 
 ----
 
-. . .
-
 #### Namespaces
 
 Isolation des processus (PID Namespace), interface réseau (Network
@@ -51,11 +49,10 @@ Limitation de ce que `root` peut faire.
 
 ### Mais Jamy, comment ça marche ?
 
-![cps.jpg]
+![](cps.jpg)
 
-----
 
-#### Syscall
+### Syscall
 
 * `clone`
 * `unshare`
@@ -63,6 +60,8 @@ Limitation de ce que `root` peut faire.
 
 . . .
 
+#### Exemple
+
 ```c
 int fd;
 
@@ -75,16 +74,6 @@ setns(fd, 0);
 
 ----
 
-#### Système de fichiers
-
-Sous-arbre de la racine.
-
-* `pivot_root(2)`
-* Union FileSystems
-* Thin provisioning
-
-. . .
-
 ```
 PATH                     FILESYSTEM
 /                        /dev/sda1
@@ -93,7 +82,6 @@ PATH                     FILESYSTEM
 ├── sys
 ├── usr
 └── var
-    ├── cache
     ├── cntrs
     │   ├── toto         /dev/sda5
     │   │   ├── dev
@@ -109,9 +97,20 @@ PATH                     FILESYSTEM
     └── tmp
 ```
 
+### Système de fichiers
+
+* `pivot_root(2)`
+* Union FileSystems
+* Thin provisioning
+
+----
+
+TODO une image pour expliquer UnionFS
+
+
 ### Le réseau ...
 
-![sosreseau.jpg]
+![](sosreseau.jpg)
 
 
 ### Le réseau ...
@@ -124,7 +123,7 @@ Facile ! Mais il en faut beaucoup.
 
 #### VLAN
 
-Un tag par conteneur. Routage **interne** par le switch en amont.
+Un tag par conteneur. Routage *interne* par le switch en amont.
 
 . . .
 

slides/header.tex

@@ -1,10 +1,11 @@
 \setbeamertemplate{title page}[default][colsep=-4bp,rounded=true]
 \setbeamertemplate{blocks}[rounded][shadow=false]
-\setbeamercolor*{item}{fg=lightgray}
+\setbeamercolor*{item}{fg=gray}
 \setbeamercolor*{block title}{fg=darkred}
 \setsansfont[Ligatures=Common]{LinBiolinum}
 %\setmonofont{fantasque-sans-mono}
 \setmonofont{Inconsolata}
+\useinnertheme{rectangles}
 \beamertemplatenavigationsymbolsempty
 \AtBeginSection{}
 \AtBeginSubsection{}

slides/intro.md

@@ -2,10 +2,12 @@
 
 ## John von Neumann
 
-![John von Neumann](JohnvonNeumann.gif)
+----
+
+![](JohnvonNeumann.jpg)
 
 . . .
 
-About assembly language:
+À propos du langage assembleur :
 
 > Why would you want more than machine language?

slides/os.md

@@ -11,7 +11,7 @@
 
 ### ... le temps de boot ?
 
-![dmesg.png]
+![](dmesg.png)
 
 . . .
 
@@ -20,23 +20,48 @@ https://0xax.gitbooks.io/linux-insides/content/
 
 ### ... le système de fichiers ?
 
-Eh oui !
+```
+PATH                     FILESYSTEM
+/                        /dev/sda2
+├── bin
+├── boot                 /dev/sda1
+├── etc
+├── dev
+├── home                 /dev/sda3
+├── lib
+├── proc
+├── root
+├── sbin
+├── sys
+├── tmp                  tmpfs
+├── usr
+│   ├── bin
+│   ├── lib
+│   └── share
+└── var
+    ├── cache
+    ├── lib
+    ├── log
+    └── tmp
+```
 
 
 ### ... d'isoler ?
 
-> * Limitation des ressources ;
-> * partage du temps de calcul ;
+> * Sécurité (root, exploit, ...) ;
+> * limitation des ressources ;
 > * prévention des dénis de service :
 > ```sh
 > 42sh$ while true; do mkdir x; cd x; done
 > ```
-> * abstraction des ports ;
-> * sécurité (root, exploit, ...).
+> * partage du temps de calcul ;
+> * abstraction des ports réseau.
 
 
 ## Les techniques d'isolation
 
+----
+
 > * `chroot`
 > * Virtualisation et paravirtualisation
 
@@ -48,4 +73,4 @@ Eh oui !
 
 ### Mais ...
 
-![idea.jpg]
+![](idea.jpg)

slides/slides.md

@@ -1,3 +1,3 @@
 % Virtualisation légère
 % Pierre-Olivier Mercier
-% Jeudi 1er octobre 2015
+% Jeudi 1^er^ octobre 2015

slides/slides.pdfpc

@@ -3,16 +3,17 @@ slides.pdf
 [duration]
 180
 [notes]
-### Accueil
-Bonjour
-Hésitez pas à poser des questions
-### John von Neumann
+### 1
+Bjr! Aujd nous allons parler virli. C'est un domaine assez ancien, comme nous le verrons un peu plus tard, mais depuis 2 ans, tout le monde essaye de faire tout et surtout n'importe quoi avec. J'imagine que vous avez déjà entendu parler des containers, de jails, de LXC ou de Docker ; mais c'est pas forcément toujours clair. On va débrouisailler tout ça ensemble et voir comment ça marche, pourquoi c'est bien, comment c'est sécurisé. Je vais m'appuyer sur des notions que vous ne connaissez peut-être pas ou que vous avez oublié. Si c'est le cas, n'hésitez surtout pas à me couper la parole et à me poser vos questions.
+### 2
 Commençons par parler de quelqu'un d'important...
-Pourquoi aurait-on besoin de gaspiller du temps de calcul scientifique si précieux pour générer du code binaire ?
+à qui l'on doit l'architecture VN // Harvard... ~1950
+Pourquoi aurait-on besoin de gaspiller du temps de calcul scientifique si précieux pour générer du code binaire ? => bien sûr ça fait sourire, lang haut niveau, mais on peut croire parfois des évolutions sont inutiles.
 - 1 machine = 1 programme => perte de temps de calcul pendant les I/O
 => Ordonnanceur rudimentaires : partager le temps de calcul entre les bloquages d'I/O
-=> problèmes : ex : partage de l'espace d'adressage (=> MMU)
-### Est-ce bien nécessaire : un noyau ?
+=> pb: ex : partage de l'espace d'adressage (=> MMU)
+### 3
+Interface entre le système et le matériel.
 - Gestion de la concurrence d'accès au matériel
 - Répartition du temps CPU entre les tâches
 - Gestion du contexte des tâches (mémoire, registres, context switch, ...)
@@ -20,26 +21,31 @@ Pourquoi aurait-on besoin de gaspiller du temps de calcul scientifique si préci
 - Diverses couches d'abstraction :
   - matériel : clavier/souris/...
   - FS
-### Est-ce bien nécessaire : le temps de boot ?
+Mais pourquoi ça prend autant de temps ?
+Windows promet un boot instanné depuis 10 ans...
+### 4
 - bootloader: charge le noyau en mem et jump
 - détection du matériel
 - mise en place des interfaces : réseau, FS, nom de machine, utilisateurs, droits, permissions, ...
+LIEN si intéressé
 - montage de la racine
 - /sbin/init
-### Les techniques d'isolation : chroot
+
+Sans tous les services autour du noyau, on booterait en un rien de temps. Mais c'est cool aussi d'avoir une UI, un pare-feu, etc.
+### 5
 Le noyau seul ne fait rien, il lui faut des programmes et des données.
 
 Tous les programmes n'ont pas besoin de toutes les données.
 Mais certains programmes échangent des données entre-eux (IPC, socket, ...)
 Et s'il y a une vulnérabilité ?
 pourquoi partager les données de services qui ne communiquent pas entre eux ?
-### Est-ce bien nécessaire : d'isoler ?
-- limitation quantité de RAM, BP réseau
-- allocation du temps de calcul par groupe (1 serveur peut avoir plusieurs process qui sont schedulés indépendamment = triche !)
-- DOS locaux => machine à genoux
-- plusieurs serveur web/ssh
+### 6
 - sécu : droits root, exploit, ...
-### Les techniques d'isolation : chroot
+- limitation quantité de RAM, BP réseau
+- DOS locaux => machine à genoux
+- allocation du temps de calcul par groupe (1 serveur peut avoir plusieurs process qui sont schedulés indépendamment = triche !)
+- plusieurs serveur web/ssh
+### 7
 DEMO chroot
 - complexe à mettre en œuvre
 on peut pas avoir 2 serveurs web/ssh
@@ -50,14 +56,14 @@ on peut pas avoir 2 serveurs web/ssh
 - coût : maj pas simples, monitoring peu précis (limitation des ports)
 => ok pour de la défense en profondeur
 Exemple : ING1 exams machine
-### Les techniques d'isolation : virtualisation/paravirtualisation
+### 8
 - accès concurent au matos : périphériques émulés
 - VT-x/AMD-v
 - plusieurs serveurs sur le même port
 - limitation des ressources
 - on peut lancer différents OS/version
 - similaire dupliqué : autant de noyaux lancés que de services, FS non partagés, MAJ
-### Les techniques d'isolation : mais ...
+### 9
 - partager le même noyau, avec KVM : tout existe déjà : ordonanceur
 - les FS identiques (on met à jour le système de base une seule)
 
@@ -69,7 +75,7 @@ Exemple : ING1 exams machine
 
 On appel ça des conteneurs !
 PAUSE ?
-### Made in Unix: Que doit-on isoler ?
+### 10
 - matos : non, le noyau l'abstrait déjà (ex webcam/group video) mais limitation des ressources
 - processus, interfaces réseau et liste de partitions montées pour éviter l'espionnage et l'accès à des données sensibles
 - réseau : iface, table de routage, ports, etc.
@@ -77,14 +83,14 @@ PAUSE ?
 - horloge : non, la timezone est un fichier
 DEMO strace date => /etc/timezone
 - logs kernel prévu dans une prochaine version
-### Pour cette mission...
+### 11
 Que doit-on implémenter concrétement ?
 - KVM fourni déjà plein de trucs
 - ordonanceur VM/process => groupe
 + statistiques diverses pour limitation
 + mécanisme pour avoir plusieurs structures similaires (point de montage, user, iface réseau)
 + problématique de root : si on peut tout faire, on peut se balader partout...
-### Made in Linux
+### 12
 - isoler plein de choses : Namespace
 DEMO make menuconfig
 DEMO namespace UTS, PID, (user?)
@@ -95,7 +101,7 @@ DEMO limitation mémoire
 DEMO statistiques réseau
 - capabilities : ~40 : CAP_KILL, CAP_SYS_TIME
 DEMO capabilities
-### Mais Jamy, comment ça marche ?
+### 13
 - recopie de la structure du parent (UTS, mount)
 - création d'une nouvelle struct (network, PID, users, IPC)
 - réseau : 1 iface = 1 ns
@@ -103,34 +109,67 @@ DEMO capabilities
 - chaque process est lié à des namespace /proc/PID/ns/*
 DEMO sudo ls -l /proc/1/ns/*
 + ouvrir ces fichiers : récupérer fd sur NS
-### pour les nuls: SYSCALLS
+### 14
 utilise 3 syscalls pour gérer les NS :
 - clone(2): nouveau process fils avec création de nouveau namespace en fonction des flags
 - unshare(2): nouveau namespace pour le process courant
 - setns(2): rejoindre un namespace existant
 + second argument pour filtrer le type de namespace, 0 accepte tout
-### pour les nuls: FileSystem
+### 15
 - sous-arbre de la racine
+### 16
 - pivot_root: initramfs, racine d'une partition, pas d'autre FS monté sur celui qui va disparaître
 - UnionFS: peut avoir plusieurs couches
 + cache les fichiers d'une même couche
 + récemment intégré dans le kernel 3.18 (décembre)
 - Thin provisioning: allocation dynamique de l'espace disque
-### pour les nuls: le réseau
+### 18
 - Réseau : pas évident :
 * 1 carte réseau = 1 seule IP
 * promiscuité
 * routage
-### pour les nuls: le réseau
+### 19
 - iface physique : Ok
 - MAC-VLAN : chaque machine a une MAC différente (promiscuité filtrée par le noyau)
 2 modes : VEPA : tous les paquets sortent, le switch doit les renvoyer vers la même machine
 Bridge : le noyau analyse les paquets sortant avant transmission
 - veth : on partage une interface virtuelle entre l'hôte et l'invité et on relie le tout à un bridge.
 DEMO network namespace
-### MAIS !
+### 20
 LXC stable depuis le 20 février 2014
-DEMO LXC busybox
+Capabilities moyennement propres (CAP_SYS_ADMIN lol)
+DEMO LXC VPS: lxc-start -n virli-vps
 
-Doit-on tout virtualiser ? avoir toutes les bibliothèques et fichiers de base (init, syslog, cron, sshd, ...) ?
+Gagné : bootloader + noyau...
+Doit-on tout virtualiser ? avoir toutes les bibliothèques et fichiers de base (init, syslog, cron, sshd, ...) juste pour un programme ?
 !!! QUESTIONS + PAUSE !!!
+### 21
+- embarque le strict minimum
+- lance le strict minimum : pas d'init, pas de cron, pas de ssh, juste l'appli
+DEMO lxc busybox httpd : lxc-start -n virli-httpd
+- ldd apache, bon c'est encore pas super pratique
+=> image minimaliste (juste gestion. de paquet) puis install
+=> mais on lance que le prog, pas init et tout
+#### 22
+- dépôt d'images
+- fichiers de recette (Dockerfile)
+DEMO Dockerfile nginx
+- rajout PHP-FPM?
+=> classique, on ajoute PHP-FPM dans le conteneur
+=> soit on le place dans un conteneur différent
+#### 23
+- Partage d'un volume de données
+- Liaison entre conteneur
+=> On orchestre tout ça avec Docker compose
+Hyper pratique en dev, comme en prod !
+#### 24
+noMAJ: cela casserait le principe de conteneur identique partout où on le crée
+=> préférer remonter au mainteneur
+Couches propre pour contenir le poids des images
+DataOnlyCntr: MAJ du soft sans toucher aux données
+Config: seul moyen de passer des args
+- généralement par script shell
+- penser à faire des applis qui comprennent les SIGTERM, ...
+DEMO Dockerfile FIC
+syslog: beurk
+MySQL/DB/... contient déjà des mécanismes d'isolation, il ne faut pas avoir un serveur par service/serveur, préférer une solution globale.