Last rev

slides/apps.md

@@ -4,15 +4,11 @@
 
 ----
 
-TODO une image représentant les conteneurs applicatifs
-
-----
-
 ![](logo-docker.png)
 
 ----
 
-TODO une image d'architecture nginx/php-fpm
+![](nginxphp.png)
 
 
 ## Quelques bonnes pratiques

slides/conclusion.md

@@ -1,6 +1,8 @@
-## Et maintenant ?
+# Conclusion
 
-### Quelle est la problématique ?
+## Problèmes, soucis et choses pas claires
+
+### Et maintenant ?
 
 #### Sécurité
 
@@ -10,4 +12,4 @@ Cf. conteneurs chez Amazon
 
 #### Ordonancement des ressources
 
-TODO image tetris, illustration ordonnancement
+![](tetris.png)

slides/containers.md

@@ -12,7 +12,6 @@
 > * Nom et domaine de la machine !
 > * IPC !
 > * Horloge ?
-> * Logs ?
 
 
 ## Made in Linux
@@ -32,11 +31,15 @@ groupes (User Namespace), nom de machine (UTS Namespace), IPC.
 
 `namespaces(7)`
 
+. . .
+
 #### CGroups
 
 Statistiques sur l'utilisation des ressources et limitation.
 
-https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt
+<https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt>
+
+. . .
 
 #### Capabilities
 
@@ -100,12 +103,12 @@ PATH                     FILESYSTEM
 ### Système de fichiers
 
 * `pivot_root(2)`
-* Union FileSystems
 * Thin provisioning
+* Union FileSystems
 
-----
+### Union FileSystem
 
-TODO une image pour expliquer UnionFS
+![](unionfs.png)
 
 
 ### Le réseau ...

slides/os.md

@@ -15,7 +15,7 @@
 
 . . .
 
-https://0xax.gitbooks.io/linux-insides/content/
+<https://0xax.gitbooks.io/linux-insides/content/>
 
 
 ### ... le système de fichiers ?
@@ -49,11 +49,11 @@ PATH                     FILESYSTEM
 ### ... d'isoler ?
 
 > * Sécurité (root, exploit, ...) ;
-> * limitation des ressources ;
 > * prévention des dénis de service :
 > ```sh
 > 42sh$ while true; do mkdir x; cd x; done
 > ```
+> * limitation des ressources ;
 > * partage du temps de calcul ;
 > * abstraction des ports réseau.
 
@@ -65,12 +65,9 @@ PATH                     FILESYSTEM
 > * `chroot`
 > * Virtualisation et paravirtualisation
 
-----
-
-* `chroot`
-* Virtualisation et paravirtualisation
-
 
 ### Mais ...
 
+. . .
+
 ![](idea.jpg)

slides/slides.pdfpc

@@ -2,25 +2,26 @@
 slides.pdf
 [duration]
 180
+[skip]
+3,6,9,10,11,12,16,18,19,20,21,22,23,24,31,37,38,39,41,42,43,47,48,49,50,51,53,
 [notes]
 ### 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.
+Bjr! Aujd nous allons parler virli. C'est un domaine assez ancien, 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...
+Rendons homage à JvN...                   cartes perforées
 à 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
-=> pb: ex : partage de l'espace d'adressage (=> MMU)
+- 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
+=> pb: ex : partage de l'espace d'adressage (=> MMU) => abouti aux noyaux
 ### 3
-Interface entre le système et le matériel.
+Interface entre le système (progs) 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, ...)
-- Gestion des erreurs (division par 0)
+- Maintenir une isolation : gestion erreurs (div par 0)
 - Diverses couches d'abstraction :
   - matériel : clavier/souris/...
   - FS
+
 Mais pourquoi ça prend autant de temps ?
 Windows promet un boot instanné depuis 10 ans...
 ### 4
@@ -28,72 +29,77 @@ Windows promet un boot instanné depuis 10 ans...
 - 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
+- montage de la racine, son rôle s'arrête là (- 1s)
 - /sbin/init
 
