TP1 WIP
This commit is contained in:
parent
fe77666200
commit
7a1d5d9981
10 changed files with 189 additions and 219 deletions
|
|
@ -3,10 +3,11 @@
|
|||
Mon premier conteneur
|
||||
=====================
|
||||
|
||||
Afin de tester la bonne marche de votre installation, exécutons la commande :
|
||||
Afin de tester la bonne marche de notre installation, lançons notre premier
|
||||
conteneur avec la commande :
|
||||
|
||||
```
|
||||
docker run hello-world
|
||||
docker container run hello-world
|
||||
```
|
||||
|
||||
Cette commande va automatiquement exécuter une série de commandes pour nous,
|
||||
|
|
@ -14,45 +15,59 @@ comme indiqué dans le message affiché en retour :
|
|||
|
||||
D'abord, le daemon va rechercher s'il possède localement l'image
|
||||
*hello-world*. Si ce n'est pas le cas, il va aller la récupérer sur
|
||||
`hub.docker.com`. Ce site met à disposition un grand nombre d'images : des
|
||||
`store.docker.com`. Ce site met à disposition un grand nombre d'images : des
|
||||
systèmes de base comme Ubuntu, Debian, Centos, etc. jusqu'à des conteneurs
|
||||
prêts à l'emploi : le serveur web nginx, la base de données MySQL, un serveur
|
||||
node.js, etc.
|
||||
|
||||
Nous pouvons directement utiliser le client pour rechercher une image sur le
|
||||
hub, en utilisant la commande `search` :
|
||||
Store, en utilisant la commande `search` :
|
||||
|
||||
```
|
||||
docker search mariadb
|
||||
```
|
||||
|
||||
Il est possible de mettre à jour les images locales ou simplement
|
||||
pré-télécharger des images depuis le hub en utilisant la commande `pull` :
|
||||
pré-télécharger des images depuis le Store en utilisant la commande `pull` :
|
||||
|
||||
```
|
||||
docker pull ubuntu
|
||||
docker image pull ubuntu
|
||||
```
|
||||
|
||||
Pour consulter la liste des images dont nous disposons localement (soit parce
|
||||
qu'on les a téléchargées, soit parce que nous les avons créées nous-même), on
|
||||
utilise la commande `images` :
|
||||
Remarquez comment on interagit avec chaque *objet Docker* : dans la ligne de
|
||||
commande, le premier mot clef est le type d'objet (`container`, `image`,
|
||||
`service`, `network`, `volume`, ...) ; ensuite, vient l'action que l'on
|
||||
souhaite faire dans ce cadre.[^oldcall]
|
||||
|
||||
[^oldcall]: cela n'a pas toujours été aussi simple, cette syntaxe n'existe que
|
||||
depuis la version 1.13 (janvier 2017). C'est pourquoi, lorsque vous ferez
|
||||
des recherches sur internet, vous trouverez de nombreux articles utilisant
|
||||
l'ancienne syntaxe, sans le type d'objets : `docker images` au lieu de
|
||||
`docker image ls`, `docker run` au lieu de `docker container run`, ...
|
||||
|
||||
L'ancienne syntaxe est dépréciée, mais il reste actuellement possible de
|
||||
l'utiliser.
|
||||
|
||||
Par exemple, pour consulter la liste des images dont nous disposons localement
|
||||
(soit parce qu'on les a téléchargées, soit parce que nous les avons créées
|
||||
nous-même), on utilise la commande `ls` sous le type d'objets `image` :
|
||||
|
||||
```
|
||||
docker images
|
||||
docker image ls
|
||||
```
|
||||
|
||||
Vous devriez constater la présence de plusieurs images « Ubuntu », mais chacune
|
||||
a un *TAG* différent. En effet, souven, il existe plusieurs versions d'une même
|
||||
image. Pour Ubuntu par exemple, nous avons la possibilité de lancer la version
|
||||
`precise`, `trusty`, `xenial` ou `yakkety`.
|
||||
`trusty`, `xenial`, `zesty` ou `artful`.
|
||||
|
||||
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
|
||||
simple de faire référence aux identifiants.
|
||||
|
||||
Chaque nom d'image possède au moins un tag associé : *latest*. C'est le tag qui
|
||||
est automatiquement recherché lorsque l'on ne le précisez pas en lançant
|
||||
l'image.
|
||||
Chaque nom d'image possède au moins un tag associé par défaut : *latest*. C'est
|
||||
le tag qui est automatiquement recherché lorsque l'on ne le précisez pas en
|
||||
lançant l'image.
|
||||
|
||||
|
||||
## Exécuter un programme dans un conteneur
|
||||
|
|
@ -65,7 +80,7 @@ lancer dans le conteneur ainsi que ses éventuels arguments. Essayons d'afficher
|
|||
un Hello World :
|
||||
|
||||
```
|
||||
docker run ubuntu /bin/echo "Hello World"
|
||||
docker container run ubuntu /bin/echo "Hello World"
|
||||
```
|
||||
|
||||
Dans notre exemple, c'est bien le `/bin/echo` présent dans le conteneur qui est
|
||||
|
|
@ -78,7 +93,7 @@ n'utilisez pas [Alpine Linux](https://www.alpine-linux.org), vous pourriez
|
|||
tenter d'utiliser son gestionnaire de paquet `apk`, via :
|
||||
|
||||
```
|
||||
docker run alpine /sbin/apk stats
|
||||
docker container run alpine /sbin/apk stats
|
||||
```
|
||||
|
||||
|
||||
|
|
@ -111,7 +126,7 @@ créer une nouvelle image à partir de ce conteneur.
|
|||
Pour créer une image, commençons par entrer dans un nouveau conteneur :
|
||||
|
||||
```
|
||||
docker run -it ubuntu /bin/bash
|
||||
docker container run -it ubuntu /bin/bash
|
||||
```
|
||||
|
||||
Vous avez remarqué l'utilisation des options `--tty` et `--interactive` ? Avant
|
||||
|
|
@ -120,13 +135,13 @@ 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 ...
|
||||
docker DOCKER_PARAMS container 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"
|
||||
docker -H unix:///var/run/docker.sock container run -it alpine /bin/ash -c "echo foo"
|
||||
```
|
||||
|
||||
Ici, l'option `-H` sera traitée par le client Docker (pour définir
|
||||
|
|
@ -136,11 +151,9 @@ 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,
|
||||
fermée (`close(2)`). 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 :
|
||||
|
||||
|
|
@ -155,11 +168,10 @@ sans quoi `bash` ne se lancera pas en mode interractif[^bashnointer].
|
|||
transmise au conteneur.
|
||||
|
||||
|
||||
### Modification interractive
|
||||
### Modification interactive
|
||||
|
||||
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` !
|
||||
Nous voilà maintenant dans le conteneur ! Il est assez épuré, il n'y a rien de
|
||||
superflu : même pas d'éditeur de texte : ni vim, ni emacs, même pas `vi` !
|
||||
|
||||
La première chose à faire est de télécharger la liste des paquets. En effet,
|
||||
afin de ne pas livrer de superflu, la liste des paquets et son cache ne sont
|
||||
|
|
@ -199,7 +211,7 @@ Sauvegardez votre image modifiée avec la commande `commit` pour pouvoir
|
|||
commencer directement de votre image avec `nano` :
|
||||
|
||||
```
|
||||
docker commit CONTAINER my_nano
|
||||
docker container commit CONTAINER my_nano
|
||||
```
|
||||
|
||||
En remplaçant `CONTAINER` par le nom ou l'identifiant de votre
|
||||
|
|
@ -207,7 +219,7 @@ container. `my_nano` est le nom que vous voudrez utiliser à la place
|
|||
d'`ubuntu` :
|
||||
|
||||
```
|
||||
docker run -it my_nano /bin/bash
|
||||
docker container run -it my_nano /bin/bash
|
||||
```
|
||||
|
||||
Vous constatez cette fois que vous pouvez lancer `nano`, alors que vous ne
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue