First part wip
This commit is contained in:
parent
142b06dea6
commit
b3d5f320ce
107
slides/containers.md
Normal file
107
slides/containers.md
Normal file
@ -0,0 +1,107 @@
|
||||
# Voyage par conteneur
|
||||
|
||||
## Made in Unix
|
||||
|
||||
### Que doit-on isoler ?
|
||||
|
||||
* Matériel ?
|
||||
* Processus ?
|
||||
* Réseau ?
|
||||
* Système de fichiers ?
|
||||
* Utilisateurs et groupes ?
|
||||
* Nom et domaine de la machine !
|
||||
* IPC !
|
||||
* Horloge ?
|
||||
|
||||
|
||||
## Made in Linux
|
||||
|
||||
|
||||
### Pour cette mission, vous disposerez de ...
|
||||
|
||||
TODO screen drôle de Spy 2015
|
||||
|
||||
----
|
||||
|
||||
. . .
|
||||
|
||||
#### Namespaces
|
||||
|
||||
Isolation des processus (PID Namespace), interface réseau (Network
|
||||
Namespace), partitions montées (Mount Namespace), utilisateurs et
|
||||
groupes (User Namespace), nom de machine (UTS Namespace), IPC.
|
||||
|
||||
#### CGroups
|
||||
|
||||
Statistiques sur l'utilisation des ressources et limitation.
|
||||
|
||||
http://kernel.org/doc/FIXME/cgroups.txt
|
||||
|
||||
#### Capabilities
|
||||
|
||||
Limitation de ce que `root` peut faire.
|
||||
|
||||
|
||||
## pour les nuls
|
||||
|
||||
### Mais Jamie, comment ça marche ?
|
||||
|
||||
TODO screen C'est pas sorcier
|
||||
|
||||
----
|
||||
|
||||
#### Système de fichiers
|
||||
|
||||
Sous-arbre de la racine
|
||||
|
||||
* Union FileSystems
|
||||
* Thin provisioning
|
||||
|
||||
#### Processus
|
||||
|
||||
Premier processus contenu = PID 1.
|
||||
|
||||
|
||||
### Le réseau ...
|
||||
|
||||
TODO Câbles mélangés
|
||||
|
||||
----
|
||||
|
||||
#### Interface physique
|
||||
|
||||
Facile ! Mais il en faut beaucoup.
|
||||
|
||||
#### MAC-VLAN
|
||||
|
||||
* **VEPA :** tous les paquets sortants sortent, y compris ceux à destination
|
||||
d'une autre machine locale. Le switch derrière doit rerouter les paquets vers
|
||||
la machine.
|
||||
* **Bridge :** le noyau analyse les paquets avant de les transmettre.
|
||||
|
||||
#### Virtual Ethernet
|
||||
|
||||
Interfaces virtuelles connectées à un bridge.
|
||||
|
||||
|
||||
## En résumé
|
||||
|
||||
### Mais ! (il y a toujours un mais)
|
||||
|
||||
. . .
|
||||
|
||||
#### LXC stable
|
||||
|
||||
Prêt pour la production depuis le XX 2014.
|
||||
|
||||
Attention à la configuration et aux erreur de capabilities !
|
||||
|
||||
. . .
|
||||
|
||||
#### Partage des systèmes de fichiers
|
||||
|
||||
Optimise l'utilisation du cache :-)
|
||||
|
||||
. . .
|
||||
|
||||
N'optimise pas le travail de l'administrateur système :-(
|
||||
13
slides/intro.md
Normal file
13
slides/intro.md
Normal file
@ -0,0 +1,13 @@
|
||||
# Avant tout...
|
||||
|
||||
## John von Neuman
|
||||
|
||||
### Un personnage important
|
||||
|
||||
TODO ici une photo
|
||||
|
||||
---
|
||||
|
||||
#### John von Neuman
|
||||
|
||||
> Citation de lui sur le langage Assembleur
|
||||
50
slides/os.md
Normal file
50
slides/os.md
Normal file
@ -0,0 +1,50 @@
|
||||
# Système d'exploitation
|
||||
|
||||
## Est-ce bien nécessaire ...
|
||||
|
||||
### ... un noyau ?
|
||||
|
||||
TODO Logos de différents noyaux
|
||||
|
||||
. . .
|
||||
|
||||
Oui !
|
||||
|
||||
### ... le temps de boot ?
|
||||
|
||||
. . .
|
||||
|
||||
* Initialisation du/des processeur(s) et de la mémoire ;
|
||||
* détection du matériel ;
|
||||
* préparation des interfaces pour l'userland ;
|
||||
* montage du système de fichiers racine ;
|
||||
* lancement de `/sbin/init`
|
||||
|
||||
### ... le système de fichiers ?
|
||||
|
||||
Eh oui !
|
||||
|
||||
### ... d'isoler ?
|
||||
|
||||
* Mutualisation des services
|
||||
|
||||
TODO 2-3 mots accrocheurs
|
||||
|
||||
|
||||
## Les techniques d'isolation
|
||||
|
||||
### `chroot`
|
||||
|
||||
* **Difficulté :** hardcore ;
|
||||
* **Sécurité :** douteuse ;
|
||||
* **Coûts :** élevés.
|
||||
|
||||
### Virtualisation et paravirtualisation
|
||||
|
||||
* **Difficulté :** débutant ;
|
||||
* **Sécurité :** OK ;
|
||||
* **Coûts :** réduits.
|
||||
|
||||
### Mais ...
|
||||
|
||||
TODO clipart lumière
|
||||
96
slides/slides.pdfpc
Normal file
96
slides/slides.pdfpc
Normal file
@ -0,0 +1,96 @@
|
||||
[file]
|
||||
slides.pdf
|
||||
[duration]
|
||||
180
|
||||
[notes]
|
||||
### 1
|
||||
Bonjour
|
||||
Hésitez pas à poser des questions
|
||||
### 2
|
||||
Commençons par parler de quelqu'un d'important...
|
||||
### 3
|
||||
Test
|
||||
### 4
|
||||
- Gestion de l'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, ...)
|
||||
- Diverses couches d'abstraction :
|
||||
- matériel : clavier/souris/...
|
||||
- FS
|
||||
### 5
|
||||
- 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, ...
|
||||
- montage de la racine
|
||||
- /sbin/init
|
||||
### 6
|
||||
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é ?
|
||||
### 7
|
||||
- grosse machine coûte moins cher
|
||||
- pourquoi partager les données de services qui ne communiquent pas entre eux ?
|
||||
=> serveur DNS, mails, web, de notation de l'école
|
||||
### 8
|
||||
DEMO chroot
|
||||
- complexe à mettre en œuvre
|
||||
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)
|
||||
### 9
|
||||
- accès concurent au matos : périphériques émulés
|
||||
- VT-x/AMD-v
|
||||
- plusieurs serveurs sur le même port
|
||||
- limitation des ressources
|
||||
- non partage des ressources similaires : autant de noyau lancé que de services, FS non partagés
|
||||
### 10
|
||||
- partager le même noyau (KVM...), les FS identiques (on met à jour le système de base une seule)
|
||||
|
||||
* 1998 : Jails BSD
|
||||
* 2005 : Zones Solaris
|
||||
* 2005 : patch Linux OpenVZ
|
||||
* 2008 : début du projet Linux Container (LXC)
|
||||
* 2015 : Windows 10
|
||||
|
||||
On appel ça des conteneurs !
|
||||
### 11
|
||||
Que doit-on implémenter concrétement ?
|
||||
- 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
|
||||
- users, groups, nom de machine et IPC : pas de raison qu'ils soient partagés
|
||||
- horloge : non, la timezone peut changer
|
||||
### 12
|
||||
- isoler plein de choses : Namespace
|
||||
DEMO make menuconfig
|
||||
DEMO namespace
|
||||
- limiter les ressources : cgroups
|
||||
DEMO make menuconfig
|
||||
DEMO limitation CPU
|
||||
DEMO limitation mémoire
|
||||
DEMO statistiques réseau
|
||||
- mais dans le monde Unix, root peut tout faire ... => capabilities
|
||||
DEMO capabilities
|
||||
### 13
|
||||
- crée listes distinctes ou ajoute des propriétés
|
||||
- FS : sous-arbre de la racine comme chroot + AUFS/OverlayFS (cache), LVM (thin provisioning)
|
||||
- Processus : premier lancé PID 1
|
||||
### 14
|
||||
- Réseau : pas évident :
|
||||
* 1 carte réseau = 1 seule IP
|
||||
* promiscuité
|
||||
* routage
|
||||
- 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.
|
||||
### 15
|
||||
LXC stable depuis
|
||||
Doit-on tout virtualiser ? avoir toutes les bibliothèques et fichiers de base (init, syslog, cron, sshd, ...) ?
|
||||
DEMO LXC busybox
|
||||
!!! QUESTIONS + PAUSE !!!
|
||||
Loading…
x
Reference in New Issue
Block a user