-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.
+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, partage de fichiers réseau, etc.
 ### 5
-Le noyau seul ne fait rien, il lui faut des programmes et des données.
+La perte de temps dans nos FS dont on a perdu le contrôle. Le noyau fait rien, lui faut progs et données.
+FS est bien organisé, mais pour un prog donné, il y a beaucoup de fichiers auquel il peut accéder alors qu'ils lui sont inutiles : confs, lib, exe, ...
 
-Tous les programmes n'ont pas besoin de toutes les données.
-Mais certains programmes échangent des données entre-eux (IPC, socket, ...)
+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 ?
 ### 6
-- sécu : droits root, exploit, ...
-- 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 !)
+Mécanismes d'isolation pr amélior sécurité, mais aussi :
+- DOS locaux : serveur SMTP vs. fork bomb
+- limitation/mieux répartir RAM (impact leak), BP réseau
+- répartition TpsDCalc par services/groupe de process (triche : plusieurs process = schedulés indépendamment)
 - plusieurs serveur web/ssh
 ### 7
+1er système d'isolation, rudimentaire
 DEMO chroot
-- complexe à mettre en œuvre
+- complexe à mettre en œuvre (MAJ, automatismes...)
 on peut pas avoir 2 serveurs web/ssh
 - faible sécurité (grsec) + DEMO escape
 - si un process tombe, on peut lui voler son port et hop
 - arbre de process partagé
 - pas de limitation des ressources
-- coût : maj pas simples, monitoring peu précis (limitation des ports)
 => ok pour de la défense en profondeur
 Exemple : ING1 exams machine
 ### 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
+- hypvsr concurent au matos : périphériques émulés
+- chaque machine stack réseau : plusieurs serveurs sur le même port
+- limitation des ressources géré par l'hyperviseur
+- on peut lancer différents OS/version et bénéficier des instructions VT-x/AMD-v
+- similaire dupliqué (admin sys Debian stable) : autant de noyaux lancés que de services, FS non partagés
+
+=> dans Linux : KVM : un hyperviseur dans le noyau WTF !!
 ### 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)
+Pourquoi renverser problème : intégrer dans le noyau des espaces d'exécutions distinct ?
 
 * 1998 : Jails BSD
 * 2005 : Zones Solaris
 * 2005 : patch Linux OpenVZ
 * 2008 : début du projet Linux Container (LXC)
-* 2015 : Windows 10
+* 2015 : Windows 10 (heu ...)
 
-On appel ça des conteneurs !
-PAUSE ?
+Tout ça, c'est ce qu'on appel des conteneurs !
 ### 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
+- processus, interfaces réseau et liste de partitions montées pour éviter l'espionnage/kill et l'accès à des données sensibles
 - réseau : iface, table de routage, ports, etc.
 - users, groups, nom de machine et IPC : pas de raison qu'ils soient partagés
 - horloge : non, la timezone est un fichier
 DEMO strace date => /etc/timezone
-- logs kernel prévu dans une prochaine version
+- logs kernel prévu dans une prochaine version PAUSE?
 ### 11
 Que doit-on implémenter concrétement ?
-- KVM fourni déjà plein de trucs
+- des espaces d'exécution distincts
 - 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...
+- statistiques diverses pour limitation
+- mécanisme pour avoir plusieurs structures similaires (point de montage, user, iface réseau)
+=> dans Linux, avec KVM, on a pas mal de choses schdul
+
+problématique du root, roi du monde : si on peut tout faire, on peut se balader entre les mondes
 ### 12
 - isoler plein de choses : Namespace
+Linux distingue 6 espaces
+peuvent être créés indépendamment, au moment du fork ou en cours d'exec
+
 DEMO make menuconfig
 DEMO namespace UTS, PID, (user?)
+### 13
 - limiter les ressources : cgroups
   * CPU (assignation de nœuds et prioritisation), mémoire, réseau, freeze
   * à venir: PID
