tuto 1: done
This commit is contained in:
parent
7a1d5d9981
commit
13bd205b1b
@ -135,5 +135,8 @@ des instructions reconnues.
|
||||
## Rendu
|
||||
|
||||
Rendez le fichier `Dockerfile` et son contexte (`index.html`, fichiers de conf
|
||||
éventuels, ...) que vous avez utiliser pour réaliser votre image
|
||||
é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`.
|
||||
|
@ -103,7 +103,7 @@ docker container run alpine /sbin/apk stats
|
||||
|
||||
À 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
|
||||
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
|
||||
@ -111,7 +111,7 @@ 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")
|
||||
![Images vs. conteneurs](img-vs-cntr.png "Images vs. conteneurs"){ width=85% }
|
||||
|
||||
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.
|
||||
@ -197,7 +197,7 @@ En attendant la fin de l'installation, jetons un œil à la commande dans un
|
||||
autre terminal :
|
||||
|
||||
```
|
||||
docker ps
|
||||
docker container ls
|
||||
```
|
||||
|
||||
Cette commande liste les conteneurs actifs. Notez le *Container ID* ainsi que
|
||||
|
BIN
tutorial/1/img-vs-cntr.png
Normal file
BIN
tutorial/1/img-vs-cntr.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 247 KiB |
@ -3,7 +3,122 @@
|
||||
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.
|
||||
|
||||
## Les pilotes réseau
|
||||
|
||||
Docker propose de base trois *drivers* pour « gérer » cela :
|
||||
|
||||
- `none` : pour limiter les interfaces réseaux 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
|
||||
pont réseau dédié.
|
||||
|
||||
|
||||
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 :
|
||||
|
||||
## Le pont `docker0`
|
||||
```
|
||||
42sh$ docker network ls
|
||||
NETWORK ID NAME DRIVER SCOPE
|
||||
74cedd3ff385 bridge bridge local
|
||||
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.
|
||||
|
||||
Pour changer le réseau principal joint par le conteneur, utiliser l'option
|
||||
`--network` du `docker container run`.
|
||||
|
||||
|
||||
### Le réseau `host`
|
||||
|
||||
En utilisant ce réseau, vous abandonnez tout isolation sur cette partie du
|
||||
conteneur et partagez donc avec l'hôte toute sa pile IP. Cela signifie, entre
|
||||
autre, que les ports que vous chercherez à allouer dans le conteneur devront
|
||||
être disponibles dans la pile de l'hôte et également que tout port allouer sera
|
||||
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
|
||||
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
|
||||
relatives aux objets Docker `network` :
|
||||
|
||||
```
|
||||
docker network create --driver bridge my_network
|
||||
```
|
||||
|
||||
C'est ensuite ce nom de réseau que vous passerez à l'option `--network` de vos
|
||||
`run`, ou vous pouvez également faire rejoindre un conteneur déjà lancé à un
|
||||
réseau :
|
||||
|
||||
```
|
||||
docker network connect NETWORK CONTAINER
|
||||
```
|
||||
|
||||
Lorsque plusieurs conteneurs ont rejoint 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.
|
||||
|
||||
|
||||
### Exercice
|
||||
|
||||
Lancez votre serveur web avec :
|
||||
|
||||
```
|
||||
docker container run --name helloapp -d my_webserver
|
||||
```
|
||||
|
||||
Puis créez un réseau utilisateur, rejoignez-le et lancez un conteneur dans le
|
||||
même réseau utilisateur. Vous devriez être capable de lancer dans ce conteneur
|
||||
les commandes :
|
||||
|
||||
```
|
||||
ping helloapp
|
||||
curl http://helloapp/
|
||||
```
|
||||
|
||||
|
||||
## Liaison à l'ancienne
|
||||
|
||||
Les réseaux utilisateurs sont la manière à privilégier lorsque l'on souhaite
|
||||
que deux conteneurs puissent discuter entre-eux.
|
||||
|
||||
Avant que cela n'existe, une fonctionnalité de liaison existait. Moins
|
||||
puissante que les réseaux et plus contraignante car elle nécessite de gérer
|
||||
l'ordre dans lequel les conteneurs sont lancés, elle permet néanmoins de
|
||||
partager en plus les variables d'environnements du conteneur lié.
|
||||
|
||||
Par exemple, pour lancer un conteneur `postgresql`, il faut lui préciser au
|
||||
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 :
|
||||
<https://store.docker.com/images/postgres>
|
||||
|
||||
```
|
||||
docker container run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
|
||||
```
|
||||
|
||||
Le lien permet de fournir à n'importe quel autre conteneur les mêmes variables
|
||||
d'environnement. Cela évite d'avoir à recopier le mot de passe pour lancer un
|
||||
conteneur qui en dépendrait. Comme par exemple dans le cas d'un serveur web qui
|
||||
doit se connecter à une base de données : l'application doit être configurée
|
||||
pour utiliser le mot de passe défini au lancement du conteneur de base de
|
||||
données :
|
||||
|
||||
```
|
||||
docker run -it --rm --link some-postgres:postgres postgres psql -h postgres -U postgres
|
||||
```
|
||||
|
@ -3,25 +3,34 @@
|
||||
Projet et rendu
|
||||
===============
|
||||
|
||||
## Sujet
|
||||
## Projet
|
||||
|
||||
Écrivez un `Dockerfile` pour conteneriser un client netsoul.
|
||||
É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).
|
||||
|
||||
Vous pouvez utiliser le client de votre choix, comme par exemple
|
||||
[tumsoul.py](https://virli.nemunai.re/misc/tumsoul_0.3.3.py).
|
||||
À 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
|
||||
local devrait également pouvoir accéder à la plate-forme, simplement en
|
||||
renseignant l'IP de votre machine et en ajoutant éventuellement des règles de
|
||||
pare-feu (mais cette dernière partie n'est pas demandée, gardez simplement en
|
||||
tête que cela doit pouvoir être fait manuellement au cas par cas : sur une
|
||||
machine sans pare-feu configurée, cela ne demande pas d'étape supplémentaire).
|
||||
|
||||
Une fois construit, le conteneur doit se lancer comme cela :
|
||||
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.
|
||||
|
||||
```
|
||||
docker run -e NETSOUL_LOGIN="login_x" -e PASSSOCKS="xnigol42" netsoul
|
||||
```
|
||||
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
|
||||
(afin qu'elles persistent à une mise à jour des conteneurs par exemple).
|
||||
|
||||
Passer la configuration d'un conteneur dans des variables d'environnement est
|
||||
une méthode couramment utilisée. Ces variables sont récupérées et traitées par
|
||||
le script
|
||||
d'[ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#/entrypoint). Ce
|
||||
qui permet de n'utiliser la ligne de commande que pour des indiquer le
|
||||
programme à lancer et ses arguments.
|
||||
L'exécution doit être la plus sécurisée possible (pas de port MySQL exposé sur
|
||||
l'hôte par exemple, etc.) et la plus respectueuse des bonnes pratiques que l'on
|
||||
a pu voir durant ce premier cours.
|
||||
|
||||
|
||||
## Modalité de rendu
|
||||
@ -50,11 +59,8 @@ Voici une arborescence type:
|
||||
login_x-TP1/webserver
|
||||
login_x-TP1/webserver/Dockerfile
|
||||
login_x-TP1/webserver/index.html
|
||||
login_x-TP1/webserver/datavolume-run.sh
|
||||
login_x-TP1/netsoul
|
||||
login_x-TP1/netsoul/Dockerfile
|
||||
login_x-TP1/netsoul/docker-entrypoint.sh
|
||||
login_x-TP1/netsoul/tumsoul.py
|
||||
login_x-TP1/mycloud
|
||||
login_x-TP1/mycloud/mycloud-run.sh
|
||||
```
|
||||
|
||||
## Signature du rendu
|
||||
|
@ -13,11 +13,10 @@ Tous les éléments de ce TP (exercices et projet) sont à rendre à
|
||||
dernière section de chaque partie pour plus d'information sur les éléments à
|
||||
rendre.
|
||||
|
||||
En tant que personnes sensibilisées à la sécurité des échanges
|
||||
électroniques, vous devrez m'envoyer vos rendus signés avec votre clef
|
||||
PGP. Pensez à
|
||||
[me](http://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96)
|
||||
faire signer votre clef et n'hésitez pas à
|
||||
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](http://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96) faire
|
||||
signer votre clef et n'hésitez pas à
|
||||
[faire signer la votre](http://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
|
||||
\hypersetup{linkcolor=black}
|
||||
|
Loading…
Reference in New Issue
Block a user