WIP tuto 1
This commit is contained in:
parent
2cc4d7567d
commit
2060cf899e
@ -41,10 +41,10 @@ utilise la commande `images` :
|
|||||||
docker images
|
docker images
|
||||||
```
|
```
|
||||||
|
|
||||||
Nous devrions constater la présence de deux images « Ubuntu », ayant un *TAG*
|
Vous devriez constater la présence de plusieurs images « Ubuntu », mais chacune
|
||||||
différent. Souvent, il existe plusieurs versions d'une même image. Pour Ubuntu
|
a un *TAG* différent. En effet, souven, il existe plusieurs versions d'une même
|
||||||
par exemple, nous avons la possibilité de lancer la version `precise`, `trusty`,
|
image. Pour Ubuntu par exemple, nous avons la possibilité de lancer la version
|
||||||
`xenial` ou `yakkety`.
|
`precise`, `trusty`, `xenial` ou `yakkety`.
|
||||||
|
|
||||||
Chaque image est identifiable par son *Image ID* unique ; les noms d'images
|
Chaque image est identifiable par son *Image ID* unique ; les noms d'images
|
||||||
ainsi que leurs tags sont, comme les tags Git, une manière humainement plus
|
ainsi que leurs tags sont, comme les tags Git, une manière humainement plus
|
||||||
@ -72,24 +72,93 @@ Dans notre exemple, c'est bien le `/bin/echo` présent dans le conteneur qui est
|
|||||||
appelé. Ce n'est pas le programme `/bin/echo` de la machine hôte qui a été
|
appelé. Ce n'est pas le programme `/bin/echo` de la machine hôte qui a été
|
||||||
transféré dans le conteneur.
|
transféré dans le conteneur.
|
||||||
|
|
||||||
|
Pour nous en convaincre, nous pouvons tenter d'exécuter un programme qui n'est
|
||||||
|
pas présent sur notre machine, mais bien uniquement dans le conteneur. Si vous
|
||||||
|
n'utilisez pas [Alpine Linux](https://www.alpine-linux.org), vous pourriez
|
||||||
|
tenter d'utiliser son gestionnaire de paquet `apk`, via :
|
||||||
|
|
||||||
## Modifier un conteneur
|
```
|
||||||
|
docker run alpine /sbin/apk stats
|
||||||
|
```
|
||||||
|
|
||||||
À chaque fois que nous lançons un `run`, un nouveau conteneur est créé à partir
|
|
||||||
de l'image que l'on a précisé (via un mécanisme de *Copy-On-Write*, c'est donc
|
|
||||||
très rapide et ne consomme pas beaucoup d'espace disque). Cela signifie que
|
|
||||||
lorsque nous exécutons une commande modifiant les fichiers d'un conteneur, cela
|
|
||||||
ne modifie pas l'image de base, mais crée une nouvelle image. Que nous pouvons
|
|
||||||
ensuite utiliser comme image de base.
|
|
||||||
|
|
||||||
Commençons par entrer dans un nouveau conteneur pour modifier l'image :
|
## Modifier une image
|
||||||
|
|
||||||
|
### Images vs. conteneurs
|
||||||
|
|
||||||
|
À chaque fois que nous lançons un `run`, un nouveau conteneur est créé.
|
||||||
|
L'image fournie comme argument est utilisée comme un modèle de base pour le
|
||||||
|
conteneur et est recopiée grâce à un mécanisme de *Copy-On-Write* : c'est donc
|
||||||
|
très rapide et ne consomme pas beaucoup d'espace disque.
|
||||||
|
|
||||||
|
Étant donné que chaque conteneur est créé à partir d'un modèle, cela signifie
|
||||||
|
que lorsque nous exécutons une commande modifiant les fichiers d'un conteneur,
|
||||||
|
cela ne modifie pas l'image de base, mais crée une nouvelle image. Que nous
|
||||||
|
pouvons ensuite utiliser comme image de base.
|
||||||
|
|
||||||
|
![Images vs. conteneurs](img-vs-cntr.png "Images vs. conteneurs")
|
||||||
|
|
||||||
|
Dans ce schéma, on considère les images comme étant la partie figée de Docker à
|
||||||
|
partir desquelles on peut créer des conteneurs.
|
||||||
|
|
||||||
|
Si l'on souhaite qu'une modification faite dans un conteneur (par exemple
|
||||||
|
l'installation d'un paquet) s'applique à d'autres conteneurs, il va falloir
|
||||||
|
créer une nouvelle image à partir de ce conteneur.
|
||||||
|
|
||||||
|
|
||||||
|
### Les paramètres
|
||||||
|
|
||||||
|
Pour créer une image, commençons par entrer dans un nouveau conteneur :
|
||||||
|
|
||||||
```
|
```
|
||||||
docker run -it ubuntu /bin/bash
|
docker run -it ubuntu /bin/bash
|
||||||
```
|
```
|
||||||
|
|
||||||
Nous voilà maintenant dans le conteneur ! Il est assez épuré, il n'y a rien de
|
Vous avez remarqué l'utilisation des options `--tty` et `--interactive` ? Avant
|
||||||
superflu : il n'y a même pas d'éditeur de texte : ni vim, ni emacs, même pas
|
le nom de l'image, elles sont gérées par Docker pour modifier le comportement
|
||||||
|
du `run`. En fait, tout comme `git(1)` et ses sous-commandes, chaque niveau de
|
||||||
|
commande peut prendre des paramètres :
|
||||||
|
|
||||||
|
```
|
||||||
|
docker DOCKER_PARAMS run RUN_OPTS image IMAGE_CMD IMAGE_ARGS ...
|
||||||
|
```
|
||||||
|
|
||||||
|
Par exemple :
|
||||||
|
|
||||||
|
```
|
||||||
|
docker -H unix:///var/run/docker.sock run -it alpine /bin/ash -c "echo foo"
|
||||||
|
```
|
||||||
|
|
||||||
|
Ici, l'option `-H` sera traitée par le client Docker (pour définir
|
||||||
|
l'emplacement du point de communication avec le daemon), tandis que les options
|
||||||
|
`-it` seront utilisées lors du traitement du `run`. Quant au `-c`, il sera
|
||||||
|
simplement tranmis au conteneur comme argument au premier `execve(2)` du
|
||||||
|
conteneur.
|
||||||
|
|
||||||
|
Avec l'option `--interactive`, on s'assure que l'entrée standard ne sera pas
|
||||||
|
fermée (`close(2)`)[^whyclose]. Nous demandons également l'allocation d'un TTY,
|
||||||
|
sans quoi `bash` ne se lancera pas en mode interractif[^bashnointer].
|
||||||
|
|
||||||
|
[^whyclose]: TODO
|
||||||
|
|
||||||
|
[^bashnointer]: Mais il sera possible de l'utiliser sans allouer de TTY, comme
|
||||||
|
par exemple en faisant :
|
||||||
|
|
||||||
|
```
|
||||||
|
42sh$ cat cmd
|
||||||
|
echo foo
|
||||||
|
42sh$ cat cmd | docker run -i busybox
|
||||||
|
foo
|
||||||
|
```
|
||||||
|
|
||||||
|
L'option `-i` reste néanmoins nécessaire pour que l'entrée standard soit
|
||||||
|
transmise au conteneur.
|
||||||
|
|
||||||
|
|
||||||
|
### Modification interractive
|
||||||
|
|
||||||
|
Nous voilà maintenant dans le conteneur ! Il est assez épuré, il n'y a rien
|
||||||
|
de superflu : il n'y a même pas d'éditeur de texte : ni vim, ni emacs, même pas
|
||||||
`vi` !
|
`vi` !
|
||||||
|
|
||||||
La première chose à faire est de télécharger la liste des paquets. En effet,
|
La première chose à faire est de télécharger la liste des paquets. En effet,
|
||||||
|
@ -3,13 +3,13 @@ title: Virtualisation légère -- TP n^o^ 1
|
|||||||
subtitle: Les bases de Docker
|
subtitle: Les bases de Docker
|
||||||
author: Pierre-Olivier *Nemunaire* Mercier
|
author: Pierre-Olivier *Nemunaire* Mercier
|
||||||
institute: EPITA
|
institute: EPITA
|
||||||
date: Jeudi 8 septembre 2016
|
date: Jeudi 5 octobre 2017
|
||||||
...
|
...
|
||||||
|
|
||||||
Durant ce premier TP, nous allons apprendre à utiliser Docker !
|
Durant ce premier TP, nous allons apprendre à utiliser Docker !
|
||||||
|
|
||||||
Tous les éléments de ce TP (exercices et questions) sont à rendre à
|
Tous les éléments de ce TP (exercices et questions) sont à rendre à
|
||||||
<virli@nemunai.re> au plus tard le jeudi 15 septembre 2016 à 8 h 42. Consultez la
|
<virli@nemunai.re> au plus tard le jeudi 19 octobre 2017 à 8 h 42. Consultez la
|
||||||
dernière section de chaque partie pour plus d'information sur les éléments à
|
dernière section de chaque partie pour plus d'information sur les éléments à
|
||||||
rendre.
|
rendre.
|
||||||
|
|
||||||
|
@ -3,8 +3,8 @@
|
|||||||
Composition de Docker
|
Composition de Docker
|
||||||
=====================
|
=====================
|
||||||
|
|
||||||
Docker est une suite d'outils de haut niveau, permettant d'utiliser les
|
Docker est un écosystème d'outils de haut niveau, permettant d'utiliser des
|
||||||
conteneurs.
|
*conteneurs*.
|
||||||
|
|
||||||
Docker est composé d'un daemon lancé au démarrage de votre machine, avec lequel
|
Docker est composé d'un daemon lancé au démarrage de votre machine, avec lequel
|
||||||
vous interagissez via un client (le programme `docker`). La communication entre
|
vous interagissez via un client (le programme `docker`). La communication entre
|
||||||
|
Loading…
Reference in New Issue
Block a user