@@ -104,11 +110,12 @@ DEMO make menuconfig
 DEMO freeze
 DEMO limitation mémoire
 DEMO blkio
+### 14
 - capabilities : ~40 : CAP_KILL, CAP_SYS_TIME
   * déf par thread ou attaché à un fichier (attributs étendus)
   * permet d'éviter les setuid complet
 DEMO capabilities
-### 13
+### 15
 - recopie de la structure du parent (UTS, mount)
 - création d'une nouvelle struct (network, PID, users, IPC)
 - réseau : 1 iface = 1 ns
@@ -116,67 +123,79 @@ 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
-### 14
+### 16
+Quand on est un processus/programmeur...
 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
-### 15
-- sous-arbre de la racine
-### 16
+
+Shell: unshare, ip netns
+### 17
+Chaque conteneur va être un sous-arbre de la racine
+
+Initiallement, on obtient une copie des partitions montées, la première chose que l'on a envie de faire c'est un pivot_root, plutôt qu'un chroot
+- initramfs
+- racine d'une partition
+- pas d'autre FS monté
+### 18
 - pivot_root: initramfs, racine d'une partition, pas d'autre FS monté sur celui qui va disparaître
+
+- Thin provisioning: allocation dynamique de l'espace disque
+### 19
 - 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
-### 18
+### 20
 - Réseau : pas évident :
 * 1 carte réseau = 1 seule IP
 * promiscuité
 * routage
-### 19
+### 21
 - 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
-### 20
-LXC stable depuis le 20 février 2014
-Capabilities moyennement propres (CAP_SYS_ADMIN lol)
+### 22
+Ok, donc tout est bien implémenté, on sait comment çm
+LXC stable ; quelques scripts/API créer des conteneurs.
+bas niveau (conf, ...)
+/!\ Capabilities moynemnt propres (CP_SYS_ADMIN lol)
 DEMO LXC VPS: lxc-start -n virli-vps
 
 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
+### 23
+- embarque moins que le minimum (just gest pkg)
+- lance le strict minimum : pas d'init, pas de cron, pas de ssh, juste l'appli dans env
 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
+=> image minimaliste (hub.dckr) puis install
+DEMO docker run --rm -it mdebian => nginx
+DEMO Dockerfile
 => 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.
+=> pas de données, soit DB, soit DoC
+Voyons maintenant, une archi site web classique.
+### 24
+Une DB quelque part
+Un conteneur pour PHP, nginx, les pages = 3 conteneurs.
+Si on met à jour PHP, on a juste à relancer le conteneur, idem ngninx, data.
+À leur initialisation, on leur dit où se trouver l'un-l'autre
+
+docker compose permet de lancer tous les cnt en une commande.
+Pour du dev, chaque équipe peut bosser sur son truc dans un cntr, et utiliser docker compose pour tester avec le travail des autres
+
+Quand on dev : privilégier les printf aux sysloglibs, handle kill
+### 25
+apt-get upgrade => NON => mainteneur => consistance d'un build à l'autre
+
+Pas de DB par exemple, car elles permettent déjà
+### 26
+Actmnt, EC2 cntr limité à un client, lance des VM (Xen), un agent, cntr sont répartis par algo
+
+D'ailleurs, l'une des problématiques actuelle, c'est d'arriver à trouver le meilleur algo d'ordonnancement pour répartir les cntr sur les machines physiques, c'est Tetris, il faut jouer avec les quant de mémoire, la BP, la puissance de calcul, le temps d'exec, la périodicité, ... soit remplir des fichiers de conf +/- vagues, soit coder des réseaux de neuronnes.
+
+Tous les jours ou presque on découvre de nouveaux usages de Docker (et donc de la virtualisation légère), on ne sait pas forcément toujours où l'on va, d'autant plus que c'est un domaine qui bouge beaucoup. J'espère que vous y prendrez goût et que vous trouverez l'usage qui vous facilitera la vie (même si c'est au détriment de quelques cycles), d'autres gens apprécieront sans doute !