Spell
This commit is contained in:
parent
aaeb15334a
commit
7c93dc0e08
|
|
@ -7,7 +7,7 @@ Au fur et à mesure de nos tests, la taille utilisée par les données de Docker
|
|||
peut devenir conséquente et son interface peut commencer à déborder
|
||||
d'informations dépréciées.
|
||||
|
||||
Dans la mesure du possible, Docker essai de ne pas encombrer inutilement votre
|
||||
Dans la mesure du possible, Docker essaie de ne pas encombrer inutilement votre
|
||||
disque dur avec les vieilles images qui ne sont plus utilisées. Il ne va
|
||||
cependant jamais supprimer une image encore liée à un conteneur ; il ne
|
||||
supprimera pas non plus les conteneurs qui n'auront pas été démarrés avec
|
||||
|
|
@ -42,11 +42,10 @@ docker container rm cranky_jones dreamy_gates
|
|||
|
||||
## Images
|
||||
|
||||
Les vieilles images qui n'ont plus de références sur elles (ni tag, ni
|
||||
conteneur lié) sont automatiques supprimées. Vous n'avez généralement pas à
|
||||
vous occuper de faire du nettoyage dans les images. Néanmoins, vous pouvez les
|
||||
gérer de la même manière que les conteneurs, avec les sous-commandes `docker
|
||||
image`.
|
||||
Les vieilles images qui n'ont plus de références sur elle (ni tag, ni conteneur
|
||||
lié) sont automatiquement supprimées. Vous n'avez généralement pas à vous
|
||||
occuper de faire du nettoyage dans les images. Néanmoins, vous pouvez les gérer
|
||||
de la même manière que les conteneurs, avec les sous-commandes `docker image`.
|
||||
|
||||
|
||||
## `prune`
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ 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
|
||||
Store, en utilisant la commande `search` :
|
||||
*Store*, en utilisant la commande `search` :
|
||||
|
||||
```
|
||||
docker search mariadb
|
||||
|
|
@ -57,7 +57,7 @@ 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
|
||||
a un *TAG* différent. En effet, souvent, il existe plusieurs versions d'une même
|
||||
image. Pour Ubuntu par exemple, nous avons la possibilité de lancer la version
|
||||
`trusty`, `xenial`, `zesty` ou `artful`.
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ 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é par défaut : *latest*. C'est
|
||||
le tag qui est automatiquement recherché lorsque l'on ne le précisez pas en
|
||||
le tag qui est automatiquement recherché lorsque l'on ne le précise pas en
|
||||
lançant l'image.
|
||||
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ docker -H unix:///var/run/docker.sock container run -it alpine /bin/ash -c "echo
|
|||
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
|
||||
simplement transmis 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
|
||||
|
|
@ -166,3 +166,8 @@ sans quoi `bash` ne se lancera pas en mode interractif[^bashnointer].
|
|||
|
||||
L'option `-i` reste néanmoins nécessaire pour que l'entrée standard soit
|
||||
transmise au conteneur.
|
||||
|
||||
|
||||
### TODO
|
||||
|
||||
TODO Nouvelle partie sur `docker container ls`
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ Installation
|
|||
|
||||
## Prérequis
|
||||
|
||||
Docker repose sur plusieurs techniques implémentés dans les récents noyaux
|
||||
Linux. Nous consacrerons les prochains cours à comprendre leurs
|
||||
Docker repose sur plusieurs techniques implémentées dans les récents noyaux
|
||||
Linux. Nous consacrerons les prochains cours à comprendre leur
|
||||
fonctionnement. Ces techniques ne sont pas limitées à une architecture de
|
||||
microprocesseur spécifique (comme peuvent l'être les instructions de
|
||||
virtualisation nécessaire pour rendre les hyperviseurs attractifs) ; cependant
|
||||
|
|
@ -49,7 +49,7 @@ Historiquement, Docker est un projet open-source. Depuis peu, le business-model
|
|||
de la société a évolué et ils proposent désormais deux éditions : *Community
|
||||
Edition* et *Enterprise Edition*. La seconde est payante et possède un certain
|
||||
nombre d'atouts pour faciliter son adoption en entreprise (notamment pas mal
|
||||
d'interface graphique, etc.). Le cœur de la technologie est quant à lui
|
||||
d'interfaces graphiques, etc.). Le cœur de la technologie est quant à lui
|
||||
entièrement présent dans l'édition communautaire.
|
||||
|
||||
Depuis mars dernier, les numéros de version de Docker sont tirés de l'année et
|
||||
|
|
|
|||
|
|
@ -4,14 +4,14 @@ Lier les conteneurs
|
|||
===================
|
||||
|
||||
Partager des fichiers est une chose, mais ce n'est pas une manière d'échanger
|
||||
de l'information de manière instantanée : les sockets et le réseau restent
|
||||
plus adaptés à ce genre d'échanges.
|
||||
de l'information instantanément : les sockets et le réseau restent plus adaptés
|
||||
à ce genre d'échanges.
|
||||
|
||||
## Les pilotes réseau
|
||||
|
||||
Docker propose de base trois *drivers* pour « gérer » cela :
|
||||
Docker propose de base trois pilotes (*drivers*) pour « gérer » cela :
|
||||
|
||||
- `none` : pour limiter les interfaces réseaux du conteneur à l'interface de
|
||||
- `none` : pour limiter les interfaces réseau du conteneur à l'interface de
|
||||
loopback `lo` ;
|
||||
- `host` : pour partager la pile réseau avec l'hôte ;
|
||||
- `bridge` : pour créer une nouvelle pile réseau par conteneur et rejoindre un
|
||||
|
|
@ -19,7 +19,7 @@ Docker propose de base trois *drivers* pour « gérer » cela :
|
|||
|
||||
|
||||
Ces trois *drivers* sont instanciés de base dans Docker avec le même nom que
|
||||
leur pilote. Pour consulter la liste de réseaux utilisables, utilisez :
|
||||
leur pilote. Pour consulter la liste de réseaux utilisables, lancez :
|
||||
|
||||
```
|
||||
42sh$ docker network ls
|
||||
|
|
@ -29,10 +29,10 @@ d5d907add6e2 host host local
|
|||
16b702ed01a0 none null local
|
||||
```
|
||||
|
||||
Par défaut, c'est le réseau `bridge` (utilisant le pilote `bridge`) qui est
|
||||
utilisé : ce réseau utilise le pont `docker0` que vous pouvez voir dans vos
|
||||
interfaces réseaux via `ip link`. C'est via ce pont que les conteneurs peuvent
|
||||
avoir accès à Internet, au travers une couche de NAT.
|
||||
Par défaut, c'est le réseau `bridge` (de type `bridge`) qui est employé : ce
|
||||
réseau utilise le pont `docker0` que vous pouvez voir dans vos interfaces
|
||||
réseau via `ip link`. C'est via ce pont que les conteneurs peuvent avoir accès
|
||||
à Internet, au travers d'une couche de NAT.
|
||||
|
||||
Pour changer le réseau principal joint par le conteneur, utiliser l'option
|
||||
`--network` du `docker container run`.
|
||||
|
|
@ -49,7 +49,7 @@ directement accessible, sans avoir à utiliser l'option `-p` du `run`.
|
|||
|
||||
### Créer un nouveau réseau `bridge`
|
||||
|
||||
Afin de contrôler quels échanges peuvent être réaliser entre les conteneurs, il
|
||||
Afin de contrôler quels échanges peuvent être réalisé entre les conteneurs, il
|
||||
est recommandé de créer des réseaux utilisateur.
|
||||
|
||||
La création d'un réseau se fait tout simplement au travers des sous-commandes
|
||||
|
|
@ -67,7 +67,7 @@ réseau :
|
|||
docker network connect NETWORK CONTAINER
|
||||
```
|
||||
|
||||
Lorsque plusieurs conteneurs ont rejoint un réseau utilisateur, ils peuvent
|
||||
Lorsque plusieurs conteneurs ont rejoints un réseau utilisateur, ils peuvent
|
||||
mutuellement se découvrir grâce à un système de résolution de nom basé sur leur
|
||||
nom de conteneur.
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ moins le mot de passe à utiliser via la variable d'environnement
|
|||
`POSTGRES_PASSWORD`[^storepostgres] :
|
||||
|
||||
[^storepostgres]: l'ensemble des variables que peut prendre le conteneur est
|
||||
disponible sur la page dédié à l'image sur le store :
|
||||
disponible sur la page dédiée à l'image sur le *store* :
|
||||
<https://store.docker.com/images/postgres>
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -5,11 +5,11 @@ Projet et rendu
|
|||
|
||||
## Projet
|
||||
|
||||
Écrivez un script `mycloud-run.sh` pour automatiser le lancement de
|
||||
votre instance personnelle d'`owncloud`. Une attention particulière
|
||||
devra être apportée à la manière dont vous gérerez le rappel du script
|
||||
pour éventuellement relancer un conteneur qui se serait arrêté
|
||||
(évidemment sans perdre les données).
|
||||
Écrivez un script `mycloud-run.sh` pour automatiser le lancement de votre
|
||||
instance personnelle d'`owncloud`. Une attention particulière devra être
|
||||
apportée à la manière dont vous gérerez le rappel du script pour éventuellement
|
||||
relancer un conteneur qui se serait arrêté (évidemment sans perdre les
|
||||
données).
|
||||
|
||||
À la fin de son exécution, le script affichera un lien utilisable sur l'hôte
|
||||
pour se rendre sur la page de connexion. Une autre machine de votre réseau
|
||||
|
|
@ -22,7 +22,8 @@ machine sans pare-feu configurée, cela ne demande pas d'étape supplémentaire)
|
|||
Votre script devra se limiter aux notions vues durant ce TP (ie. sans utiliser
|
||||
`docker-compose` ou `docker stack` que l'on verra au prochain TP). Il pourra
|
||||
cependant faire usage des commandes `docker OBJECT inspect` pour ne pas avoir à
|
||||
parser les retours des commandes lisibles par les humains.
|
||||
faire d'analyse syntaxique sur les retours des commandes lisibles par les
|
||||
humains.
|
||||
|
||||
Cette instance devra utiliser une base de données MySQL (lancée par vos soins
|
||||
dans un autre conteneur) et contenir ses données dans un ou plusieurs volumes
|
||||
|
|
@ -71,7 +72,7 @@ Deux méthodes sont utilisables pour signer votre rendu :
|
|||
* signature de la tarball.
|
||||
|
||||
Dans les deux cas, si vous n'en avez pas déjà une, vous devrez créer une clef
|
||||
PGP à votre nom et prénom.
|
||||
PGP à **votre nom et prénom**.
|
||||
|
||||
Pour valider la signature, il est nécessaire d'avoir reçu la clef publique
|
||||
séparément. Vous avez le choix de l'uploader sur un serveur de clefs, soit de
|
||||
|
|
@ -103,7 +104,7 @@ gpg: Can't check signature: No public key
|
|||
```
|
||||
|
||||
C'est que votre clef publique n'est pas dans mon trousseau et que les méthodes
|
||||
de récupérations automatiques n'ont pas permis de la trouver. Uploadez votre
|
||||
de récupération automatique n'ont pas permis de la trouver. Uploadez votre
|
||||
clef sur un serveur de clefs (et attendez quelques minutes sa propagation) ou
|
||||
envoyez un courriel au service avec votre clef publique en pièce-jointe, avant
|
||||
de retenter votre rendu.
|
||||
|
|
@ -130,6 +131,6 @@ Si vous recevez un rapport concluant ainsi :
|
|||
After analyzing your e-mail, I've decided to SKIP it.
|
||||
```
|
||||
|
||||
Cela signifie que la lecture de votre courriel qui a été de préférée n'est pas
|
||||
Cela signifie que la lecture de votre courriel qui a été préférée n'est pas
|
||||
celle d'un rendu. Vérifiez que vous n'envoyez pas votre clef publique avec
|
||||
votre rendu.
|
||||
|
|
|
|||
|
|
@ -4,16 +4,15 @@ Stockage de données applicatives
|
|||
================================
|
||||
|
||||
Le concept principal de Docker est de concevoir des conteneurs applicatifs : on
|
||||
va préférer assigner un unique rôle à un conteneur (donc géralement on ne va
|
||||
va préférer assigner un unique rôle à un conteneur (donc généralement on ne va
|
||||
lancer qu'une seule application par conteneur) et concevoir un service complet
|
||||
en créant un groupe de conteneur, partageant des données entre-eux par des
|
||||
en créant un groupe de conteneurs, partageant des données entre eux par des
|
||||
volumes.
|
||||
|
||||
Il est possible d'utiliser la dernière couche en lecture/écriture pour inscrire
|
||||
des données. Il n'est cependant pas recommandé de stocker des données de cette
|
||||
manière, car les données ne vont pas persister une fois que le conteneur aura
|
||||
terminé son exécution ; elles seront alors plus compliqués à retrouver
|
||||
manuellement.
|
||||
manière, car elles ne vont pas persister une fois que le conteneur aura terminé
|
||||
son exécution ; elles seront alors plus compliquées à retrouver manuellement.
|
||||
|
||||
Docker met à notre disposition plusieurs mécanismes pour que les données de nos
|
||||
applications persistent et soient prêtes à migrer plus facilement vers une
|
||||
|
|
@ -50,10 +49,11 @@ volume :
|
|||
docker volume create prod_db
|
||||
```
|
||||
|
||||
Ensuite, nous pouvons démarrer un conteneur l'utilisant, par exemple :
|
||||
Ensuite, nous pouvons démarrer un conteneur utilisant, par exemple :
|
||||
|
||||
```
|
||||
docker container run --name mydb --mount source=prod_db,target=/var/lib/mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw mysql
|
||||
docker container run --name mydb --mount source=prod_db,target=/var/lib/mysql \
|
||||
-e MYSQL_ROOT_PASSWORD=my-secret-pw mysql
|
||||
```
|
||||
|
||||
Lorsque le volume est vide, si des données sont présentes à l'endroit du point
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ socket. D'ailleurs, le client peut ne pas être sur la même machine qui
|
|||
exécutera effectivement les conteneurs.
|
||||
|
||||
C'est ce qu'il se passe lorsqu'on utilise *Docker4Windows* ou *Docker4Mac* :
|
||||
une machine virtuelle Linux est lancé parallèlement au système de base et
|
||||
chaque commande `docker` tappée est passée au deamon dans la machine virtuelle.[^dockermachine]
|
||||
une machine virtuelle Linux est lancée parallèlement au système de base et
|
||||
chaque commande `docker` tapée est passée au deamon dans la machine virtuelle.[^dockermachine]
|
||||
|
||||
[^dockermachine]: Il suffit de modifier la variable d'environnement
|
||||
`DOCKER_HOST` ou de passer le paramètre `-H` suivi de l'URL de la socket à
|
||||
|
|
@ -40,8 +40,8 @@ Une image Docker est un système de fichiers en lecture seule. Elle est formée
|
|||
d'un ensemble de couches, agrégées selon le principe d'UnionFS.
|
||||
|
||||
Une image peut, par exemple, être un système Ubuntu complet ou juste contenir
|
||||
le programme busybox ou encore un serveur web et votre application web, prêt à
|
||||
l'emploi.
|
||||
le programme `busybox` ou encore un serveur web et votre application web, prêts
|
||||
à l'emploi.
|
||||
|
||||
Les images sont utilisées pour créer des conteneurs.
|
||||
|
||||
|
|
@ -54,12 +54,12 @@ les outils fournis, soit les récupérer depuis un registre.
|
|||
Alors que les images constituent la partie immuable de Docker, les conteneurs
|
||||
sont sa partie vivante. Chaque conteneur est créé à partir d'une image : à
|
||||
chaque fois que vous lancez un conteneur, une couche lecture/écriture est
|
||||
ajoutée au dessus de l'image. Cette couche est propre au conteneur et est
|
||||
temporaire : l'image n'est pas modifié par l'exécution d'un conteneur.
|
||||
ajoutée au dessus de l'image. Cette couche est propre au conteneur et
|
||||
temporaire : l'image n'est pas modifiée par l'exécution d'un conteneur.
|
||||
|
||||
Chaque conteneur s'exécute dans un environnement restreint et distinct de
|
||||
l'environnement principal (où vous avez votre bureau). Par exemple, dans cet
|
||||
environnement, vous ne pouvez pas voir les processus qui sont situé en dehors,
|
||||
environnement, vous ne pouvez pas voir les processus qui sont situés en dehors,
|
||||
ni accéder aux fichiers extérieurs.
|
||||
|
||||
|
||||
|
|
@ -71,4 +71,4 @@ d'en envoyer.
|
|||
|
||||
Le registre utilisé de base est le [Docker Store](https://store.docker.com/) :
|
||||
il contient à la fois des images officielles (ubuntu, debian, nginx, ...) et
|
||||
des images crées par des utilisateurs.
|
||||
des images créées par des utilisateurs.
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@ docker container run -it my_editor /bin/bash
|
|||
|
||||
## `RUN` dans le `Dockerfile`
|
||||
|
||||
Dans un `Dockerfile`, chaque ligne est exécutée indépendamment des
|
||||
autres et correspondra à une nouvelle couche de notre image.
|
||||
Dans un `Dockerfile`, chaque ligne est exécutée indépendamment des autres et
|
||||
correspondra à une nouvelle couche de notre image.
|
||||
|
||||
Cela signifie que l'exemple suivant **ne fonctionne pas** :
|
||||
|
||||
|
|
@ -54,9 +54,9 @@ RUN service mysqld start
|
|||
RUN mysql -u root -p toor virli < /db.sql
|
||||
```
|
||||
|
||||
Cet exemple ne fonctionne pas car le serveur MySQL est lancé dans le premier
|
||||
RUN, n'est plus lancé au moment du deuxième RUN. En effet, chaque commande du
|
||||
`Dockerfile` a pour but de modifier le système de fichiers.
|
||||
Cet exemple ne fonctionne pas car le serveur MySQL qui est lancé dans le
|
||||
premier `RUN`, n'est plus lancé au moment du deuxième `RUN`. En effet, chaque
|
||||
commande du `Dockerfile` a pour but de modifier le système de fichiers.
|
||||
|
||||
Pour avoir le résultat escompté, il faut exécuter les commandes ensemble :
|
||||
|
||||
|
|
@ -82,13 +82,12 @@ RUN apt-get install -y nginx
|
|||
EXPOSE 80
|
||||
```
|
||||
|
||||
L'instruction `EXPOSE` sera traité plus tard par le client Docker
|
||||
(équivalent à l'argument `--expose`). Il s'agit de préciser les ports
|
||||
sur lesquels votre image écoute.
|
||||
L'instruction `EXPOSE` sera traitée plus tard par le client Docker (équivalent
|
||||
à l'argument `--expose`). Il s'agit de préciser les ports sur lesquels votre
|
||||
image écoute.
|
||||
|
||||
En utilisant l'option `-P` du `run`, vous allez pouvoir assigner une
|
||||
redirection de port aléatoire sur la machine hôte vers votre
|
||||
conteneur :
|
||||
redirection de port aléatoire sur la machine hôte vers votre conteneur :
|
||||
|
||||
```
|
||||
docker image build --tag=my_webserver .
|
||||
|
|
@ -96,20 +95,19 @@ docker container run -it -P my_webserver /bin/bash
|
|||
service nginx start
|
||||
```
|
||||
|
||||
Dans un autre terminal, lancer un `docker ps` et consulter la colonne
|
||||
*PORTS* pour connaître le port choisit par Docker pour effectuer la
|
||||
redirection.
|
||||
Dans un autre terminal, lancer un `docker ps` et consulter la colonne *PORTS*
|
||||
pour connaître le port choisi par Docker pour effectuer la redirection.
|
||||
|
||||
Rendez-vous ensuite dans votre navigateur sur <http://localhost:49153/>.
|
||||
|
||||
À vous de jouer : utilisez l'instruction `COPY` pour afficher votre
|
||||
propre `index.html` remplaçant celui installé de base par nginx.
|
||||
*À vous de jouer :* utilisez l'instruction `COPY` pour afficher votre propre
|
||||
`index.html` remplaçant celui installé de base par nginx.
|
||||
|
||||
|
||||
## Lancement de commande automatique
|
||||
|
||||
Vous pouvez placer dans un `Dockerfile` une instruction `CMD` qui sera
|
||||
exécutée si aucune commande n'est passée lors du `run`, par exemple :
|
||||
Vous pouvez placer dans un `Dockerfile` une instruction `CMD` qui sera exécutée
|
||||
si aucune commande n'est passée lors du `run`, par exemple :
|
||||
|
||||
```
|
||||
CMD nginx -g "daemon off;"
|
||||
|
|
@ -120,23 +118,22 @@ docker image build --tag=my_nginx .
|
|||
docker container run -d -P my_nginx
|
||||
```
|
||||
|
||||
L'option `-d` passée au `run` lance le conteneur en tâche de
|
||||
fond. Si vous constatez via un `docker ps` que le conteneur s'arrête
|
||||
directement, retirer cette option pour voir ce qui ne va pas, ou
|
||||
utilisez la commande `docker logs`.
|
||||
L'option `-d` passée au `run` lance le conteneur en tâche de fond. Si vous
|
||||
constatez via un `docker container ls` que le conteneur s'arrête directement,
|
||||
retirez cette option pour voir ce qui ne va pas, ou utilisez la commande
|
||||
`docker container logs`.
|
||||
|
||||
|
||||
## D'autres instructions ?
|
||||
|
||||
Consultez <https://docs.docker.com/engine/reference/builder/> pour la liste complète
|
||||
des instructions reconnues.
|
||||
Consultez <https://docs.docker.com/engine/reference/builder/> pour la liste
|
||||
complète des instructions reconnues.
|
||||
|
||||
|
||||
## Rendu
|
||||
|
||||
Rendez le fichier `Dockerfile` et son contexte (`index.html`, fichiers de conf
|
||||
éventuels, ...) que vous avez utilisé pour réaliser votre image
|
||||
`my_webserver`.
|
||||
éventuels, ...) que vous avez utilisé pour réaliser votre image `my_webserver`.
|
||||
|
||||
Une attention particulière sera apporté au respect des différentes bonnes
|
||||
pratiques vues en cours pour l'écriture de `Dockerfile`.
|
||||
Une attention particulière sera apportée au respect des différentes bonnes
|
||||
pratiques vues en cours pour l'écriture du `Dockerfile`.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ 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
|
||||
pas inclues dans le conteneur.
|
||||
pas incluses dans le conteneur.
|
||||
|
||||
```
|
||||
apt-get update
|
||||
|
|
@ -16,7 +16,7 @@ apt-get update
|
|||
|
||||
Il peut arriver que des paquets présents dans l'image ne soient pas à
|
||||
jour. Afin de garder un environnement cohérent, il est recommandé de ne pas
|
||||
utiliser le gestionnaire de paquets pour mettre à jour les paquets présent de
|
||||
utiliser le gestionnaire de paquets pour mettre à jour les paquets présents de
|
||||
base, mais plutôt de contacter le mainteneur de l'image pour qu'il la mette à
|
||||
jour.
|
||||
|
||||
|
|
@ -34,8 +34,7 @@ docker container ls
|
|||
```
|
||||
|
||||
Cette commande liste les conteneurs actifs. Notez le *Container ID* ainsi que
|
||||
le *NAMES* du conteneur du conteneur actuellement en cours d'installation de
|
||||
`nano`.
|
||||
le *NAMES* du conteneur actuellement en cours d'installation de `nano`.
|
||||
|
||||
Lorsque l'installation de `nano` est terminée, quittez l'image en tapant
|
||||
`exit`.
|
||||
|
|
@ -47,7 +46,7 @@ commencer directement de votre image avec `nano` :
|
|||
docker container commit CONTAINER my_nano
|
||||
```
|
||||
|
||||
En remplaçant `CONTAINER` par le nom ou l'identifiant de votre
|
||||
en remplaçant `CONTAINER` par le nom ou l'identifiant de votre
|
||||
container. `my_nano` est le nom que vous voudrez utiliser à la place
|
||||
d'`ubuntu` :
|
||||
|
||||
|
|
@ -56,4 +55,4 @@ docker container run -it my_nano /bin/bash
|
|||
```
|
||||
|
||||
Vous constatez cette fois que vous pouvez lancer `nano`, alors que vous ne
|
||||
pouvez toujours pas le faire dans un conteneur issue d'une image `ubuntu` !
|
||||
pouvez toujours pas le faire dans un conteneur issu d'une image `ubuntu` !
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user