tuto 1: done

tutorial/1/dockerfile.md

@@ -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`.

tutorial/1/first.md

@@ -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

tutorial/1/linking.md

@@ -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
+```

tutorial/1/rendu.md

@@ -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

tutorial/1/tutorial.md

@@ -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}