Slides 1 done
This commit is contained in:
parent
13bd205b1b
commit
e4f042a72f
Binary file not shown.
|
|
@ -0,0 +1,220 @@
|
|||
[file]
|
||||
1-docker's basis.pdf
|
||||
[skip]
|
||||
4,5,6,7,8,10,11,12,13,18,21,22,23,29,30,36,37,38,
|
||||
[end_user_slide]
|
||||
22
|
||||
[notes]
|
||||
### 1
|
||||
Après la piscine, on reste dans un thème aquatique, puisqu'on va parler de Docker aujourd'hui !
|
||||
|
||||
Sondage de repérage
|
||||
|
||||
* Qui a déjà entendu parlé de Docker ?
|
||||
* Qui a déjà utilisé au moins une fois ?
|
||||
* Est-ce que certain l'utilisent tous les jours ou presque ?
|
||||
|
||||
C'est vrai qu'une fois compris les principes, peut plus s'en passer.
|
||||
|
||||
* qqn déjà essayé un autre programme de virli ?
|
||||
|
||||
Pour les autres,
|
||||
on va p-e commencer par expliquer ce que c'est, la virli.### 2
|
||||
Déjà, la virtualisation ...
|
||||
|
||||
* La virtualisation classique
|
||||
|
||||
** gros serveur répondre pic de trafic quotidient, passe son temps à rien faire hors de ce pic => besoin d'optim
|
||||
** Déploiement fastidieux de services concurrent (ex. un serveur web) :
|
||||
- partager le port = partager la config
|
||||
- reverse proxy : ok tant que c'est deux soft différents
|
||||
- installation en parallèle de deux versions différentes hasardeuses et complexe
|
||||
|
||||
** Création du principe de machine virtuelle
|
||||
- émulation du matériel
|
||||
- gain en terme de sécu
|
||||
|
||||
** Aidé des instructions de virtualisation
|
||||
- le matériel reste émulé, mais prends des raccourcis lorsque supporté par l'hôte et l'invité (virtio)
|
||||
### 3
|
||||
* Quelles sont les grandes étapes de boot d'une machine moderne ?
|
||||
ground PS_ON, reset CPU, bootloader (BIOS/UEFI), chargeur d'amorce (GRUB, ...), noyau de l'OS, espace utilisateur (init, systemd, ...), daemons et applications utilisateur (logind, Xorg, ...)
|
||||
|
||||
* différences avec une machine virtuelle
|
||||
- création d'un espace d'adressage
|
||||
- vmenter
|
||||
|
||||
* Optimisation du reboot ?
|
||||
|
||||
* Pas encore très léger comme virtualisation
|
||||
on veut pas vraiment des multiples noyaux et système, simplement pour un daemon qui écoute sur une autre IP
|
||||
|
||||
* Virtualisation légère : le noyau peut isoler des systèmes différents
|
||||
- On a plus que l'espace utilisateur à recharger
|
||||
- Plein de technos font ça : OpenVZ, LXC, ...
|
||||
DEMO LXC VPS
|
||||
|
||||
* C'est mieux, mais on a encore des éléments inutiles : cron, init, ...
|
||||
=> Et si on lançait uniquement notre deamon ?
|
||||
DEMO docker owncloud, telegraf/graphana/... SRS FIC ?
|
||||
|
||||
* pub pour les cours 3 et 4 sur Linux Internals : NS + cg
|
||||
### 4
|
||||
* Scheduling simplifié
|
||||
* RAM mieux utilisée
|
||||
|
||||
- kernel unique
|
||||
- libc partagées
|
||||
- cache de fichiers unique (s'adapte à l'espace restant)
|
||||
### 5
|
||||
* Acteurs historiques
|
||||
- Zones Solaris
|
||||
- Jails BSD
|
||||
- OpenVZ
|
||||
|
||||
* Arnaques
|
||||
- Docker4mac
|
||||
- Docker4windows
|
||||
Microsoft Hyper-V
|
||||
Windows 10 Pro 64 bits
|
||||
|
||||
* En développement/test
|
||||
- Windows Containers
|
||||
Windows Server 2016
|
||||
Windows 10 Anniversary Edition
|
||||
### 6
|
||||
Questions ?
|
||||
### 7
|
||||
DAEMON
|
||||
* REST API
|
||||
* qui gère des Docker objects
|
||||
- images, conteneurs, services
|
||||
- réseaux, nœux de cluster
|
||||
- volumes
|
||||
* local registry
|
||||
* containerd/runc
|
||||
|
||||
CLIENT
|
||||
|
||||
Open Container Initiative
|
||||
|
||||
Docker hub/store
|
||||
### 8
|
||||
Image
|
||||
* Modèle en lecture seule
|
||||
* utilisé pour pour créer les conteneurs
|
||||
|
||||
Conteneur
|
||||
* Instance d'une image
|
||||
* isolé de tout de base, on règle après ce que l'on souhaite partager (réseau, stockage, ...)
|
||||
|
||||
Services
|
||||
* groupe de conteneurs qui forme une application
|
||||
### 9
|
||||
Démo
|
||||
|
||||
docker run touch /toto
|
||||
voir que dans un autre docker run, ls / ne montre pas foo
|
||||
### 10
|
||||
Commence par regarder en local si on a pas l'image
|
||||
|
||||
Ensuite il va interroger son registre par défaut, sans configuration, il s'agit du Docker Store.
|
||||
|
||||
Si l'on désucre le nom du conteneur, on obtient ce chemin
|
||||
|
||||
Le but de Docker étant de récupérer un fichier manifests
|
||||
|
||||
|
||||
On utilise la forme complètement quand on a un registre privé
|
||||
### 11
|
||||
Parler de l'ancienne syntaxe toujours d'actualité, mais beaucoup plus documentée
|
||||
### 12
|
||||
Démo
|
||||
|
||||
docker image ls
|
||||
docker image rm
|
||||
|
||||
docker container ls
|
||||
docker container rm
|
||||
docker container create
|
||||
### 13
|
||||
Comment fait-on pour créer une image ?
|
||||
|
||||
On va pouvoir créer une image (qui pourra donc servir de modèle pour créer d'autre cntr) à partir d'un conteneur que l'on décidera de figer à un instant donné.
|
||||
|
||||
=> docker commit
|
||||
|
||||
On indique lors du commit le conteneur à figer ainsi que lenom de l'image que l'on souhaite créer.### 14
|
||||
* CoW
|
||||
* layers/couches (docker image history IMAGE)
|
||||
* unionfs
|
||||
### 15
|
||||
Maintenant, comment faire en sorte que deux conteneur puissent se parler ?
|
||||
|
||||
On commence par lancer deux cntrs. et l'on demande explicitement à ce que le compteur nous expose son port 80.
|
||||
--
|
||||
On crée ensuite un objet Docker network, dans lequel on vient placer nos deux conteneurs.
|
||||
Ils peuvent alors se parler.
|
||||
--
|
||||
Mieux encore, un serveur DNS permet de résoudre le nom des conteneurs dans ce réseau, pour simplifier la configuration.
|
||||
|
||||
Si trop de temps :
|
||||
docker container run -P nginx
|
||||
docker container ls
|
||||
docker container port $ID
|
||||
go with firefox
|
||||
### 16
|
||||
On utilisé juste avant docker commit pour créer une nouvelle image à partir d'un conteneur. Mais on peut aussi utiliser ce qu'on appel des Dockerfile.
|
||||
|
||||
- fichier texte
|
||||
- instructions de base : FROM, RUN, COPY, CMD
|
||||
|
||||
DEMO hello srs 1
|
||||
|
||||
- passage du contexte au daemon
|
||||
- .dockerignore
|
||||
|
||||
- cache de construction
|
||||
|
||||
- bonnes pratiques à propos des installs :
|
||||
- minimise le nombre de couches
|
||||
faire la part des choses entre relecture/maintenabilité et nombre de couches
|
||||
### 17
|
||||
Dockerfile hello srs
|
||||
|
||||
À propos du linkage statique vs. dynamique
|
||||
### 18
|
||||
chaque ligne est exécutée dans un conteneur distinct
|
||||
les commandes ne servent qu'à modifier le système de fichier
|
||||
on ne peut pas lancer un programme, il sera fermé avec le conteneur
|
||||
|
||||
- bonnes pratiques à propos des installs :
|
||||
- pas d'upgrade
|
||||
- on clean les couches
|
||||
### 19
|
||||
Lorsqu'on a besoin de compiler un programme avant de le mettre dans un conteneur, pas besoin d'inclure le compilateur !
|
||||
### 20
|
||||
|
||||
|
||||
* volumes : une couche simple
|
||||
* bind mounts : partagés avec l'hôte
|
||||
|
||||
* volume-from : partage de volumes entre conteneurs
|
||||
|
||||
* tmpfs mounts : non persistant, uniquement dans la mémoire de l'hôte
|
||||
### 21
|
||||
Questions ?
|
||||
|
||||
- limiter les ressources
|
||||
- arrêter un conteneur
|
||||
- commandes détachées du terminal (-d) + docker logs
|
||||
### 22
|
||||
* Questionnaire sur Epitaf sur les notions de cours + recherches perso (pour éviter un partiel)
|
||||
* Demandez pour un partage de flux intéressants, d'articles cools sur le sujet, ...
|
||||
|
||||
* Rendus des exercices du TP + projet complémentaire par mail
|
||||
- signature PGP
|
||||
|
||||
* Correction au début du prochain cours => limite du rendu
|
||||
|
||||
* Sondage de satisfaction à la fin du cours : notez vos feedbacks !
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 160 KiB |
|
|
@ -1,22 +0,0 @@
|
|||
SOURCES = slides.md intro.md os.md containers.md apps.md conclusion.md
|
||||
HEADER = header.tex
|
||||
TEMPLATE = CambridgeUS
|
||||
COLORTHEME = beaver
|
||||
PANDOCOPTS = --latex-engine=xelatex \
|
||||
-t beamer \
|
||||
-V theme:${TEMPLATE} \
|
||||
-V colortheme:${COLORTHEME} \
|
||||
--standalone \
|
||||
--normalize \
|
||||
--slide-level=3 \
|
||||
-M lang=frenchb \
|
||||
--include-in-header=${HEADER}
|
||||
|
||||
|
||||
all: slides.pdf
|
||||
|
||||
slides.pdf: ${SOURCES}
|
||||
pandoc ${PANDOCOPTS} -o $@ $+
|
||||
|
||||
clean::
|
||||
rm slides.pdf
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
# Conteneurs applicatif
|
||||
|
||||
## Grandes idées
|
||||
|
||||
----
|
||||
|
||||
|
||||
|
||||
----
|
||||
|
||||
|
||||
|
||||
|
||||
## Quelques bonnes pratiques
|
||||
|
||||
----
|
||||
|
||||
#### Ne pas mettre à jour ou patcher une image
|
||||
|
||||
. . .
|
||||
|
||||
#### Garder les couches propres
|
||||
|
||||
* `apt-get clean`
|
||||
* `docker squash`
|
||||
|
||||
. . .
|
||||
|
||||
#### 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
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 244 KiB |
|
|
@ -1,15 +0,0 @@
|
|||
# Conclusion
|
||||
|
||||
## Problèmes, soucis et choses pas claires
|
||||
|
||||
### Et maintenant ?
|
||||
|
||||
#### Sécurité
|
||||
|
||||
Cf. conteneurs chez Amazon
|
||||
|
||||
. . .
|
||||
|
||||
#### Ordonancement des ressources
|
||||
|
||||
|
||||
|
|
@ -1,167 +0,0 @@
|
|||
# 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 ...
|
||||
|
||||
|
||||
|
||||
----
|
||||
|
||||
#### 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.
|
||||
|
||||
`namespaces(7)`
|
||||
|
||||
. . .
|
||||
|
||||
#### CGroups
|
||||
|
||||
Statistiques sur l'utilisation des ressources et limitation.
|
||||
|
||||
<https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt>
|
||||
|
||||
. . .
|
||||
|
||||
#### Capabilities
|
||||
|
||||
Limitation de ce que `root` peut faire.
|
||||
|
||||
`capabilities(7)`
|
||||
|
||||
|
||||
## pour les nuls
|
||||
|
||||
### Mais Jamy, comment ça marche ?
|
||||
|
||||
|
||||
|
||||
|
||||
### Syscall
|
||||
|
||||
* `clone`
|
||||
* `unshare`
|
||||
* `setns`
|
||||
|
||||
. . .
|
||||
|
||||
#### Exemple
|
||||
|
||||
```c
|
||||
int fd;
|
||||
|
||||
/* Get descriptor for namespace */
|
||||
fd = open("/proc/PID/ns/FILE", O_RDONLY);
|
||||
|
||||
/* Join that namespace */
|
||||
setns(fd, 0);
|
||||
```
|
||||
|
||||
----
|
||||
|
||||
```
|
||||
PATH FILESYSTEM
|
||||
/ /dev/sda1
|
||||
├── dev
|
||||
├── proc
|
||||
├── sys
|
||||
├── usr
|
||||
└── var
|
||||
├── cntrs
|
||||
│ ├── toto /dev/sda5
|
||||
│ │ ├── dev
|
||||
│ │ ├── proc
|
||||
│ │ ├── sys
|
||||
│ │ └── usr
|
||||
│ └── virli /dev/sda6
|
||||
│ ├── dev
|
||||
│ ├── proc
|
||||
│ ├── sys
|
||||
│ └── usr
|
||||
├── log
|
||||
└── tmp
|
||||
```
|
||||
|
||||
### Système de fichiers
|
||||
|
||||
* `pivot_root(2)`
|
||||
* Thin provisioning
|
||||
* Union FileSystems
|
||||
|
||||
### Union FileSystem
|
||||
|
||||
|
||||
|
||||
|
||||
### Le réseau ...
|
||||
|
||||
|
||||
|
||||
|
||||
### Le réseau ...
|
||||
|
||||
#### Interface physique
|
||||
|
||||
Facile ! Mais il en faut beaucoup.
|
||||
|
||||
. . .
|
||||
|
||||
#### VLAN
|
||||
|
||||
Un tag par conteneur. Routage *interne* par le switch en amont.
|
||||
|
||||
. . .
|
||||
|
||||
#### 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 février 2014.
|
||||
|
||||
Attention à la configuration et aux erreur avec les `capabilities` !
|
||||
|
||||
. . .
|
||||
|
||||
#### Partage des systèmes de fichiers
|
||||
|
||||
Optimise l'utilisation du cache du système de fichiers :-)
|
||||
|
||||
. . .
|
||||
|
||||
N'optimise pas le travail de l'administrateur système :-(
|
||||
BIN
slides/cps.jpg
BIN
slides/cps.jpg
Binary file not shown.
|
Before Width: | Height: | Size: 165 KiB |
BIN
slides/dmesg.png
BIN
slides/dmesg.png
Binary file not shown.
|
Before Width: | Height: | Size: 122 KiB |
|
|
@ -1,215 +0,0 @@
|
|||
# GNU/Linux
|
||||
|
||||
## Namespaces & cgroups
|
||||
|
||||
### Isolation du système
|
||||
|
||||
#### Mount Namespace
|
||||
|
||||
Isole la vue des partitions montées.
|
||||
|
||||
#### UTS Namespace
|
||||
|
||||
Identification du système : nom de machine et de domaine.
|
||||
|
||||
#### PID Namespace
|
||||
|
||||
Crée un arbre d'exécution parallèle où le premier process à être
|
||||
exécuté devient le PID 1 de cet arbre.
|
||||
|
||||
### Isolation du système
|
||||
|
||||
#### Network Namespace
|
||||
|
||||
Isole la pile réseau ; crée un nouveau groupe d'interfaces.
|
||||
|
||||
#### User Namespace
|
||||
|
||||
Crée une liste d'utilisateurs et de groupe distincte.
|
||||
|
||||
#### IPC Namespace
|
||||
|
||||
Isolation des files de messages de communication interprocessus (IPC).
|
||||
|
||||
|
||||
### Implémentation
|
||||
|
||||
```c
|
||||
#include <sched.h>
|
||||
|
||||
#define STACKSIZE (1024*1024)
|
||||
static char child_stack[STACKSIZE];
|
||||
|
||||
int clone_flags = CLONE_NEWNET | SIGCHLD;
|
||||
|
||||
pid_t pid = clone(do_execvp,
|
||||
child_stack + STACKSIZE,
|
||||
clone_flags,
|
||||
&args);
|
||||
```
|
||||
|
||||
### cgroups
|
||||
|
||||
`/sys/fs/cgroup/`
|
||||
|
||||
#### Block I/O
|
||||
|
||||
* Limitation de la bande passante lecture/écriture ;
|
||||
* poids d'un groupe ;
|
||||
* métriques: IOPS, latence, file d'attente.
|
||||
|
||||
#### CPU
|
||||
|
||||
* Poids d'utilisation du CPU ;
|
||||
* statistiques d'utilisation
|
||||
|
||||
### cgroups
|
||||
|
||||
`/sys/fs/cgroup/`
|
||||
|
||||
#### Mémoire
|
||||
|
||||
* Limite de taille ;
|
||||
* métriques : total rss, swap, nb pages in/out
|
||||
|
||||
#### Autres
|
||||
|
||||
Réseau, périphériques, gel de processus, ...
|
||||
|
||||
|
||||
### cgroups
|
||||
|
||||
#### Création de cgroups
|
||||
|
||||
```
|
||||
mkdir -p /sys/fs/cgroup/blkio/test1/ /sys/fs/cgroup/blkio/test2
|
||||
```
|
||||
|
||||
#### Altération d'une valeur
|
||||
|
||||
```
|
||||
echo 1000 > /sys/fs/cgroup/blkio/test1/blkio.weight
|
||||
echo 500 > /sys/fs/cgroup/blkio/test2/blkio.weight
|
||||
```
|
||||
|
||||
#### Assignation des tâches aux cgroups
|
||||
|
||||
```
|
||||
dd if=/mnt/sdb/zerofile1 of=/dev/null &
|
||||
echo $! > /sys/fs/cgroup/blkio/test1/tasks
|
||||
|
||||
dd if=/mnt/sdb/zerofile2 of=/dev/null &
|
||||
echo $! > /sys/fs/cgroup/blkio/test2/tasks
|
||||
```
|
||||
|
||||
|
||||
## Capabilities
|
||||
|
||||
### Résumé
|
||||
|
||||
#### Historiquement
|
||||
|
||||
* Processus privilégiés : `UID == 0`.
|
||||
* Processus non-privilégiés : `UID != 0`.
|
||||
|
||||
#### Depuis Linux 2.2
|
||||
|
||||
* Séparation des privilèges de l'UID 0.
|
||||
* Chaque thread peut posséder ses propres capacités.
|
||||
* `prctl(2)`, `execve(2)`, `clone(2)`, ...
|
||||
|
||||
### Principales capacités
|
||||
|
||||
#### Ne pas oublier de désactiver
|
||||
|
||||
* `CAP_MKNOD` : `mknod`
|
||||
* `CAP_NET_RAW` : permet d'écouter tout le réseau
|
||||
* `CAP_SYS_MODULE` : charge et décharge des modules noyau
|
||||
* `CAP_SYS_RAWIO` : accès brut aux entrées/sorties
|
||||
* `CAP_SYS_RESOURCE` : dépassement des quotas, utilisation de l'espace réservé, ...
|
||||
* `CAP_SYS_TIME` : changer l'heure de la machine
|
||||
* `CAP_SYS_ADMIN` : misc
|
||||
* ...
|
||||
|
||||
## Isolateurs
|
||||
|
||||
### `systemd`
|
||||
|
||||
* Chaque service est démarré dans un cgroup ;
|
||||
* on peut appliquer des limites au groupe en modifiant le `.service` ;
|
||||
* `systemd-nspawn` pour créer manuellement un nouveau namespace.
|
||||
|
||||
```ini
|
||||
[Service]
|
||||
CPUShares=1500
|
||||
MemoryLimit=1G
|
||||
BlockIOWeight=500
|
||||
```
|
||||
|
||||
### LXC
|
||||
|
||||
* Lance un système complet à partir de `/sbin/init` ;
|
||||
* se configure via un fichier de configuration :
|
||||
|
||||
```ini
|
||||
lxc.rootfs = /var/lib/lxc/toto/rootfs
|
||||
lxc.utsname = toto
|
||||
|
||||
lxc.network.type = veth
|
||||
lxc.network.hwaddr = 00:16:3e:c6:0e:04
|
||||
lxc.network.flags = up
|
||||
lxc.network.link = tap0
|
||||
lxc.network.name = eth0
|
||||
|
||||
lxc.tty = 4
|
||||
lxc.pts = 1024
|
||||
lxc.cap.drop = mac_admin mac_override
|
||||
```
|
||||
|
||||
### Docker
|
||||
|
||||
* Lance une application, packagée dans son environnement ;
|
||||
* création d'environnement possible à partir de `Dockerfile` :
|
||||
|
||||
```
|
||||
FROM debian:wheezy
|
||||
RUN groupadd -r mysql && useradd -r -g mysql mysql
|
||||
RUN apt-get update && apt-get install -y perl
|
||||
ENV MYSQL_MAJOR 5.7
|
||||
VOLUME /var/lib/mysql
|
||||
COPY docker-entrypoint.sh /entrypoint.sh
|
||||
ENTRYPOINT ["/entrypoint.sh"]
|
||||
EXPOSE 3306
|
||||
CMD ["mysqld", "--datadir=/var/lib/mysql"]
|
||||
```
|
||||
|
||||
|
||||
## Réseau
|
||||
|
||||
### Réseaux physiques
|
||||
|
||||
#### empty
|
||||
|
||||
Loopback uniquement, n'ajoute aucune interface.
|
||||
|
||||
#### phys
|
||||
|
||||
Utilisation d'une interface physique directement.
|
||||
|
||||
#### vlan
|
||||
|
||||
Assignation d'un VLAN à chaque conteneur.
|
||||
|
||||
|
||||
### Réseaux virtuels
|
||||
|
||||
#### veth
|
||||
|
||||
On crée une interface virtuelle sur l'hôte que l'on connecte à un bridge.
|
||||
|
||||
#### 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.
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
\setbeamertemplate{title page}[default][colsep=-4bp,rounded=true]
|
||||
\setbeamertemplate{blocks}[rounded][shadow=false]
|
||||
\setbeamercolor*{item}{fg=gray}
|
||||
\setbeamercolor*{block title}{fg=darkred}
|
||||
\setsansfont[Ligatures=Common]{LinBiolinum}
|
||||
%\setmonofont{fantasque-sans-mono}
|
||||
\setmonofont{Inconsolata}
|
||||
\useinnertheme{rectangles}
|
||||
\beamertemplatenavigationsymbolsempty
|
||||
\AtBeginSection{}
|
||||
\AtBeginSubsection{}
|
||||
BIN
slides/idea.jpg
BIN
slides/idea.jpg
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
|
|
@ -1,13 +0,0 @@
|
|||
# Avant tout...
|
||||
|
||||
## John von Neumann
|
||||
|
||||
----
|
||||
|
||||
|
||||
|
||||
. . .
|
||||
|
||||
À propos du langage assembleur :
|
||||
|
||||
> Why would you want more than machine language?
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 220 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 172 KiB |
73
slides/os.md
73
slides/os.md
|
|
@ -1,73 +0,0 @@
|
|||
# Système d'exploitation vs. hyperviseur
|
||||
|
||||
## Est-ce bien nécessaire ...
|
||||
|
||||
### ... un noyau ?
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### ... le temps de boot ?
|
||||
|
||||
|
||||
|
||||
. . .
|
||||
|
||||
<https://0xax.gitbooks.io/linux-insides/content/>
|
||||
|
||||
|
||||
### ... le système de fichiers ?
|
||||
|
||||
```
|
||||
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 ?
|
||||
|
||||
> * Sécurité (root, exploit, ...) ;
|
||||
> * 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.
|
||||
|
||||
|
||||
## Les techniques d'isolation
|
||||
|
||||
----
|
||||
|
||||
> * `chroot`
|
||||
> * Virtualisation et paravirtualisation
|
||||
|
||||
|
||||
### Mais ...
|
||||
|
||||
. . .
|
||||
|
||||
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
# En production
|
||||
|
||||
### LXC API
|
||||
|
||||
```python
|
||||
import lxc
|
||||
import sys
|
||||
|
||||
# Setup the container object
|
||||
c = lxc.Container("apicontainer")
|
||||
|
||||
# Create the container rootfs
|
||||
c.create("download", lxc.LXC_CREATE_QUIET,
|
||||
{"dist": "ubuntu", "release": "trusty",
|
||||
"arch": "i386"})
|
||||
|
||||
# Start the container
|
||||
if not c.start():
|
||||
print("Failed to start the container")
|
||||
sys.exit(1)
|
||||
```
|
||||
|
||||
### Projets naissants
|
||||
|
||||
#### Core OS
|
||||
|
||||
* Système d'exploitation minimaliste ;
|
||||
* fleet : systemd administrable à distance ;
|
||||
* lance des conteneur via fichiers de service Systemd.
|
||||
|
||||
#### Citadel
|
||||
|
||||
* Interaction avec un cluster Docker ;
|
||||
* schedule l'emplacement d'exécution des conteneurs.
|
||||
|
||||
#### Shipyard
|
||||
|
||||
* Interface web pour gérer son cluster Docker.
|
||||
|
|
@ -1,147 +0,0 @@
|
|||
# Rappels & historique
|
||||
|
||||
## Rappels sur la virtualisation classique
|
||||
|
||||
### Prémices
|
||||
|
||||
#### Au départ
|
||||
|
||||
Exécuter simultanément plusieurs environnements distinct sur un
|
||||
mainframe IBM.
|
||||
|
||||
#### IBM System/370
|
||||
|
||||
* Virtualisation grâce au système CP/CMS ;
|
||||
* permis par la présence d'une MMU et par l'ajout d'un mode
|
||||
*supervisor* au processeur.
|
||||
|
||||
### Vocabulaire
|
||||
|
||||
* Machine hôte/host machine
|
||||
* Machine invité/guest machine
|
||||
|
||||
#### Virtualisation vs. émulation
|
||||
|
||||
* Émulation : simulation logiciel de matériel (potentiellement une architecture différente) : pas d'accès direct au matériel ;
|
||||
* Virtualisation : accès direct, mais restrint, au matériel.
|
||||
|
||||
#### Technologies de virtualisation matérielle
|
||||
|
||||
* Intel VT-x/AMD-V/ARM Virtualization Extensions
|
||||
* partitionne le processeur pour exécuter plusieurs système d'exploitation via le même processeur.
|
||||
|
||||
|
||||
### Comment virtualiser ?
|
||||
|
||||
* Full virtualisation : hyperviseurs ;
|
||||
* Paravirtualisation ;
|
||||
* Isolateurs/conteneurs ;
|
||||
* Conteneurs applicatifs.
|
||||
|
||||
### Hyperviseurs
|
||||
|
||||
|
||||
|
||||
### Hyperviseurs
|
||||
|
||||
Contrôlent l'utilisation faite des ressources de la machine hôte par les
|
||||
machines virtuelles.
|
||||
|
||||
#### Type 1
|
||||
|
||||
* L'hyperviseur contrôle directement le matériel ;
|
||||
* Tous les systèmes lancés par la suite passent par l'hyperviseur.
|
||||
|
||||
* Microsoft Hyper-V, XenServer, VMware ESX, ...
|
||||
|
||||
#### Type 2
|
||||
|
||||
* L'hyperviseur s'appuie sur le système d'exploitation déjà lancé pour accéder
|
||||
au matériel ;
|
||||
|
||||
* Linux KVM, VirtualBox, BHyVe, ...
|
||||
|
||||
|
||||
### Paravirtualisation
|
||||
|
||||
#### Caractéristiques
|
||||
|
||||
* Nécessite un noyau patché ;
|
||||
* l'hôte expose une API accessible aux invités ;
|
||||
* les invités accèdent au matériel via l'API de l'hôte.
|
||||
|
||||
#### Exemple
|
||||
|
||||
* Xen
|
||||
|
||||
|
||||
## Virtualisation légère
|
||||
|
||||
### Conteneur
|
||||
|
||||
|
||||
|
||||
### Conteneur
|
||||
|
||||
#### Caractéristiques
|
||||
|
||||
* Isolation faite par le noyau de l'hôte ;
|
||||
* le noyau est partagé entre tous les invités ;
|
||||
* les périphériques sont déjà en place (pas besoin d'en émuler) ;
|
||||
* l'invité démarre à partir de `/sbin/init`.
|
||||
|
||||
|
||||
### Conteneurs applicatifs
|
||||
|
||||
|
||||
|
||||
### Conteneurs applicatifs
|
||||
|
||||
#### Caractéristiques
|
||||
|
||||
* Noyau est partagé avec l'hôte ;
|
||||
* on utilise tout en place : fs, sockets, périphériques ;
|
||||
* lance directement une application, pas `init`.
|
||||
|
||||
#### Versus chroot
|
||||
|
||||
* Simple isolation d'une partie du système de fichiers ;
|
||||
* pas de limitation sur les ressources utilisés ;
|
||||
* pas d'isolation de l'arbre des processus ;
|
||||
* implémentations douteuses (GrSecurity !).
|
||||
|
||||
|
||||
## Différentes implémentations
|
||||
|
||||
### Points communs
|
||||
|
||||
#### Environnement virtualisé
|
||||
|
||||
* Arborescence de fichiers séparée ;
|
||||
* arbre de processus isolé ;
|
||||
* comptes utilisateurs distincts ;
|
||||
* pile réseau et nom de machine propre.
|
||||
|
||||
### Diversité
|
||||
|
||||
#### Unix
|
||||
|
||||
* **FreeBSD :** Jails lancées en 1998 ;
|
||||
* **Solaris :** Zones lancées en 2005 ;
|
||||
|
||||
#### GNU/Linux
|
||||
|
||||
* **OpenVZ :** 2005, nécessite de patcher son kernel ;
|
||||
* **Linux Containers (LXC) :** 2008, basé sur les namespaces et les cgroups ;
|
||||
* **Docker :** 2013, en pleine croissance !
|
||||
|
||||
### Et Windows ?
|
||||
|
||||
#### Isolation
|
||||
|
||||
* Parallels Virtuozzo Containers ;
|
||||
* Sandboxie.
|
||||
|
||||
#### Dérivés
|
||||
|
||||
* **Boot2Docker :** Docker dans une VM.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
% Virtualisation légère
|
||||
% Pierre-Olivier Mercier
|
||||
% Jeudi 1^er^ octobre 2015
|
||||
|
|
@ -1,201 +0,0 @@
|
|||
[file]
|
||||
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, 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
|
||||
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) => abouti aux noyaux
|
||||
### 3
|
||||
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
|
||||
- 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
|
||||
- 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, 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, partage de fichiers réseau, etc.
|
||||
### 5
|
||||
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, ...
|
||||
|
||||
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
|
||||
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 (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
|
||||
=> ok pour de la défense en profondeur
|
||||
Exemple : ING1 exams machine
|
||||
### 8
|
||||
- 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
|
||||
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 (heu ...)
|
||||
|
||||
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/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 PAUSE?
|
||||
### 11
|
||||
Que doit-on implémenter concrétement ?
|
||||
- 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)
|
||||
=> 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
|
||||
* un process appartient à un seul cgroup à la fois
|
||||
* hiérarchie : un hérite des propriété de ses parents
|
||||
* un cgroup par défaut pour tous les process
|
||||
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
|
||||
### 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
|
||||
- processus : premier lancé PID 1 (2 PID : in/out NS)
|
||||
- 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
|
||||
### 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
|
||||
|
||||
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)
|
||||
### 20
|
||||
- Réseau : pas évident :
|
||||
* 1 carte réseau = 1 seule IP
|
||||
* promiscuité
|
||||
* routage
|
||||
### 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
|
||||
### 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 ?
|
||||
### 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 (hub.dckr) puis install
|
||||
DEMO docker run --rm -it mdebian => nginx
|
||||
DEMO Dockerfile
|
||||
=> mais on lance que le prog, pas init et tout
|
||||
=> 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 !
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 762 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Loading…
Reference in New Issue