Présentations

• Bonjour, je suis:

  • 👨🏾‍🎓 djalal

• Cet atelier se déroulera de 9h à 17h.

• La pause déjeuner se fera entre 12h et 13h30.

  (avec 2 pauses café à 10h30 et 15h!)

• N'hésitez pas à m'interrompre pour vos questions, à n'importe quel moment.

• Surtout quand vous verrez des photos de conteneurs en plein écran!

logistics.md

Une brève introduction

• Ce cours a été écrit à l'origine comme support à des ateliers en présentiel

• Ce contenu est maintenu par Jérôme Petazzoni et de nombreux contributeurs

• La traduction intégrale depuis l'anglais est réalisée et maintenue par @djalal

• Vous pouvez aussi le parcourir à votre propre rythme.

• Nous avons inclus autant d'information que possible dans les diapositives.

• Nous vous recommandons d'avoir un instructeur pour vous aider...

• ... sauf si vous êtes à l'aise avec la lecture minutieuse de la documentation Docker...

• ... et avec la recherche de réponses dans les forums Docker, StackOverflow, et autres boutiques.

containers/intro.md

À propos de ces diapositives

• Tout le contenu est disponible dans un dépôt public Github:

  https://github.com/jpetazzo/container.training

• Vous pouvez obtenir une version à jour de ces diapos ici:

  https://container.training/ (anglais) ou https://docker.djal.al/ (français)

Chapitre 1

• Docker vu d'hélicoptère

• Histoire des conteneurs ... et de Docker

• Notre environnement de formation

• Nos premiers conteneurs

• Conteneurs en tâche de fond

(auto-generated TOC)

Chapitre 2

• Comprendre les images Docker

• Construire des images Docker avec un Dockerfile

• CMD et ENTRYPOINT

• Copier des fichiers pendant le build

(auto-generated TOC)

Chapitre 3

• Réduire la taille de l'image

• Builds multi-stage

• Publier des images sur le Docker Hub

• Astuces pour Dockerfiles efficaces

• Exemples de Dockerfile

• Dockerfiles avancés

(auto-generated TOC)

Chapitre 4

• Bases du réseau pour conteneur

• Pilote réseau pour conteneur

• Le Container Network Model

• Service discovery avec les containers

(auto-generated TOC)

Chapitre 5

• Processus de développement local avec Docker

• Travailler avec des volumes

• Compose pour les développeurs

(auto-generated TOC)

Chapitre 6

• Configuration d'applications

• Stockage des secrets

• Gestion des logs

• Limiter les ressources

• Notre application de démo

• Identifier les goulots d'étranglement

• SwarmKit

• Déclaratif vs Impératif

• Mode Swarm

• Créer notre premier Swarm

(auto-generated TOC)

Chapitre 7

• Lancer notre premier service Swarm

• Notre appli sur Swarm

• Héberger notre propre Registry

• Les Stacks Swarm

• CI/CD avec Docker et l'orchestration

• Mettre à jour les services

• Mises à jour progressive

• Healthcheck et rollback automatique

(auto-generated TOC)

Chapitre 8

• Gestion des secrets et chiffrement au repos

• Modèle du moindre privilège

• Logs centralisés

• Installer ELK pour stocker les logs de conteneur

• Collecter les métriques

• Liens et ressources

(auto-generated TOC)

shared/toc.md

Docker vu d'hélicoptère

Dans cette leçon, nous apprendrons:

• Pourquoi les conteneurs (pitch d'ascenseur non-technique)

• Pourquoi les conteneurs (version technique du pitch d'ascenseur)

• Comment Docker nous aide à les construire, transporter et lancer

• L'Histoire des conteneurs

On ne va pas (encore!) lancer Docker ou des conteneurs dans ce chapitre.

Pas de souci, nous y arriverons assez tôt!

containers/Docker_Overview.md

Pitch d'ascenseur

(pour votre manager, votre patron...)

containers/Docker_Overview.md

OK... Pourquoi ce buzz autour des conteneurs?

• L'industrie logicielle a changé

• Avant:

  • applications monolithiques
  • longs cycles de développements
  • environnement unique
  • montée en charge lente

• Maintenant:

  • services découplés
  • améliorations rapides, itératives
  • environnements multiples
  • montée en charge rapide

containers/Docker_Overview.md

Déployer devient très compliqué

• Nombreuses technos différentes:

  • langages
  • frameworks
  • bases de données

• Nombreux environnements différents:

  • espaces de développement individuels
  • pre-production, QA, staging...
  • production: on-prem, cloud, hybride

containers/Docker_Overview.md

Résultats

• Passage "Dev à Prod" réduit de 9 mois à 15 minutes (ING)

• Durée des traitements d'intégration continue réduite de 60% (BBC)

• Déployer 100 fois par jour au lieu d'une fois par semaine (GILT)

• 70% de consolidation d'infrastructure (MetLife)

• 60% de consolidation d'infrastructure (Intesa Sanpaolo)

• Densité d'application 14x supérieure; 60% du datacenter legacy migré en 4 mois (GE Appliances)

• etc.

containers/Docker_Overview.md

Pitch d'ascenseur

(pour vos collègues développeurs et admin. système)

containers/Docker_Overview.md

Echapper à l'enfer des dépendances

1. Ecrire les instructions d'installation dans un fichier INSTALL.txt

2. Avec ce fichier, écrire un script install.sh qui va marcher pour vous

3. Traduire ce fichier en Dockerfile, le tester sur votre machine

4. Si le Dockerfile passe sur votre machine, il passera n'importe où

5. Réjouissez-vous, car vous êtes sauvé de l'enfer des dépendances et du "ça marche sur ma machine"

Plus jamais de "ça marchait en dev - c'est le problème des admins maintenant!"

containers/Docker_Overview.md

Intégrez des développeurs et contributeurs rapidement

1. Ecrire les Dockerfiles pour les composants applicatifs

2. Utiliser des images pré-générées du Docker Hub (mysql, redis, etc.)

3. Décrire votre suite logicielle avec un fichier Compose

4. Intégrer quelqu'un avec deux commandes:

git clone ...
docker-compose up

Avec ça, vous pouvez monter des environnements de développement, intégration ou QA en quelques minutes!

containers/Docker_Overview.md

Histoire des conteneurs ... et de Docker

containers/Docker_History.md

Premières expérimentations

• IBM VM/370 (1972)

• Linux VServers (2001)

• Solaris Containers (2004)

• FreeBSD jails (1999-2000)

Cela fait très longtemps que les conteneurs existent.

(Voir cet excellent billet par Serge Hallyn pour plus de détails historiques.)

containers/Docker_History.md

Conteneurs = moins cher que les VMs

• Utilisateurs: fournisseurs d'hébergement.

• Audience hautement spécialisée avec une forte culture d'admin. système.

containers/Docker_History.md

Conteneurs = plus facile que les VMs

• Je ne peux pas parler pour Heroku, mais les conteneurs étaient l'arme secrète de dotCloud (parmi d'autres).

• dotCloud maintenait un PaaS, via un moteur de conteneur personnalisé.

• Ce moteur était basé sur OpenVZ (et plus tard, LXC) et AUFS.

• Tout a commencé (vers 2008) par un simple script Python.

• En 2012, le moteur comptait plusieurs composants Python (env. 10)
  (et env. 100 micro-services!)

• Fin 2012, dotCloud reconstruit le moteur de conteneur.

• Le nom de code de ce projet est "Docker".

containers/Docker_History.md

Première version publique de Docker

• Mars 2013, Pycon, Santa Clara:
  "Docker" est montré en public pour la première fois.

• Il est publié avec une licence open source.

• Réactions et retours très positifs!

• L'équipe dotCloud est progressivement réaffectée au développement de Docker.

• La même année, dotCloud change de nom pour s'appeler Docker.

• En 2014, l'activité PaaS est revendue.

containers/Docker_History.md

Docker premiers jours (2013-2014)

containers/Docker_History.md

Premiers utilisateurs de Docker

• Gestionnaires de PAAS (Flynn, Dokku, Tsuru, Deis...)

• Utilisateurs de PAAS (ceux assez gros pour justifier la construction de leur propre PAAS)

• Services d'intégration continue

• développeurs, développeurs, développeurs

containers/Docker_History.md

Boucle de retours positifs

• En 2013, la technologie sous-tenant les conteneurs (cgroups, namespaces, stockage copy-on-write, etc.)

• La popularité croissante de Docker et des conteneurs a mis en lumière de nombreux bugs.

• En conséquence, ces bugs sont corrigés, résultant dans une meilleure stabilité des conteneurs.

• Aujourd'hui, tout fournisseur d'hébergement/cloud un peu sérieux peut lancer des conteneurs.

• Les conteneurs sont devenus un super outil pour déployer/transporter des applis vers/depuis les environnements on-prem/cloud.

containers/Docker_History.md

Maturité (2015-2016)

containers/Docker_History.md

Docker devient un standard d'industrie

• Docker atteint le jalon symbolique du 1.0

• Docker est maintenant supporté par les systèmes existants comme Mesos ou Cloud Foundry.

• Standardisation autour de l'OCI (Open Containers Initiative).

• De nouveaux moteurs de conteneurs sont développés.

• Création de la CNCF (Cloud Native Computing Foundation).

containers/Docker_History.md

Docker devient une plate-forme

• Le moteur de conteneur initial est maintenant nommé "Docker Engine".

• D'autres outils y sont ajoutés:

  • Docker Compose (anciennement "Fig")
  • Docker Machine
  • Docker Swarm
  • Kitematic
  • Docker Cloud (anciennement "Tutum")
  • Docker Datacenter
  • etc.

• Docker Inc. lance ses offres commerciales.

containers/Docker_History.md

Notre environnement de formation

• Si vous assistez à un atelier ou un tutoriel:

  • une VM a été provisionnée pour chaque apprenant

• Si vous suivez ou révisez ce cours tout seul, vous pouvez:

  • installer Docker en local (comme expliqué dans le chapitre "Installer Docker")

  • installer Docker sur une VM dans le cloud (par ex.)

  • utiliser https://www.play-with-docker.com/ pour lancer en un instant un environnement de formation

containers/Training_Environment.md

Notre VM Docker

Cette section suppose que vous suivez ce cours dans le cadre d'un tutoriel, une atelier ou une formation, où chaque apprenant reçoit une VM Docker individuelle.

• La VM est créée juste avant la formation.

• Elle restera allumée pendant toute la durée de la formation.

• Elle sera détruite peu de temps après la formation.

• Elle est fournie avec Docker et quelques autres outils utiles.

containers/Training_Environment.md

C'est quoi Docker?

• "Installer Docker" signifie en vrai "Installer le Docker Engine et le client en ligne de commande".

• Le Docker Engine est un daemon (un service tournant en tâche de fond).

• Ce daemon gère les conteneurs, à la manière d'un hyperviseur qui gère ses VMs.

• Nous dialoguons avec le Docker Engine par la Docker CLI (ligne de commande).

• Docker CLI et Docker Engine communiquent via une API.

• Il existe de nombreux autres programmes, et de composants client, pour exploiter cette API.

containers/Training_Environment.md

Pourquoi on ne lance pas Docker en local?

• On va télécharger des images de conteneur et des paquets de distribution.

• Cela pourrait quelque peu stresser la connexion WiFi locale, et nous ralentir.

• Au lieu de ça, on préfère passer par une VM distante qui a une meilleure connectivité.

• Dans de rares cas, installer Docker en local peut s'avérer tortueux:

  • pas d'accès au compte admin/root (poste géré par une DSI stricte)

  • CPU ou système d'exploitation 32 bits.

  • vieille version de l'OS (par ex. CentOS 6, OSX pré-Yosemite, Windows 7)

• Il est meilleur de passer du temps à apprendre les conteneurs qu'à trifouiller l'installateur!

containers/Training_Environment.md

Se connecter à votre Machine Virtuelle

Vous avez besoin d'un client SSH.

• Sur OS X, Linux et autres systèmes UNIX, ssh suffit:

$ ssh <login>@<ip-address>

• Sur Windows, si vous n'avez pas de client SSH, vous pouvez télécharger:

  • Putty (www.putty.org)

  • Git BASH (https://git-for-windows.github.io/)

  • MobaXterm (https://mobaxterm.mobatek.net/)

containers/Training_Environment.md

Vérifier votre Machine Virtuelle

Une fois connecté(e), assurez-vous que la commande Docker de base fonctionne:

$ docker version
Client:
 Version:       18.03.0-ce
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    0520e24
 Built:         Wed Mar 21 23:10:06 2018
 OS/Arch:       linux/amd64
 Experimental:  false
 Orchestrator:  swarm
Server:
 Engine:
  Version:      18.03.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   0520e24
  Built:        Wed Mar 21 23:08:35 2018
  OS/Arch:      linux/amd64
  Experimental: false

Si ça ne marche pas, levez la main et on viendra vous aider!

containers/Training_Environment.md

Objectifs

À la fin de cette leçon, vous aurez:

• vu Docker en action;

• démarré vos premiers conteneurs.

containers/First_Containers.md

Hello World

Depuis votre environnement Docker, lancez juste la commande suivante:

$ docker run busybox echo hello world
hello world

(Si votre installation Docker est vierge, quelques lignes en plus s'afficheront, correspondant au téléchargement de l'image busybox.)

containers/First_Containers.md

C'était notre premier conteneur!

• Nous avons utilisé l'une des images les plus petites et simples: busybox.

• busybox est typiquement utilisée dans les systèmes embarqués (téléphones, routeurs, etc.)

• Nous avons lancé un seul processus pour afficher hello world.

containers/First_Containers.md

Un conteneur plus utile

Lançons un conteneur un peu plus excitant:

$ docker run -it ubuntu
root@04c0bb0a6c07:/#

• C'est un conteneur tout neuf.

• Il exécute un système ubuntu basique et sans fioritures.

• -it est le raccourci pour -i -t.

  • -i dit à Docker de nous connecter à l'entrée du conteneur.

  • -t dit à Docker que nous voulons un pseudo-terminal.

containers/First_Containers.md

Faire quelque chose dans notre conteneur

Essayez de lancer figlet dans notre conteneur.

root@04c0bb0a6c07:/# figlet hello
bash: figlet: command not found

D'accord, donc nous allons devoir l'installer.

containers/First_Containers.md

Installer un paquet dans notre conteneur

Nous voulons figlet, alors installons-le:

root@04c0bb0a6c07:/# apt-get update
...
Fetched 1514 kB in 14s (103 kB/s)
Reading package lists... Done
root@04c0bb0a6c07:/# apt-get install figlet
Reading package lists... Done
...

Une minute plus tard, figlet est installé!

containers/First_Containers.md

Essayons de lancer notre programme fraichement installé

Le programme figlet prend un message en paramètre.

root@04c0bb0a6c07:/# figlet hello
 _          _ _       
| |__   ___| | | ___  
| '_ \ / _ \ | |/ _ \ 
| | | |  __/ | | (_) |
|_| |_|\___|_|_|\___/

Magnifique! 😍

containers/First_Containers.md

Hôte et conteneurs sont deux systèmes indépendants

• Nous avons lancé un conteneur ubuntu sur un hôte Linux/Windows/macOS.

• Ils possèdent des paquets indépendants et différents.

• Installer quelque chose sur l'hôte ne l'expose pas dans le conteneur.

• Et vice-versa.

• Même si l'hôte et le conteneur ont tous deux la même distribution Linux.

• Nous pouvons lancer n'importe quel conteneur sur n'importe quel hôte.

  (Une exception: les conteneurs Windows ne peuvent tourner sur les machines Linux; par encore en tout cas.)

containers/First_Containers.md

Où est notre conteneur?

• Notre conteneur est maintenant en état stopped.

• Il existe encore sur le disque, mais toutes ses ressources ont été libérées.

• Nous verrons plus tard comment récupérer ce conteneur.

containers/First_Containers.md

Démarrer un autre conteneur

Et si nous démarrions un nouveau conteneur, pour y lancer à nouveau figlet?

$ docker run -it ubuntu
root@b13c164401fb:/# figlet
bash: figlet: command not found

• Nous avons lancé un tout nouveau conteneur.

• Dans l'image de base Ubuntu utilisée ci-dessus, figlet est absent.

containers/First_Containers.md

Où est mon conteneur?

• Pouvons nous réutiliser ce conteneur que nous avons pris le soin de personnaliser?

  On pourrait, mais ce n'est pas le mode de production par défaut avec Docker.

• Quel est le processus général, alos?

  Toujours démarrer avec un conteneur tout nouveau.
  Si on a besoin d'installer quoique ce soit dans notre conteneur, générer une nouvelle image.

• Ça a l'air compliqué!

  Nous allons voir que c'est en fait assez simple!

• Et tout ça pour quoi?

  Tout ça pour appuyer sur l'automatisation et la répétabilité. Voyons voir pourquoi ...

containers/First_Containers.md

Animaux de compagnie et bétail

• Dans la métaphore "pets vs cattle", il existe deux genres de serveurs.

• Les animaux de compagnie (Pets):

  • ont un petit nom et une configuration unique

  • quand ils défaillent, on fait tout ce qu'on peut pour les soigner.

• Le bétail (Cattle):

  • ont des noms génériques (par ex. contenant des numéros) et une configuration générique

  • leur configuration est générée par une couche de gestion de configuration, et des templates ...

  • quand une panne advient, on peut les remplacer immédiatement par un nouveau serveur

• Quelle est la relation avec Docker et les conteneurs?

containers/First_Containers.md

Environnement de développement locaux

• Avec l'usage de VMs locales (comme par ex. Virtualbox ou VMware), notre flux de travail ressemble à ce qui suit:

  • créer une VM à partir d'un gabarit de base (Ubuntu, CentOS...)

  • installer les paquets, configurer l'environnement

  • travail sur le projet en tant que tel

  • finalement, éteindre la VM

  • la prochaine fois qu'on aborde ce projet, redémarrer la VM dans l'état où on l'a laissée

  • si on a besoin de retoucher l'environnement, on le fait en direct.

• Au fil du temps, la configuration de la VM évolue et diverge.

• Il nous manque une procédure propre, fiable et déterministe de provisionner cet environnement.

containers/First_Containers.md

Développement local avec Docker

• Avec Docker, la démarche est la suivante:

  • créer une image de conteneur représentant notre environnement de dév.

  • lancer un conteneur basé sur cette image

  • travailler sur notre projet proprement dit

  • finalement, stopper le conteneur

  • la prochaine fois qu'on aborde le projet, démarrer un nouveau contneeur

  • en cas de changement de l'environnement, on créé une nouvelle image.

• Nous avons une définition claire de notre environnement, qu'on peut partager de manière fiable avec les autres.

• Nous verrons dans les chapitres suivants comment préparer une image personnalisée avec figlet.

containers/First_Containers.md

Objectifs

Nos premiers conteneurs étaient interactifs.

Nous allons maintenant voir comment:

• Lancer un conteneur non-interactif
• Lancer un conteneur en tâche de fond.
• Lister les conteneurs en cours d'exécution.
• Vérifier les logs d'un conteneur.
• Arrêter un conteneur.
• Lister les conteneurs à l'arrêt.

containers/Background_Containers.md

Un conteneur non-interactif

Nous allons lancer un petit conteneur spécial.

Ce conteneur ne fait qu'afficher l'heure à chaque seconde.

$ docker run jpetazzo/clock
Fri Feb 20 00:28:53 UTC 2015
Fri Feb 20 00:28:54 UTC 2015
Fri Feb 20 00:28:55 UTC 2015
...

• Ce conteneur va tourner indéfiniment.
• Pour l'arrêter, appuyer sur ^C.
• Docker a automatiquement téléchargé l'image jpetazzo/clock.
• Cette image est une image utilisateur, créée par jpetazzo.
• Nous en apprendrons plus sur les images utilisateur (et autres types d'images) plus tard.

containers/Background_Containers.md

Lancer un conteneur en tâche de fond

Les conteneurs peuvent être démarrés en tâche de fond, avec l'option -d (mode daemon)

$ docker run -d jpetazzo/clock
47d677dcfba4277c6cc68fcaa51f932b544cab1a187c853b7d0caf4e8debe5ad

• Nous ne voyons pas l'affichage du conteneur.
• Mais pas de souci: Docker collecte tout affichage et l'écrit dans un log!
• Docker nous retourne un identifiant (ID) du conteneur.

containers/Background_Containers.md

Lister les conteneurs en cours d'exécution

Comment vérifier que notre conteneur est encore lancé?

Avec docker ps, tout comme la commande ps d'UNIX, qui liste les processus qui tournent.

$ docker ps
CONTAINER ID  IMAGE           ...  CREATED        STATUS        ...
47d677dcfba4  jpetazzo/clock  ...  2 minutes ago  Up 2 minutes  ...

Docker nous indique:

• l'ID (tronqué) de notre conteneur;
• l'image utilisée pour démarrer le conteneur;
• que notre conteneur est lancé (Up) depuis quelques minutes;
• d'autres informations (COMMAND, PORTS, NAME) que nous verrons plus tard.

containers/Background_Containers.md

Lancer plus de conteneurs

Démarrons deux autres conteneurs.

$ docker run -d jpetazzo/clock
57ad9bdfc06bb4407c47220cf59ce21585dce9a1298d7a67488359aeaea8ae2a

$ docker run -d jpetazzo/clock
068cc994ffd0190bbe025ba74e4c0771a5d8f14734af772ddee8dc1aaf20567d

Vérifiez que docker ps mentionne correctement tous les 3 conteneurs.

containers/Background_Containers.md

Afficher uniquement le dernier conteneur démarré

Quand de nombreux conteneurs tournent déjà, il peut être utile de limiter l'affichage au dernier conteneur démarré.

C'est à ça que sert l'option -l ("Last"):

$ docker ps -l
CONTAINER ID  IMAGE           ...  CREATED        STATUS        ...
068cc994ffd0  jpetazzo/clock  ...  2 minutes ago  Up 2 minutes  ...

containers/Background_Containers.md

Voir uniquement les IDs des conteneurs

Plusieurs commandes Docker sont basées sur des IDs de conteneurs: docker stop, docker rm, etc.

Si nous voulons lister uniquement les IDs de nos conteneurs (sans les autres colonnes ni en-tête), nous pouvons utiliser l'option -q ("Quiet", "Quick"):

$ docker ps -q
068cc994ffd0
57ad9bdfc06b
47d677dcfba4

containers/Background_Containers.md

Combinaison d'options

Nous pouvons combiner -l et -q pour uniquement voir l'ID du dernier conteneur démarré:

$ docker ps -lq
068cc994ffd0

A première vue, cela parait vraiment utile dans le cadre de scripts.

Toutefois, si nous voulons démarrer un conteneur et récupérer son ID de manière sécurisée, il est plus conseillé d'utiliser docker run -d, ce que nous aborderons dans un instant.

(Using docker ps -lq is prone to race conditions: what happens if someone else, or another program or script, starts another container just before we run docker ps -lq?)

containers/Background_Containers.md

Voir les logs d'un conteneur

On vous a dit que Docker enregistrait l'affichage d'un conteneur.

C'est le moment d'en parler.

$ docker logs 068
Fri Feb 20 00:39:52 UTC 2015
Fri Feb 20 00:39:53 UTC 2015
...

• Nous avons spécifié un préfixe de l'ID d'un conteneur.
• On peut, bien sûr, utiliser l'ID complet.
• La commande logs va afficher les logs complets du conteneur.
  (Parfois, c'est bien trop. Voyons comment gérer ça.)

containers/Background_Containers.md

Afficher uniquement la fin des logs

Pour éviter de se faire spammer avec des dizaines de pages d'infos, on peut utiliser l'option --tail:

$ docker logs --tail 3 068
Fri Feb 20 00:55:35 UTC 2015
Fri Feb 20 00:55:36 UTC 2015
Fri Feb 20 00:55:37 UTC 2015

• Le paramètre est le nombre de lignes que nous voulons afficher.

containers/Background_Containers.md

Suivre les logs en temps réel

Tout comme la commande UNIX standard tail -f, on peut suivre les logs de notre conteneur:

$ docker logs --tail 1 --follow 068
Fri Feb 20 00:57:12 UTC 2015
Fri Feb 20 00:57:13 UTC 2015
^C

• Cela affichera la dernière ligne du fichier log
• Puis, l'affichage continuera de se mettre à jour en temps réel.
• Pour sortir, appuyer sur ^C.

containers/Background_Containers.md

Arrêter notre conteneur

Il y a deux façons de stopper notre conteneur détaché;

• Le tuer via la commande docker kill.
• Le stopper via la commande docker stop.

La première arrête le conteneur immédiatement, en utilisant le signal KILL.

La seconde est plus douce. Elle envoie un signal TERM, et après 10 secondes, si le conteneur n'est pas arrêté, il envoie KILL.

Rappel: le signal KILL ne peut être intercepté, et terminera le conteneur de force.

containers/Background_Containers.md

Arrêter nos conteneurs

Essayons d'arrêter un de ces conteneurs:

$ docker stop 47d6
47d6

Cela va prendre 10 secondes:

• Docker envoie le signal TERM;
• le conteneur ne réagit pas à ce signal (c'est un simple script Shell sans gestion de signal spécifique);
• 10 secondes plus tard, puisque le conteneur est toujours actif, Docker envoie le signal KILL;
• ceci neutralise le conteneur.

containers/Background_Containers.md

Supprimer le reste des conteneurs

Soyons moins patient avec les deux autres conteneurs:

$ docker kill 068 57ad
068
57ad

Les commandes stop et kill acceptent plusieurs IDs de conteneurs.

Ces conteneurs seront supprimés immédiatement (sans le délai de 10 secondes).

Vérifions que nos conteneurs ne s'affichent plus:

$ docker ps

containers/Background_Containers.md

Lister les conteneurs arrêtés

Nous pouvons aussi afficher les conteneurs stoppés, avec l'option -a (--all).

$ docker ps -a
CONTAINER ID  IMAGE           ...  CREATED      STATUS
068cc994ffd0  jpetazzo/clock  ...  21 min. ago  Exited (137) 3 min. ago
57ad9bdfc06b  jpetazzo/clock  ...  21 min. ago  Exited (137) 3 min. ago
47d677dcfba4  jpetazzo/clock  ...  23 min. ago  Exited (137) 3 min. ago
5c1dfd4d81f1  jpetazzo/clock  ...  40 min. ago  Exited (0) 40 min. ago
b13c164401fb  ubuntu          ...  55 min. ago  Exited (130) 53 min. ago

containers/Background_Containers.md

Objectifs

Dans cette section, nous expliquerons:

• Ce qu'est une image;

• Ce qu'est un layer;

• Les différents nommages d'image;

• Comment chercher et télécharger des images;

• Les tags d'image et quand les utiliser.

containers/Initial_Images.md

Qu'est-ce qu'une image?

• Image = fichiers + méta-données

• Ces fichiers forment le système de fichier racine de notre conteneur.

• Les méta-données indiquent un nombre de choses, comme:

  • l'auteur de l'image
  • la commande à exécuter dans le conteneur au démarrage
  • les variables d'environnement à initialiser
  • etc.

• Des couches composent les images, appelées layers, empilées les unes au-dessus des autres.

• Chaque couche peut ajouter, modifier, supprimer des fichiers ou des méta-données.

• Les layers sont partagés entre images pour optimiser l'usage du disque, les temps de transfert et la consommation mémoire.

containers/Initial_Images.md

Exemple d'une web app Java

Chaque des points suivants se traduira par un layer:

• couche de base CentOS
• Paquets et fichier de configuration fournis par le service informatique interne
• JRE
• Tomcat
• Dépendances de notre application
• Code et sources de notre application
• Configuration de notre appli

containers/Initial_Images.md

Différences entre conteneurs et images

• Une image est un système de fichiers en lecture seule.

• Un conteneur est un ensemble de processus encapsulé dans une copie en lecture/écriture de ce système de fichiers.

• Pour optimiser le temps de démarrage du conteneur, on fait du copy-on-write au lieu d'une copie traditionnelle.

• docker run démarre un conteneur depuis une image donnée.

containers/Initial_Images.md

Comparaison avec la programmation orientée objet

• Conceptuellement, les images sont proches des classes.

• Conceptuellement, les layers sont proches de l'héritage.

• Conceptuellement, les conteneurs sont proches des instances.

containers/Initial_Images.md

Attends un peu...

Si une image est en lecture-seule, comment on la change?

• On ne la change pas.

• On lance un nouveau conteneur à partir de cette image.

• Puis on apporte des modifications à ce conteneur.

• Quand on a fini, nous les figeons dans un nouveau layer.

• Une nouvelle image est créée en empilant la nouvelle couche au-dessus de l'ancienne image.

containers/Initial_Images.md

Le problème de l'oeuf et la poule

• La seule façon de créer une image est de geler un conteneur.

• La seule façon de créer un conteneur est d'instancier une image.

• A l'aide!

containers/Initial_Images.md

Créer les premières images

Il existe une image spéciale vide, appelée scratch.

• Elle permet de générer une image de zéro.

La commande docker import charge un fichier tarball dans Docker.

• L'image importée devient une image indépendante.
• Cette nouvelle image a un seul layer.

Note: vous n'aurez sans doute jamais à faire cela vous-même.

containers/Initial_Images.md

Créer d'autres images

docker commit

• Enregistre tous les changements d'un conteneur dans un nouveau layer.
• Génère une nouvelle image (en réalité une copie du conteneur).

docker build (utilisé 99% du temps)

• Exécute une séquence répétable de construction.
• C'est la méthode recommandée!

Nous expliquerons les deux méthodes dans un moment.

containers/Initial_Images.md

Images et espaces de nommage

Il existe trois espaces de nommage (namespaces):

• Images officielles:

  par ex. ubuntu, busybox, etc.

• Images d'utilisateurs (et organisations):

  par ex. jpetazzo/clock

• Images auto hébergées

  par ex. registry.example.com:5000/mon-image/privee

Examinons chacun d'entre eux.

containers/Initial_Images.md

Espace de nom 'racine'

L'espace de nom racine est pour les images officielles. Elles y sont placées par Docker Inc., mais sont généralement écrites et maintenues par des tierces parties.

Ces images incluent:

• De petites images "couteau suisse", telles busybox.

• Des images de distributions Linux servant de base aux builds, comme ubuntu, fedora, etc.

• Des services et composants prêts à l'emploi, comme redis, postgresql, etc.

• Plus de 150 à ce jour!

containers/Initial_Images.md

Espace de nommage utilisateur

L'espace de nommage pour utilisateur contient les images dans Docker Hub fournies par les utilisateurs et organisations.

Par exemple:

jpetazzo/clock

L'utilisateur Docker Hub est:

jpetazzo

Le nom de l'image est:

clock

containers/Initial_Images.md

Espace de nommage auto-hébergé

Cet espace de nommage contient les images qui ne sont pas hébergées sur Docker Hub, mais sur des registres de tierce partie.

Ils contiennent le nom de serveur (ou adresse IP), et le port (en option), du serveur de registre.

Par exemple:

localhost:5000/wordpress

• localhost:5000 est l'hôte et le port du registre
• wordpress est le nom de cette image

Other examples:

quay.io/coreos/etcd
gcr.io/google-containers/hugo

containers/Initial_Images.md

Comment gérer et stocker les images?

On stocke les images:

• sur votre hôte Docker.
• dans un registre Docker.

Vous pouvez utiliser le client Docker pour télécharger (pull) ou téléverser (push) des images.

Pour être plus précis: vous pouvez utiliser le client Docker pour intimer au Docker Engine de push et pull des images vers/depuis un registre.

containers/Initial_Images.md

Afficher les images actuelles

Voyons quelles sont les images disponibles sur notre serveur.

$ docker images
REPOSITORY       TAG       IMAGE ID       CREATED         SIZE
fedora           latest    ddd5c9c1d0f2   3 days ago      204.7 MB
centos           latest    d0e7f81ca65c   3 days ago      196.6 MB
ubuntu           latest    07c86167cdc4   4 days ago      188 MB
redis            latest    4f5f397d4b7c   5 days ago      177.6 MB
postgres         latest    afe2b5e1859b   5 days ago      264.5 MB
alpine           latest    70c557e50ed6   5 days ago      4.798 MB
debian           latest    f50f9524513f   6 days ago      125.1 MB
busybox          latest    3240943c9ea3   2 weeks ago     1.114 MB
training/namer   latest    902673acc741   9 months ago    289.3 MB
jpetazzo/clock   latest    12068b93616f   12 months ago   2.433 MB

containers/Initial_Images.md

Chercher des images

Nous ne pouvons lister toutes les images sur un registre distant, mais nous pouvons chercher un mot-clé spécifique:

$ docker search marathon
NAME                     DESCRIPTION                     STARS  OFFICIAL  AUTOMATED
mesosphere/marathon      A cluster-wide init and co...   105              [OK]
mesoscloud/marathon      Marathon                        31               [OK]
mesosphere/marathon-lb   Script to update haproxy b...   22               [OK]
tobilg/mongodb-marathon  A Docker image to start a ...   4                [OK]

• "Stars" mesure la popularité de l'image.

• "Official" concerne les images qui sont dans le namespace racine.

• "Automated" indique que l'image est générée automatiquement par le Docker Hub.
  (Cela signifie que leur recette de construction est toujours disponible.)

containers/Initial_Images.md

Télécharger des images

Il y a deux façons de récupérer des images.

• Explicite, avec docker pull.

• Implicite, en lançant docker run et l'image n'est pas disponible en local.

containers/Initial_Images.md

Télécharger une image via pull

$ docker pull debian:jessie
Pulling repository debian
b164861940b8: Download complete
b164861940b8: Pulling image (jessie) from debian
d1881793a057: Download complete

• Comme vu précédemment, les images sont faites de layers.

• Docker a téléchargé tous les layers nécessaires.

• Dans notre exemple, :jessie indique quelle version exacte de Debian nous voulons.

C'est un tag (étiquette) de version.

containers/Initial_Images.md

Images et tags

• On peut associer des tags aux images.

• C'est utile pour préciser les versions ou variantes d'une image.

• docker pull ubuntu va se référer à ubuntu:latest.

• Le tag latest est par tradition mis à jour fréquemment.

containers/Initial_Images.md

Quand utiliser (et ne pas utiliser) les tags

Pas besoin de spécifier d'étiquette (tag) pour:

• des tests ou prototypes rapides.
• expérimenter.
• récupérer la dernière version.

Utiliser des tags pour:

• Persister une procédure dans un script;
• Déployer en production;
• Garantir que la même version sera utilisée partout;
• Garantir la répétabilité future.

This is similar to what we would do with pip install, npm install, etc.

containers/Initial_Images.md

Résumé du chapitre

Nous avons appris comment:

• Comprendre les images et layers;
• Fonctionne les espaces de nom dans Docker;
• Chercher et télécharger des images.

containers/Initial_Images.md

Objectifs

Nous allons construire une image de conteneur automatiquement, grâce au Dockerfile.

A la fin de cette leçon, vous saurez comment:

• Ecrire un Dockerfile.

• Générer une image (build) via un Dockerfile.

containers/Building_Images_With_Dockerfiles.md

Aperçu d'un Dockerfile

• Un Dockerfile est une recette de construction pour une image Docker.

• Il contient une série d'instructions indiquant à Docker comment l'image est construite.

• La commande docker build génère une image à partir d'un Dockerfile.

containers/Building_Images_With_Dockerfiles.md

Ecrire notre premier Dockerfile

Notre Dockerfile doit être dans un dossier nouveau et vide.

1. Ajouter un nouveau dossier pour accueillir notre Dockerfile.

$ mkdir myimage

1. Créer un fichier Dockerfile à l'intérieur de ce nouveau dossier.

$ cd myimage
$ vim Dockerfile

Bien sûr, vous pouvez utiliser n'importe quel éditeur de votre choix.

containers/Building_Images_With_Dockerfiles.md

Entrez ces lignes dans notre Dockerfile...

FROM ubuntu
RUN apt-get update
RUN apt-get install figlet

• FROM indique notre image de base pour notre build.

• Chaque ligne RUN sera exécutée par Docker pendant le build.

• Nos commandes RUN doivent être non-interactive.
  (Aucune entrée ne peut être fournie à Docker pendant le build).

• Dans bien des cas, nous ajouterons l'option -y à apt-get.

containers/Building_Images_With_Dockerfiles.md

Construisons-la!

Enregistrez notre fichier, et lancez:

$ docker build -t figlet .

• -t indique le tag à appliquer à l'image.

• . indique la localisation du build context.

Nous parlerons en détails du build context plus tard.

Pour garder les choses simples: c'est le dossier où se trouve notre Dockerfile.

containers/Building_Images_With_Dockerfiles.md

Que se passe-t-il quand nous générons l'image?

L'affichage de docker build ressemble à ceci:

docker build -t figlet .
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM ubuntu
 ---> f975c5035748
Step 2/3 : RUN apt-get update
 ---> Running in e01b294dbffd
(...output of the RUN command...)
Removing intermediate container e01b294dbffd
 ---> eb8d9b561b37
Step 3/3 : RUN apt-get install figlet
 ---> Running in c29230d70f9b
(...output of the RUN command...)
Removing intermediate container c29230d70f9b
 ---> 0dfd7a253f21
Successfully built 0dfd7a253f21
Successfully tagged figlet:latest

• L'affichage des commandes RUN a été omis.
• Voyons voir en quoi consiste cet affichage.

containers/Building_Images_With_Dockerfiles.md

Envoi du build context à Docker

Sending build context to Docker daemon 2.048 kB

• Le build context est le dossier . donné à docker build.

• Il est envoyé (sous forme d'archive) par le client Docker au daemon Docker.

• Cela permet d'utiliser un serveur distant pour le build utilisant des fichiers locaux.

• Soyez attentifs (ou patient) si ce dossier est lourd et votre connexion est lente.

• You can speed up the process with a .dockerignore file

  • It tells docker to ignore specific files in the directory

  • Only ignore files that you won't need in the build context!

containers/Building_Images_With_Dockerfiles.md

Exécution de chaque étape

Step 2/3 : RUN apt-get update
 ---> Running in e01b294dbffd
(...output of the RUN command...)
Removing intermediate container e01b294dbffd
 ---> eb8d9b561b37

• Un container (e01b294dbffd) est créé à partir de l'image de base.

• La commande RUN se lance dans ce container.

• Le conteneur est sauvé dans une nouvelle image (eb8d9b561b37)

• Le conteneur de build (e01b294dbffd) est supprimé.

• Le résultat de cette étape sera l'image de base pour la prochaine commande.

containers/Building_Images_With_Dockerfiles.md

Le système de cache

Si vous lancez le même build de nouveau, ce sera instantané. Pourquoi?

• Après chaque étape de build, Docker prend un snapshot de l'image résultante.

• Avant chaque nouvelle étape, Docker vérifie si la même séquence a été générée.

• Docker utilise les chaines de caractères exactes définies dans votre Dockerfile, donc:

  • RUN apt-get install figlet cowsay
    est différent de
    RUN apt-get install cowsay figlet
  • RUN apt-get update n'est pas exécuté, quand les miroirs sont mis à jour.

Vous pouvez forcer un nouveau build avec docker build --no-cache....

containers/Building_Images_With_Dockerfiles.md

Lancer l'image

L'image résultante n'est pas différente de celle définie manuellement.

$ docker run -ti figlet
root@91f3c974c9a1:/# figlet hello
 _          _ _       
| |__   ___| | | ___  
| '_ \ / _ \ | |/ _ \ 
| | | |  __/ | | (_) |
|_| |_|\___|_|_|\___/

Youpi! 🎉

containers/Building_Images_With_Dockerfiles.md

Utiliser l'image et afficher l'historique

La commande history liste toutes les couches composant une image.

Pour chaque couche (layer), on voit la date de création, sa taille et la commande utilisée.

Quand une image est générée via un Dockerfile, chaque layer correspond à une ligne du Dockerfile.

$ docker history figlet
IMAGE         CREATED            CREATED BY                     SIZE
f9e8f1642759  About an hour ago  /bin/sh -c apt-get install fi  1.627 MB
7257c37726a1  About an hour ago  /bin/sh -c apt-get update      21.58 MB
07c86167cdc4  4 days ago         /bin/sh -c #(nop) CMD ["/bin   0 B
<missing>     4 days ago         /bin/sh -c sed -i 's/^#\s*\(   1.895 kB
<missing>     4 days ago         /bin/sh -c echo '#!/bin/sh'    194.5 kB
<missing>     4 days ago         /bin/sh -c #(nop) ADD file:b   187.8 MB

containers/Building_Images_With_Dockerfiles.md

Introduction à la syntaxe JSON

La plupart des arguments de Dockerfile peuvent être passés sous deux formes:

• chaine simple:
  RUN apt-get install figlet

• liste JSON:
  RUN ["apt-get", "install", "figlet"]

Nous allons changer notre Dockerfile et voir comment cela affecte l'image résultante.

containers/Building_Images_With_Dockerfiles.md

Usage de la syntaxe JSON dans notre Dockerfile

Changeons notre Dockerfile comme suit:

FROM ubuntu
RUN apt-get update
RUN ["apt-get", "install", "figlet"]

Puis relançons un build du nouveau Dockerfile.

$ docker build -t figlet .

containers/Building_Images_With_Dockerfiles.md

Syntaxe JSON vs syntaxe simple

Comparons le nouvel historique:

$ docker history figlet
IMAGE         CREATED            CREATED BY                     SIZE
27954bb5faaf  10 seconds ago     apt-get install figlet         1.627 MB
7257c37726a1  About an hour ago  /bin/sh -c apt-get update      21.58 MB
07c86167cdc4  4 days ago         /bin/sh -c #(nop) CMD ["/bin   0 B
<missing>     4 days ago         /bin/sh -c sed -i 's/^#\s*\(   1.895 kB
<missing>     4 days ago         /bin/sh -c echo '#!/bin/sh'    194.5 kB
<missing>     4 days ago         /bin/sh -c #(nop) ADD file:b   187.8 MB

• La syntaxe JSON spécifie une commande exacte à exécuter.

• La syntaxe simple spécifie une commande à être encapsulée dans /bin/sh -c "...".

containers/Building_Images_With_Dockerfiles.md

Quand utiliser la syntaxe JSON et la syntaxe simple

• La syntaxe simple:

  • est plus facile à écrire
  • extrapole les variables d'environnement et d'autres expressions de shell
  • crée un processus supplémentaire (/bin/sh -c ...) pour interpréter la commande
  • exige l'existence de /bin/sh dans le conteneur

• La syntaxe JSON:

  • est plus longue à écrire (et à lire!)
  • passe tous les arguments sans interprétation
  • n'ajoute pas de processus supplémentaire
  • ne requiert pas l'existence de /bin/sh dans le conteneur

containers/Building_Images_With_Dockerfiles.md

Objectifs

Dans cette leçon, nous verrons deux instructions importantes du Dockerfile:

CMD et ENTRYPOINT.

Ces instructions nous permettent de déclarer la commande par défaut à lancer dans un conteneur.

containers/Cmd_And_Entrypoint.md

Définir une commande par défaut

Quand quelqu'un lancera notre conteneur, nous voulons le saluer avec un sympathique bonjour, et une fonte spéciale.

Pour ça, nous allons lancer:

figlet -f script hello

• -f script dit à figlet d'utiliser une fonte spécifique.

• hello est le message que nous voulons afficher.

containers/Cmd_And_Entrypoint.md

Ajouter CMD à notre Dockerfile

Notre nouveau Dockerfile aura cet aspect:

FROM ubuntu
RUN apt-get update
RUN ["apt-get", "install", "figlet"]
CMD figlet -f script hello

• CMD définit une commande par défaut à lancer quand aucune n'est précisée.

• Elle peut apparaître n'importe où dans le fichier.

• Chaque CMD annulera et remplacera la précédente.

• Par conséquent, même si vous pouvez utiliser plusieurs fois CMD, c'est inutile au final.

containers/Cmd_And_Entrypoint.md

Générer et tester notre image

Essayons de lancer un build:

$ docker build -t figlet .
...
Successfully built 042dff3b4a8d
Successfully tagged figlet:latest

Et de le lancer:

$ docker run figlet
 _          _   _       
| |        | | | |      
| |     _  | | | |  __  
|/ \   |/  |/  |/  /  \_
|   |_/|__/|__/|__/\__/

containers/Cmd_And_Entrypoint.md

Surcharger CMD

Si nous voulons ouvrir un shell dans notre conteneur (au lieu de lancer figlet), il suffit de spécifier un autre programme à lancer:

$ docker run -it figlet bash
root@7ac86a641116:/#

• On a indiqué bash

• Il a remplacé la valeur de CMD

containers/Cmd_And_Entrypoint.md

Utiliser ENTRYPOINT

Nous voulons être capable de spécifier un message différent en ligne de commande, tout en gardant figlet et quelques paramètres par défaut.

Autrement dit, on aimerait taper quelque chose comme:

$ docker run figlet salut
           _            
          | |           
 ,   __,  | |       _|_ 
/ \_/  |  |/  |   |  |  
 \/ \_/|_/|__/ \_/|_/|_/

Nous utiliserons pour ça l'instruction ENTRYPOINT du Dockerfile.

containers/Cmd_And_Entrypoint.md

Ajouter ENTRYPOINT à notre Dockerfile

Notre nouveau Dockerfile aura cet aspect:

FROM ubuntu
RUN apt-get update
RUN ["apt-get", "install", "figlet"]
ENTRYPOINT ["figlet", "-f", "script"]

• ENTRYPOINT définit une commande de base (et ses paramètres) pour le conteneur.

• Les arguments en ligne de commande sont ajoutés aux paramètres ci-dessus.

• Tout comme CMD, ENTRYPOINT peut apparaître n'importe où, et remplacera la valeur précédente.

Pourquoi avoir utilisé la syntaxe JSON pour notre ENTRYPOINT?

containers/Cmd_And_Entrypoint.md

Implications des syntaxes JSON vs simple

• Quand CMD ou ENTRYPOINT utilisent la syntaxe simple, ils sont encapsulés dans sh -c

• Pour éviter ce comportement, on peut utiliser la syntaxe JSON.

Et qu'est-ce qu'il se passerait avec une syntaxe simple dans ENTRYPOINT?

$ docker run figlet salut

On obtiendrait la commande suivante dans l'image figlet:

sh -c "figlet -f script" salut

containers/Cmd_And_Entrypoint.md

Générer et tester notre image

Lançons un build:

$ docker build -t figlet .
...
Successfully built 36f588918d73
Successfully tagged figlet:latest

Exécutons là:

$ docker run figlet salut
           _            
          | |           
 ,   __,  | |       _|_ 
/ \_/  |  |/  |   |  |  
 \/ \_/|_/|__/ \_/|_/|_/

containers/Cmd_And_Entrypoint.md

Usage conjoint de CMD et ENTRYPOINT

Et si nous voulions définir un message par défaut pour notre conteneur?

Alors nous utiliserions ENTRYPOINT et CMD ensemble.

• ENTRYPOINT va définir la commande de base pour notre conteneur.

• CMD définira les paramètres par défaut pour cette commande.

Ils doivent tous les deux utiliser la syntaxe JSON.

containers/Cmd_And_Entrypoint.md

CMD et ENTRYPOINT ensemble

Notre nouveau Dockerfile a cette tête:

FROM ubuntu
RUN apt-get update
RUN ["apt-get", "install", "figlet"]
ENTRYPOINT ["figlet", "-f", "script"]
CMD ["hello world"]

• ENTRYPOINT définit une commande de base (et ses paramètres) pour le conteneur.

• Si nous ne spécifions aucun argument supplémentaire au lancement du conteneur, la valeur de CMD y est ajoutée.

• Autrement, nos arguments supplémentaires de ligne de commande remplacent CMD.

containers/Cmd_And_Entrypoint.md

Générer et tester notre image

Lançons un build:

$ docker build -t myfiglet .
...
Successfully built 6e0b6a048a07
Successfully tagged myfiglet:latest

Exécutons-là sans paramètres:

$ docker run myfiglet
 _          _   _                             _        
| |        | | | |                           | |    |  
| |     _  | | | |  __             __   ,_   | |  __|  
|/ \   |/  |/  |/  /  \_  |  |  |_/  \_/  |  |/  /  |  
|   |_/|__/|__/|__/\__/    \/ \/  \__/    |_/|__/\_/|_/

containers/Cmd_And_Entrypoint.md

Surcharger les paramètres par défaut de l'image

Maintenant, passons des arguments supplémentaires à l'image.

$ docker run myfiglet hola mundo
 _           _                                               
| |         | |                                      |       
| |     __  | |  __,     _  _  _           _  _    __|   __  
|/ \   /  \_|/  /  |    / |/ |/ |  |   |  / |/ |  /  |  /  \_
|   |_/\__/ |__/\_/|_/    |  |  |_/ \_/|_/  |  |_/\_/|_/\__/

Nous avons surchargé CMD tout en gardant ENTRYPOINT.

containers/Cmd_And_Entrypoint.md

Surcharger ENTRYPOINT

Et si nous voulons lancer un shell dans notre conteneur?

On ne peut pas juste taper docker run figlet bash car ça dirait juste à figlet d'afficher le mot "bash".

On utilise donc le paramètre --entrypoint:

$ docker run -it --entrypoint bash myfiglet
root@6027e44e2955:/#

containers/Cmd_And_Entrypoint.md

Objectifs

Jusqu'ici, nous avons installé des choses dans nos images de conteneurs en téléchargeant des paquets.

Nous pouvons aussi copier des fichiers depuis le build context vers le conteneur que nous générons.

Rappel: le build context est le dossier qui contient le Dockerfile.

Dans ce chapitre, nous apprendrons une nouvelle instruction du Dockerfile: COPY.

containers/Copying_Files_During_Build.md

Compilons du code C

Nous voulons construire un conteneur qui compile un simple programme "Hello world" écrit en C.

Voici le programme, hello.c:

int main () {
  puts("Hello, world!");
  return 0;
}

Ouvrons un nouveau dossier, et plaçons ce fichier à l'intérieur.

Nous écrirons ensuite le Dockerfile.

containers/Copying_Files_During_Build.md

Le Dockerfile

Sur Debian et Ubuntu, le paquet build-essential nous donnera un compilateur.

En l'installant, n'oubliez pas de spécifier l'option -y, ou sinon le build échouera (puisque cette phase ne peut pas être intéractive).

Puis nous allons utiliser COPY pour placer le fichier source dans le conteneur.

FROM ubuntu
RUN apt-get update
RUN apt-get install -y build-essential
COPY hello.c /
RUN make hello
CMD /hello

Ecrivez ce Dockerfile.

containers/Copying_Files_During_Build.md

Tester notre programme C

• Créez les fichiers hello.c et Dockerfile dans le même dossier.

• Lancer docker build -t hello . dans ce dossier.

• Lancer docker run hello, vous devriez voir Hello, world!.

Victoire!

containers/Copying_Files_During_Build.md

COPY et le cache de build

• Lancez le build encore.

• Maintenant, modifiez hello.c et lancer le build encore.

• Docker peut mettre en cache les étapes impliquant COPY.

• Ces étapes ne seront pas exécutées si les fichiers n'ont pas changé.

containers/Copying_Files_During_Build.md

Détails

• On peut COPY des dossiers complets en récursif.

• D'anciens Dockerfiles peuvent aussi comporter l'instruction ADD.
  C'est similaire sauf qu'il peut aussi extraire des archives automatiquement.

• Si nous voulions vraiment compiler le code C dans le conteneur, nous aurions:

  • copié le source dans un dossier différent, via l'instruction WORKDIR.

  • ou mieux encore, utilisé l'image officielle gcc.

containers/Copying_Files_During_Build.md

Réduire la taille de l'image

• Dans notre précédent exemple, notre image finale contenait:

  • notre programme hello

  • son code source

  • le compilateur

• Seul le premier élément est strictement nécessaire.

• Nous allons voir comment obtenir une image sans les composants superflus.

containers/Multi_Stage_Builds.md

Ne pouvons-nous pas retirer les fichiers superflus avec RUN?

Que se passe-t-il si nous utilisons une des commandes suivantes?

• RUN rm -rf ...

• RUN apt-get remove ...

• RUN make clean ...

Retirer les fichiers avec un layer en plus

En téléchargeant une image, tous les layers doivent être récupérés.

En conséquence, RUN rm ne réduit pas la taille de l'image, ni ne libère d'espace disque.

containers/Multi_Stage_Builds.md

Supprimer les fichiers inutiles

Des techniques variées sont disponibles pour obtenir des images plus petites:

• dégonflement de layers,

• ajouter des binaires qui sont générés hors du Dockerfile,

• aplatir l'image finale,

• les builds multi-stage, à multiples étapes.

Passons-les en revue rapidement.

containers/Multi_Stage_Builds.md

Dégonflement de layers

Vous verrez souvent des Dockerfiles comme suit:

FROM ubuntu
RUN apt-get update && apt-get install xxx && ... && apt-get remove xxx && ...

Ou la variante plus lisible:

FROM ubuntu
RUN apt-get update \
 && apt-get install xxx \
 && ... \
 && apt-get remove xxx \
 && ...

Cette commande RUN nous retourne une seule couche.

Les fichiers qui y sont ajoutés, puis supprimés dans le même layer, n'augmentent pas sa taille.

containers/Multi_Stage_Builds.md

Dégonflement de layers : pour et contre

Pour:

• fonctionne sur toutes les versions de Docker

• n'exige pas d'outils spéciaux

Contre:

• pas très lisible

• quelques fichiers inutiles pourraient subsister si le nettoyage n'était pas assez poussé

• ce layer est coûteux (lent à générer)

containers/Multi_Stage_Builds.md

Compiler les binaires hors du Dockerfile

Cela résulte dans un Dockerfile qui ressemble à ça:

FROM ubuntu
COPY xxx /usr/local/bin

Bien sûr, cela suppose que le fichier xxx existe déjà dans le build context.

Ce fichier doit exister avant de lancer docker build.

Par exemple, il peut:

• exister dans le dépôt du code,
• être créé par un autre outil (script, Makefile...),
• être créé par un autre conteneur puis extrait depuis l'image.

Voir par exemple l'image officielle busybox ou cette image busybox plus ancienne.

containers/Multi_Stage_Builds.md

Compiler les binaires en dehors: pour et contre

Pour:

• l'image finale peut être très petite

Contre:

• exige un outil de build supplémentaire

• nous retombons dans l'enfer des dépendances et le "ça-marche-sur-mon-poste"

Contre, si le binaire est ajouté au dépôt de code:

• brise la portabilité entre différentes plate-formes

• augmente largement la taille du dépôt si le binaire est souvent mis à jour

containers/Multi_Stage_Builds.md

Aplatir l'image finale

L'idée est de transformer l'image finale en une image à un seul layer.

Cela peut être réalisé de deux manières (au moins).

• Activer les fonctions expérimentales et aplatir l'image finale:

  docker image build --squash ...

• Exporter/importer l'image finale.

  docker build -t temp-image .
  docker run --entrypoint true --name temp-container temp-image
  docker export temp-container | docker import - final-image
  docker rm temp-container
  docker rmi temp-image

containers/Multi_Stage_Builds.md

Aplatir l'image finale: pour et contre

Pour:

• les images à layer unique sont plus légères et rapides à télécharger

• les fichiers supprimés ne prennent plus de place ni de ressources réseau.

Contre:

• nous devons quand même activement supprimer les fichiers inutiles;

• aplatir une image peut prendre beaucoup de temps (pour les plus grosses images)

• aplatir est une opération qui annule le cache
  (ne changer ne serait-ce qu'un petit fichier, et toute l'image doit être aplatie de nouveau)

containers/Multi_Stage_Builds.md

Builds multi-stage

Un build multi-stage nous permet d'indiquer plusieurs étapes d'images.

Chaque étape constitue une image séparée, et peut copier les fichiers des images précédentes.

Nous allons voir comment ça marche plus en détail.

containers/Multi_Stage_Builds.md

Builds multi-stage

• A tout moment dans notre Dockerfile, nous pouvons ajouter une ligne FROM.

• Cette ligne démarre une nouvelle étape dans notre build.

• Chaque étape peut accéder aux fichiers des étapes précédentes avec COPY --from=....

• Quand un build est étiqueté (avec docker build -t ...), c'est la dernière étape qui récupère le tag.

• Les étapes précédentes ne sont pas supprimées, elle seront utilisées par le cache, et peuvent être référencées.

containers/Multi_Stage_Builds.md

Builds multi-stage en pratique

• Chaque étape est numérotée, en débutant à 0

• Nous pouvons copier un fichier d'une étape précédente en indiquant son numéro, par ex.:

  COPY --from=0 /fichier/depuis/etape/une /chemin/dans/etape/courante

• Nous pouvons aussi nommer les étapes, et y faire référence:

  FROM golang AS builder
  RUN ...
  FROM alpine
  COPY --from=builder /go/bin/mylittlebinary /usr/local/bin/

containers/Multi_Stage_Builds.md

Builds multi-stage pour notre programme C

Nous allons changer notre Dockerfile pour:

• donner un surnom à notre première étape: compiler

• ajouter une seconde étape utilisant la même image de base ubuntu

• ajouter le binaire hello à la seconde étape

• vérifier que CMD est dans la seconde étape

Le Dockerfile résultant est dans la prochaine diapo.

containers/Multi_Stage_Builds.md

Dockerfile du build multi-stage

Voici le Dockerfile final:

FROM ubuntu AS compiler
RUN apt-get update
RUN apt-get install -y build-essential
COPY hello.c /
RUN make hello
FROM ubuntu
COPY --from=compiler /hello /hello
CMD /hello

Essayons de le générer, et vérifions que cela fonctionne bien:

docker build -t hellomultistage .
docker run hellomultistage

containers/Multi_Stage_Builds.md

Comparaison des tailles d'image en build simple/multi-stage

Listez nos images avec docker images, et vérifiez la taille de:

• l'image de base ubuntu,

• l'image hello à étape unique,

• l'image hellomultistage à plusieurs étapes.

Nous pouvons arriver à des tailles d'images encore plus petites avec des images de base plus petites.

Toutefois, si nous utilisons une image de base commune (par ex. en prenant comme standard ubuntu), ces images en commun ne seront téléchargées qu'une fois par hôte, les rendant virtuellement "gratuites".

containers/Multi_Stage_Builds.md

Cibles de build

• On peut aussi étiqueter une étape intermédiaire avec docker build --target STAGE --tag NAME

• Cela va créer une image (appelée NAME) correspondant à l'étape STAGE

• Elle peut être utilisée pour accéder facilement à une étape intermédiaire pour inspection.

  (Au lieu de fouiller l'affichage de docker build pour trouver l'ID d'image)

• Elle peut aussi être utilisée pour générer de multiples images avec un seul Dockerfile

  (Au lieu d'utiliser plusieurs Dockerfiles, qu'il faudrait perpétuellement synchroniser)

containers/Multi_Stage_Builds.md

Publier des images sur le Docker Hub

Nous avons généré nos premières images.

Nous pouvons maintenant les publier vers le Docker Hub!

Vous n'avez pas à faire les exercices de cette section, parce qu'ils exigent un compte sur le Docker Hub, et nous ne voulons forcer personne à en créer un.

Veuillez noter, toutefois, que la création d'un compte sur le Docker Hub est gratuite (sans carte bancaire), et que l'hébergement d'images publiques est aussi gratuit.

containers/Publishing_To_Docker_Hub.md

Connexion au Docker Hub

• C'est faisable depuis la ligne de commande Docker:

  docker login

containers/Publishing_To_Docker_Hub.md

Tags d'image et adresses de registre

• Docker et ses tags d'images sont comme Git et ses tags/branches.

• Ce sont des pointeurs vers un ID d'image spécifique.

• Marquer une image ne renomme pas cette image: elle ne fait qu'ajouter une étiquette.

• En poussant une image vers un registre distant, l'adresse de registre est dans le tag.

  Example: registry.example.net:5000/image

• Qu'en est-il des images du Docker Hub?

Etiqueter une image pour la pousser sur le Hub

• Ajoutons une étiquette à notre image figlet (ou une autre):

  docker tag figlet jpetazzo/figlet

• Et poussons-là sur le Hub:

  docker push jpetazzo/figlet

• C'est tout!

Les vertus des builds automatisés

• Vous pouvez lier un dépôt du Docker Hub avec un dépôt Github ou BitBucket.

• Chaque push dans Github/Bitbucket va déclencher un build sur Docker Hub.

• Si l'image est générée avec succès, elle sera disponible sur Docker Hub.

• Vous pouvez associer tags et branches entre le code source et images de conteneurs.

• Si vous maintenez des dépôts publics, tout ça est gratuit.

containers/Publishing_To_Docker_Hub.md

Astuces pour Dockerfiles efficaces

Nous allons voir comment:

• réduire le nombre de layers.

• Exploiter le cache de build pour accélérer la construction.

• Injecter les tests unitaires dans le processus de génération.

containers/Dockerfile_Tips.md

Réduire le nombre de layers

• Chaque ligne du Dockerfile ajoute une nouvelle couche.

• Ecrivez votre Dockerfile pour exploiter le système de cache de Docker.

• Combinez les commandes avec && pour chainer les commandes et \ pour empiler les lignes.

Note: il est fréquent d'écrire un Dockerfile ligne par ligne:

RUN apt-get install thisthing
RUN apt-get install andthatthing andthatotherone
RUN apt-get install somemorestuff

Puis le corriger très facilement avant déploiement:

RUN apt-get install thisthing andthatthing andthatotherone somemorestuff

containers/Dockerfile_Tips.md

Eviter de ré-installer les dépendances à chaque build

• Problème classique de Dockerfile:

  "chaque fois que je change une ligne de code, toutes mes dépendances sont ré-installées!"

• Solution: COPY-er les listes de dépendances (packages.json, requirements.txt, etc.) à part pour éviter de ré-installer des dépendances inchangées chaque fois.

containers/Dockerfile_Tips.md

Exemple de "mauvais" Dockerfile

Les dépendances sont ré-installées chaque fois, car le système de build ne sait pas si requirements.txt a été mis à jour.

FROM python
WORKDIR /src
COPY . .
RUN pip install -qr requirements.txt
EXPOSE 5000
CMD ["python", "app.py"]

containers/Dockerfile_Tips.md

Correction du Dockerfile

Ajouter les dépendances dans une étape à part permet à Docker un cache plus efficace, car il ne les installera que si requirements.txt change.

FROM python
COPY requirements.txt /tmp/requirements.txt
RUN pip install -qr /tmp/requirements.txt
WORKDIR /src
COPY . .
EXPOSE 5000
CMD ["python", "app.py"]

containers/Dockerfile_Tips.md

Injecter les tests unitaires dans le processus de génération.

FROM <baseimage>
RUN <install dependencies>
COPY <code>
RUN <build code>
RUN <install test dependencies>
COPY <test data sets and fixtures>
RUN <unit tests>
FROM <baseimage>
RUN <install dependencies>
COPY <code>
RUN <build code>
CMD, EXPOSE ...

• Le build échoue dès qu'une instruction échoue
• Si RUN <unit tests> échoue, le build ne produira aucune image
• S'il réussit, le build générera une image propre (sans librairie de test ni données)

containers/Dockerfile_Tips.md

Exemples de Dockerfile

Il y a quelques astuces, conseils et techniques qu'on peut appliquer dans nos Dockerfiles.

Mais parfois, on se doit de passer par des formes différentes, voire opposées, selon:

• la complexité du projet,

• le langage de programmation ou le framework choisi,

• l'étape du projet (nouveau MVP vs prod super-stable),

• si nous générons une image finale, ou une base pour d'autres images,

• etc.

Nous allons montrer quelques exemples de techniques très différentes.

containers/Dockerfile_Tips.md

Quand optimiser une image

Au moment d'écrire des images officielles, c'est une bonne idée de réduire au maximum:

• le nombre de couches,

• la taille finale de l'image.

C'est souvent au détriment du temps de génération et du confort pour le mainteneur de l'image; mais quand une image est téléchargée des millions de fois, économiser ne serait-ce qu'une poignée de secondes de délai vaut le coup.

RUN apt-get update && apt-get install -y libpng12-dev libjpeg-dev && rm -rf /var/lib/apt/lists/* \
    && docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr \
    && docker-php-ext-install gd
...
RUN curl -o wordpress.tar.gz -SL https://wordpress.org/wordpress-${WORDPRESS_UPSTREAM_VERSION}.tar.gz \
    && echo "$WORDPRESS_SHA1 *wordpress.tar.gz" | sha1sum -c - \
    && tar -xzf wordpress.tar.gz -C /usr/src/ \
    && rm wordpress.tar.gz \
    && chown -R www-data:www-data /usr/src/wordpress

(Source: Image officielle Wordpress)

containers/Dockerfile_Tips.md

Quand ne pas optimiser une image

Parfois, il est préférable de prioriser le confort du mainteneur

En particulier, si:

• l'image change beaucoup,

• l'image a peu d'utilisateurs (par ex. 1 seul, le mainteneur!),

• l'image est générée et lancée sur la même machine,

• l'image est générée et lancée sur des machines sur un réseau très rapide...

Dans ces cas, mieux vaut garder les choses simples!

(Prochaine diapo: un Dockerfile qui peut être utilisé pour un aperçu de site Jekyll / github pages)

containers/Dockerfile_Tips.md

FROM debian:sid
RUN apt-get update -q
RUN apt-get install -yq build-essential make
RUN apt-get install -yq zlib1g-dev
RUN apt-get install -yq ruby ruby-dev
RUN apt-get install -yq python-pygments
RUN apt-get install -yq nodejs
RUN apt-get install -yq cmake
RUN gem install --no-rdoc --no-ri github-pages
COPY . /blog
WORKDIR /blog
VOLUME /blog/_site
EXPOSE 4000
CMD ["jekyll", "serve", "--host", "0.0.0.0", "--incremental"]

containers/Dockerfile_Tips.md

Système de version multi-dimensionnels

Un tag d'image peut indiquer une version de l'image.

Mais parfois, plusieurs composants importants co-existent, et nous devons indiquer les versions de chacun.

C'est possible en passant par des variables d'environnement:

ENV PIP=9.0.3 \
    ZC_BUILDOUT=2.11.2 \
    SETUPTOOLS=38.7.0 \
    PLONE_MAJOR=5.1 \
    PLONE_VERSION=5.1.0 \
    PLONE_MD5=76dc6cfc1c749d763c32fff3a9870d8d

(Source: Image officielle Plone)

containers/Dockerfile_Tips.md

Entrypoints et démarreurs

Il est très courant de définir un entrypoint spécifique.

Ce point d'entrée est généralement un script, réalisant une série d'opérations telles que:

• vérifications avant démarrage (si une dépendance obligatoire n'est pas disponible, afficher un message d'erreur sympa au lieu d'un obscur paquet de lignes dans un fichier log);

• génération ou validation de fichier de configuration;

• limiter les privilèges (avec par ex. su ou gosu, parfois combiné avec chown);

• et plus encore.

containers/Dockerfile_Tips.md

Un script d'entrypoint typique

 #!/bin/sh
 set -e
 # first arg is '-f' or '--some-option'
 # or first arg is 'something.conf'
 if [ "${1#-}" != "$1" ] || [ "${1%.conf}" != "$1" ]; then
     set -- redis-server "$@"
 fi
 # allow the container to be started with '--user'
 if [ "$1" = 'redis-server' -a "$(id -u)" = '0' ]; then
     chown -R redis .
     exec su-exec redis "$0" "$@"
 fi
 exec "$@"

(Source: Image officielle Redis)

containers/Dockerfile_Tips.md

Factoriser les informations

Pour faciliter la maintenance (et éviter les erreurs humaines), évitez de répéter des informations comme:

• numéros de versions,

• URLs de ressources distantes (par ex. fichiers tarballs) ...

Pour ce faire, utilisez des variables d'environnement.

ENV NODE_VERSION 10.2.1
...
RUN ...
    && curl -fsSLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION.tar.xz" \
    && curl -fsSLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \
    && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \
    && grep " node-v$NODE_VERSION.tar.xz\$" SHASUMS256.txt | sha256sum -c - \
    && tar -xf "node-v$NODE_VERSION.tar.xz" \
    && cd "node-v$NODE_VERSION" \
...

(Source: Image officielle Nodejs)

containers/Dockerfile_Tips.md

Surcharge

En théorie, les images de production et développement devraient être les mêmes.

En pratique, nous avons souvent besoin d'activer des comportements spécifiques en développement (par ex. trace de debogage).

Une façon de concilier les deux besoins est d'utiliser Compose pour activer ces comportements.

Jetons un oeil à l'appli de démo trainingwheels comme exemple.

containers/Dockerfile_Tips.md

Image de production

Le Dockerfile génère une image exploitant gunicorn:

FROM python
RUN pip install flask
RUN pip install gunicorn
RUN pip install redis
COPY . /src
WORKDIR /src
CMD gunicorn --bind 0.0.0.0:5000 --workers 10 counter:app
EXPOSE 5000

(Source: Dockerfile trainingwheels)

containers/Dockerfile_Tips.md

Fichier Compose de développement

Ce fichier Compose utilise la même image, mais avec quelques valeurs surchargées en développement:

• On préfère le serveur Flask de développement (surcharge de CMD);

• On définit la variable d'environnement DEBUG;

• On utilise un volume pour fournir un processus de développement local plus rapide.

services:
  www:
    build: www
    ports:
      - 8000:5000
    user: nobody
    environment:
      DEBUG: 1
    command: python counter.py
    volumes:
      - ./www:/src

(Source: Fichier Compose trainingwheels)

containers/Dockerfile_Tips.md

Comment choisir quelles bonnes pratiques sont les meilleures?

• Le but principal des conteneurs est de rendre notre vie meilleure;

• Dans ce chapitre, nous avons montré bien des façons d'écrire des Dockerfiles;

• Ces Dockerfiles utilisent parfois des techniques diamétralement opposées;

• Et pourtant, c'était la "bonne" technique pour cette situation spécifique;

• C'est bien (et souvent encouragé) de commencer simple et d'évoluer selon le besoin;

• N'hésitez pas à revoir ce chapitre plus tard (après quelques Dockerfiles) pour inspiration!

containers/Dockerfile_Tips.md

Objectifs

Nous avons vu des Dockerfiles simples pour illustrer comment Docker construit des images de conteneurs.

Dans cette section, nous allons voir d'autres commandes propres aux Dockerfiles.

containers/Advanced_Dockerfiles.md

Dockerfile, l'essentiel

• Les instructions d'un Dockerfile sont exécutées dans l'ordre.

• Chaque instruction ajoute une nouvelle couche à l'image (layer).

• Docker gère un cache avec les layers des builds précédents.

• Quand rien ne change dans les instructions ou les fichiers qui définissent un layer, le builder récupère la version en cache, sans exécuter l'instruction de ce layer.

• L'instruction FROM DOIT être la première instruction (hormis les commentaires).

• Les lignes débutant par # sont considérées comme des commentaires.

• Quelques instructions (comme CMD et ENTRYPOINT) concernent les méta-données. (avec pour conséquence que chaque mention de ces instructions rend les précédentes obsolètes)

containers/Advanced_Dockerfiles.md

Instruction RUN

L'instruction RUN peut être utilisée de deux manières.

Via le shell wrapping, qui exécute la commande spécifiée dans un shell, avec /bin/sh -c, exemple:

RUN apt-get update

Ou via la méthode exec, qui évite l'expansion de chaine du shell, et permet l'exécution pour les images qui n'embarquent pas /bin/sh, i.e. :

RUN [ "apt-get", "update" ]

containers/Advanced_Dockerfiles.md

RUN plus en détail

RUN est utile pour:

• Exécuter une commande.
• Enregistrer les changements du système de fichiers.
• Installer efficacement des bibliothèques, paquets et divers fichiers.

RUN n'est pas fait pour:

• Enregistrer l'état des processus
• Démarrer automatiquement un process en tache de fond (daemon).

Si vous voulez démarrer automatiquement un processus quand le container se lance, vous devriez passer par CMD et/ou ENTRYPOINT.

containers/Advanced_Dockerfiles.md

Fusion de layers:

Il est possible d'exécuter plusieurs commandes d'un seul coup:

RUN apt-get update && apt-get install -y wget && apt-get clean

Il est aussi possible de répartir une même commande sur plusieurs lignes:

RUN apt-get update \
 && apt-get install -y wget \
 && apt-get clean

containers/Advanced_Dockerfiles.md

Instruction EXPOSE

L'instruction EXPOSE indique à Docker quels ports doivent être publiés pour cette image.

EXPOSE 8080
EXPOSE 80 443
EXPOSE 53/tcp 53/udp

• Tous les ports sont privés par défaut;

• Déclarer un port avec EXPOSE ne suffit pas à le rendre public;

• Le Dockerfile ne contrôle pas sur quel port un service sera exposé.

containers/Advanced_Dockerfiles.md

Exposer des ports

• Quand vous lancez docker run -p <port> ..., ce port devient public;

  (Même s'il n'a pas été déclaré via EXPOSE.)

• Quand vous lancez docker run -P...(sans numéro de port), tous les ports déclarés via EXPOSE deviennent publics.

Un port public est accessible depuis les autres containers et depuis l'extérieur de la machine hôte.

Un port privé n'est pas accessible depuis l'extérieur.

containers/Advanced_Dockerfiles.md

Instruction COPY

L'instruction COPY ajoute des fichiers et du contenu depuis votre machine hôte vers l'image.

COPY . /src

Cela va ajouter le contenu du build context (le dossier passé en argument à la commande docker build) au dossier /src dans l'image.

containers/Advanced_Dockerfiles.md

Isolation du build context

Note: vous pouvez manipuler uniquement les fichiers et dossier contenus dans le build context. Tout chemin absolu est traité comme ayant pour racine le build context, i.e que les 2 lignes suivantes sont équivalentes:

COPY . /src
COPY / /src

Toute tentative d'utiliser .. pour sortir du build context sera détectée et bloquée par Docker, et le build échouera.

Sans cela, un Dockerfile pourrait être valide sur une machine A, mais échouer sur une machine B.

containers/Advanced_Dockerfiles.md

Instruction ADD

ADD fonctionne presque comme COPY, mais avec quelques petits plus.

ADD peut récupérer des fichiers à distance:

ADD http://www.example.com/webapp.jar /opt/

Cette ligne irait télécharger le fichier webapp.jar pour le placer dans le dossier /opt.

ADD va automatiquement décompresser les fichiers zip et tar:

ADD ./assets.zip /var/www/htdocs/assets/

Cette ligne décompresse assets.zip pour copier son contenu dans /var/www/htdocs/assets.

Néanmoins, ADD ne décompressera pas automatiquement les fichiers téléchargés à distance.

containers/Advanced_Dockerfiles.md

ADD, COPY, et le cache de build

• Avant d'ajouter un nouveau layer, Docker vérifie son cache de build.

• Pour la plupart des instructions Dockerfile, Docker examine simplement le contenu du Dockerfile pour la vérification du cache.

• Pour les instructions ADD et COPY, Docker vérifie aussi si les fichiers à ajouter à l'image ont été modifiés.

• ADD doit toujours télécharger tout fichier distant avant de vérifier s'il a changé.

  (Il ne sait pas utiliser par ex. les en-têtes ETags ou If-Modified-Since)

containers/Advanced_Dockerfiles.md

Instruction VOLUME

L'instruction VOLUME indique à Docker qu'un dossier spécifique devrait être un volume.

VOLUME /var/lib/mysql

Les accès filesystem dans les volumes contournent la couche copy-on-write, offrant une performance native dans les I/O de ses dossiers.

Les volumes peuvent être attachés à plusieurs containers, permettant de "transporter" les données d'un container à un autre, dans le cas par ex. d'une mise à jour de base de données vers une version plus récente.

Il est possible de démarrer un container en mode "lecture seule". Le filesystem du container sera restreint en mode "lecture seule", mais tout volume restera en lecture/écriture si nécessaire.

containers/Advanced_Dockerfiles.md

Instruction WORKDIR

L'instruction WORKDIR change le dossier en cours pour les instructions suivantes.

Cela affecte aussi CMD et ENTRYPOINT, puisque cela modifie le dossier de démarrage quand un container se lance.

WORKDIR /src

Vous pouvez spécifier plusieurs WORKDIR pour changer de dossier au cours des différentes opérations.

containers/Advanced_Dockerfiles.md

Instruction ENV

L'instruction ENV déclare des variables d'environnement qui devraient être affectées dans tout container lancé depuis cette image.

ENV WEBAPP_PORT 8080

Ceci a pour résultat de créer une variable d'environnement dans tout container provenant de cette image.

WEBAPP_PORT=8080

Vous pouvez aussi spécifier des variables d'environnement via docker run.

$ docker run -e WEBAPP_PORT=8000 -e WEBAPP_HOST=www.example.com ...

containers/Advanced_Dockerfiles.md

Instruction USER

L'instruction USER change l'utilisateur ou l'UID à utiliser pour la suite des opérations, mais aussi l'utilisateur au lancement du container.

Comme WORKDIR, elle peut être utilisée plusieurs fois, par ex. pour repasser à root ou un autre utilisateur.

containers/Advanced_Dockerfiles.md

Instruction CMD

L'instruction CMD est la commande par défaut qui se lance quand un container est instancié à partir d'une image.

CMD [ "nginx", "-g", "daemon off;" ]

Ceci signifie que nous n'avons pas besoin de spécifier nginx -g "daemon off;" lors du lancement de notre container.

Au lieu de:

$ docker run <dockerhubUsername>/web_image nginx -g "daemon off;"

Nous pouvons juste écrire:

$ docker run <dockerhubUsername>/web_image

containers/Advanced_Dockerfiles.md

CMD plus en détail

Tout comme RUN, l'instruction CMD existe sous deux formes.

La première lance un shell:

CMD nginx -g "daemon off;"

La seconde s'exécute directement, sans passer par un shell:

CMD [ "nginx", "-g", "daemon off;" ]

containers/Advanced_Dockerfiles.md

Instruction ENTRYPOINT

L'instruction ENTRYPOINT ressemble à l'instruction CMD, sauf que les arguments passés en ligne de commande sont ajoutés au point d'entrée.

Note: vous devez utiliser pour cela la syntaxe "exec" (["..."]).

ENTRYPOINT [ "/bin/ls" ]

Avec ceci, si nous lançons la commande:

$ docker run training/ls -l

Au lieu d'essayer de lancer -l, le container va exécuter /bin/ls -l

containers/Advanced_Dockerfiles.md

Comment CMD et ENTRYPOINT interagissent

Les instructions CMD et ENTRYPOINT fonctionnent mieux quand elles sont définies ensemble.

ENTRYPOINT [ "nginx" ]
CMD [ "-g", "daemon off;" ]

La ligne ENTRYPOINT spécifie la command à lancer et la ligne CMD spécifie ses options. En ligne de commande, nous pourrons donc potentiellement surcharger les options le cas échéant.

$ docker run -d <dockerhubUsername>/web_image -t

Cela surchargera les options CMD avec de nouvelles valeurs.

containers/Advanced_Dockerfiles.md

Instructions Dockerfile avancées

• ONBUILD vous permet de cacher des commandes qui ne seront executées que quand cette image servira de base à une autre.
• LABEL ajoute des meta-datas libres à l'image.
• ARG déclare des variables de build (optionelles ou obligatoires).
• STOPSIGNAL indique le signal à envoyer lors d'un docker stop (TERM par défault).
• HEALTHCHECK définit une commande de test vérifiant le statut d'un container.
• SHELL choisit le programme par défaut pour la forme string de RUN, CMD, etc.

containers/Advanced_Dockerfiles.md

Objectifs

Nous allons maintenant lancer des services connectés (acceptant des requêtes) dans des conteneurs.

À la fin de cette section, vous serez capable de:

• Lancer un service connecté dans un conteneur;

• Manipuler les bases du réseau pour conteneur;

• Trouver l'adresse IP d'un conteneur.

Nous expliquerons aussi les différents modèles de réseau usités par Docker.

containers/Container_Networking_Basics.md

Un serveur web simple, statique

Lancer l'image nginx du Docker Hub, qui contient un serveur web basique:

$ docker run -d -P nginx
66b1ce719198711292c8f34f84a7b68c3876cf9f67015e752b94e189d35a204e

• Docker va télécharger l'image depuis le Docker Hub.

• -d dit à Docker de lancer une image en tâche de fond.

• -P dit à Docker de rendre ce service disponible depuis d'autres serveurs.
  (-P est la version courte de --publish-all)

Mais, comment on se connecte à notre serveur web maintenant?

containers/Container_Networking_Basics.md

Trouver le port de notre serveur web

Nous allons utiliser docker ps:

$ docker ps
CONTAINER ID  IMAGE  ...  PORTS                  ...
e40ffb406c9e  nginx  ...  0.0.0.0:32768->80/tcp  ...

• Le serveur web tourne sur le port 80 à l'intérieur du conteneur.

• Ce port correspond au port 32768 sur notre hôte Docker.

Nous expliquerons les pourquoi et comment de ce mappage.

Mais d'abord, assurons-nous que tout fonctionne correctement.

containers/Container_Networking_Basics.md

Connexion à notre serveur web (IHM)

Pointer votre navigateur à l'adresse IP de votre hôte Docker, sur le port affiché par docker ps, correspondant au port 80 du conteneur.

containers/Container_Networking_Basics.md

Connexion à notre serveur web (CLI)

Vous pouvez aussi utiliser curl directement depuis le hôte Docker.

Assurez-vous d'utiliser le bon numéro de port s'il est différent de notre exemple ci-dessous:

$ curl localhost:32768
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

containers/Container_Networking_Basics.md

Comment Docker sait quel port associer?

• Il y a des meta-données dans l'image indiquant "cette image fait tourner quelque chose sur le port 80"

• On peut examiner ces meta-donnéees avec docker inspect:

$ docker inspect --format '{{.Config.ExposedPorts}}' nginx
map[80/tcp:{}]

• Cette méta-donnée a pour origine le Dockerfile, via le mot-clé EXPOSE.

• On peut le constater avec docker history:

$ docker history nginx
IMAGE               CREATED             CREATED BY
7f70b30f2cc6        11 days ago         /bin/sh -c #(nop)  CMD ["nginx" "-g" "…
<missing>           11 days ago         /bin/sh -c #(nop)  STOPSIGNAL [SIGTERM]
<missing>           11 days ago         /bin/sh -c #(nop)  EXPOSE 80/tcp

containers/Container_Networking_Basics.md

Pourquoi le mappage de ports?

• Nous n'avons plus d'adresses IPv4.

• Les conteneurs ne peuvent pas avoir d'adresse IPv4 publiques.

• Ils possèdent des adresses privées.

• Les services doivent être exposés port par port.

• Le mappage de ports est obligatoire pour éviter les conflits.

containers/Container_Networking_Basics.md

Trouver le port du serveur web via un script

Manipuler la sortie de docker ps serait fastidieux.

Il y a une commande pour nous aider:

$ docker port <containerID> 80
32768

containers/Container_Networking_Basics.md

Affectation manuelle des numéros de port

Si vous voulez allouer vous-même les numéros de port, aucun souci:

$ docker run -d -p 80:80 nginx
$ docker run -d -p 8000:80 nginx
$ docker run -d -p 8080:80 -p 8888:80 nginx

• Trois serveurs web NGINX tournent.
• Le premier est exposé sur le port 80.
• Le deuxième est exposé sur le port 8000.
• Le troisième est exposé sur les ports 8080 et 8888.

Note: la convention est port-du-hôte:port-du-conteneur.

containers/Container_Networking_Basics.md

Intégrer les conteneurs dans votre infrastructure

On peut intégrer les conteneurs au réseau de bien des manières.

• Démarrer le conteneur, pour laisser Docker lui allouer un port public.
  Puis lire le port affecté et l'injecter dans votre configuration.

• Choisir un numéro de port à l'avance, au moment de générer votre configuration.
  Puis démarrer votre conteneur en forçant les ports à la main.

• Utiliser un plugin de réseau, pour brancher vos conteneurs sur des VLANs, tunnels, etc.

• Activer le Mode Swarm pour un déploiement à travers un cluster.
  Le conteneur sera accessible depuis n'importe quel noeud du cluster.

En utilisant Docker à travers une couche de gestion supplémentaire comme Mesos ou Kubernetes, ils fournissent en général leurs propres mécanismes d'exposition de conteneurs.

containers/Container_Networking_Basics.md

Trouver l'adresse IP du conteneur

Nous pouvons utiliser la commande docker inspect pour trouver l'adresse IP de notre conteneur.

$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' <yourContainerID>
172.17.0.3

• docker inspect est une commande avancée, qui peut retourner une tonne d'informations à propos des conteneurs.

• Ici, nous lui fournissons une chaîne pour extraire exactement l'adresse IP du conteneur.

containers/Container_Networking_Basics.md

Interroger notre conteneur

Nous pouvons tester la connectivité du conteneur via l'adresse IP déterminée précédemment. Voyons ceci avec l'outil ping.

$ ping <ipAddress>
64 bytes from <ipAddress>: icmp_req=1 ttl=64 time=0.085 ms
64 bytes from <ipAddress>: icmp_req=2 ttl=64 time=0.085 ms
64 bytes from <ipAddress>: icmp_req=3 ttl=64 time=0.085 ms

containers/Container_Networking_Basics.md

Résumé du chapitre

Nous avons appris comment:

• Exposer un port sur le réseau;

• Manipuler les bases du réseau pour conteneur;

• Trouver une adresse IP de conteneur.

Dans le chapitre suivant, nous verrons comment connecter les conteneurs entre eux, sans publier leurs ports.

containers/Container_Networking_Basics.md

Pilote réseau pour conteneur

Le Docker Engine prend en charge de nombreux pilotes réseau.

Certains pilotes sont inclus à l'installation:

• bridge (par défaut)

• none

• host

• container

Le pilote est indiqué avec docker run --net ....

Les différents pilotes sont expliqués en détail dans les diapos suivantes.

containers/Network_Drivers.md

La passerelle par défaut (bridge)

• Par défaut, le conteneur dispose d'une interface eth0 virtuelle.
  (En supplément de lo, sa propre interface de boucle interne).

• Cette interface est fournie par une paire veth.

• Elle est connectée au Docker bridge.
  (Appelé docker0 par défaut; configurable avec --bridge.)

• L'allocation d'adresses IP se fait sur un sous-réseau privé interne.
  (Docker utilise 172.17.0.0/16 par défaut; configurable avec --bip.)

• Le trafic sortant passe à travers une règle iptables MASQUERADE.

• Le trafic entrant passe à travers une règle iptables DNAT.

• Le conteneur peut avoir ses propres routes, règles iptables, etc.

containers/Network_Drivers.md

Le pilote null

• On démarre le conteneur avec docker run --net none ...

• Il n'aura que l'interface de bouclage lo. Pas de eth0.

• Il ne peut ni recevoir ni envoyer de trafic réseau.

• Utile pour les logiciels isolés/suspects.

containers/Network_Drivers.md

Le pilote hôte

• On démarre le conteneur avec docker run --net host ...

• Il voit (et peut accéder) aux interfaces réseau de l'hôte.

• Il peut ouvrir n'importe quelle interface et port (pour le meilleur et pour le pire).

• Le trafic réseau se passe des couches NAT, bridge ou veth.

• Performance = native!

Cas d'usage:

• Applications sensibles à la performance (VOIP, jeu-vidéo, streaming...)

• découvertes d'homologue (par ex. mappage de port Erlang, Raft, Serf ...)

containers/Network_Drivers.md

Le pilote conteneur

• On démarre le conteneur avec docker run --net container:id ...

• Il recycle la pile réseau d'un autre conteneur.

• Il partage avec l'autre conteneur les mêmes interfaces, adresses IP, routes, règles iptables, etc.

• Ces conteneurs peuvent communiquer à travers leur interface lo.
  (i.e. l'un peut s'attacher à 127.0.0.1 et les autres peuvent s'y connecter.)

containers/Network_Drivers.md

Objectifs

Nous aborderons le CNM (Modèle de Réseau pour Container)

A la fin de la leçon, vous serez capable de:

• Créer un réseau privé pour un groupe de containers;

• Utiliser le nommage de container pour connecter les services ensemble;

• Connecter et déconnecter dynamiquement des containers à des réseaux;

• Affecter l'adresse IP à un container.

Nous expliquerons aussi le principe des réseaux overlay et des plugins de réseau.

containers/Container_Network_Model.md

Le Container Network Model

Le CNM a été introduit dans Engine 1.9.0 (Novembre 2015).

Le CNM ajoute la notion de network, et une commande principale pour manipuler et inspecter ces réseaux: docker network.

$ docker network ls
NETWORK ID          NAME                DRIVER
6bde79dfcf70        bridge              bridge
8d9c78725538        none                null
eb0eeab782f4        host                host
4c1ff84d6d3f        blog-dev            overlay
228a4355d548        blog-prod           overlay

containers/Container_Network_Model.md

Qu'est-ce qu'il y a dans un réseau?

• Dans le concept, un réseau est un switch virtuel;

• Il peut être local (dans un Engine simple) ou global (transversal à plusieurs hôtes);

• Un réseau possède un sous-réseau IP associé;

• Docker va affecter de nouvelles adresses IP aux containers connectés à ce réseau;

• Des containers peuvent être connectés à plusieurs réseaux;

• Des containers peuvent se voir affecté des noms et alias par réseau;

• Les noms et alias sont résolus via un serveur DNS embarqué.

containers/Container_Network_Model.md

Détails d'implémentation de réseau

• Un réseau est géré par un driver.

• Les drivers inclus par défaut:

  • bridge (par défaut)
  • none
  • host
  • macvlan

• Un driver multi-hôte, overlay, est inclus sans installation supplémentaire (pour les clusters Swarm).

• Des drivers supplémentaires sont disponibles sous forme de plugins (OVS, VLAN, etc)

• Un réseau peut avoir son propre IPAM (allocation d'IP)

containers/Container_Network_Model.md

Créer un réseau

Essayons de déclarer un nouveau réseau appelé dev.

$ docker network create dev
4c1ff84d6d3f1733d3e233ee039cac276f425a9d5228a4355d54878293a889ba

Le réseau est maintenant visible avec la commande network ls;

$ docker network ls
NETWORK ID          NAME                DRIVER
6bde79dfcf70        bridge              bridge
8d9c78725538        none                null
eb0eeab782f4        host                host
4c1ff84d6d3f        dev                 bridge

containers/Container_Network_Model.md

Placer des containers sur un réseau

Nous allons créer un container nommé sur ce réseau.

Il sera disponible via son nom, es.

$ docker run -d --name es --net dev elasticsearch:2
8abb80e229ce8926c7223beb69699f5f34d6f1d438bfc5682db893e798046863

containers/Container_Network_Model.md

Communication entre containers

Et maintenant, ajoutons un autre container sur ce réseau.

$ docker run -ti --net dev alpine sh
root@0ecccdfa45ef:/#

Depuis ce nouveau container, nous pouvons résoudre et ping l'autre, en utilisant son nom:

/ # ping es
PING es (172.18.0.2) 56(84) bytes of data.
64 bytes from es.dev (172.18.0.2): icmp_seq=1 ttl=64 time=0.221 ms
64 bytes from es.dev (172.18.0.2): icmp_seq=2 ttl=64 time=0.114 ms
64 bytes from es.dev (172.18.0.2): icmp_seq=3 ttl=64 time=0.114 ms
^C
--- es ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.114/0.149/0.221/0.052 ms
root@0ecccdfa45ef:/#

containers/Container_Network_Model.md

Service discovery avec les containers

• Essayons de lancer une application reposant sur deux containers;

• Le premier container est un serveur web;

• L'autre est une base de données redis;

• Nous les placerons tous deux sur le réseau dev créé auparavant;

containers/Container_Network_Model.md

Lancer le serveur web

• L'application est fournie par l'image jpetazzo/trainingwheels.

• Nous en savons peu sur elle, donc nous la lançons et on verra ce qui arrivera!

Démarrer le container, en publiant tous ses ports:

$ docker run --net dev -d -P jpetazzo/trainingwheels

Vérifier quel port lui a été alloué:

$ docker ps -l

containers/Container_Network_Model.md

Tester le serveur web

• Si nous ouvrons l'application à ce stage, nous verrons une page d'erreur:

• C'est parce que le service Redis n'est pas lancé.

• Ce container essaie de résoudre le nom redis.

Note: nous n'utilisons pas de FQDN ou une adresse IP ici; juste redis.

containers/Container_Network_Model.md

Démarrer la base de données

• Nous devons démarrer un container Redis.

• Ce container doit être sur le même réseau que le serveur web.

• Il doit porter le nom correct (redis) pour que l'application le trouve.

Démarrer le container;

$ docker run --net dev --name redis -d redis

containers/Container_Network_Model.md

Tester à nouveau le serveur web

• Si nous ouvrons l'application à présent, nous devrions voir que l'appli fonctionne correctement:

• Quand l'appli essaie de résoudre redis, au lieu d'avoir une erreur DNS, on récupère l'adresse IP de notre container Redis.

containers/Container_Network_Model.md

A propos du scope

• Et si nous voulions lancer plusieurs clones de notre application?

• Puisque les noms sont uniques, il ne peut y avoir qu'un seul container nommé redis.

• Toutefois, nous pouvons forcer un nom de réseau de notre container avec --net-alias.

• --net-alias a une portée par réseau, et indépendant du nom de container d'origine.

containers/Container_Network_Model.md

Bon à savoir...

• Docker ne peut créer des noms de réseau et alias sur le réseau par défaut bridge.

• Sachant ceci, pour utiliser ces fonctions, vous devez créer un réseau spécifique d'abord.

• Les alias de réseau ne sont pas uniques au sein d'un réseau donné.

• i.e plusieurs containers peuvent porter le même alias sur le même réseau.

• Dans ce scénario, le serveur DNS Docker retournera plusieurs enregistrements.
  (i.e, vous aurez un "DNS round robin" prêt à l'emploi)

• Activer le Mode Swarm donne accès au traitement distribué (clustering) et la répartition de charge (load balancing) via IPVS.

• Créer les réseaux et les alias de réseau est en général automatisé par des outils comme Compose.

containers/Container_Network_Model.md

Réseaux superposés (overlay)

• Les caractéristiques vues jusqu'ici fonctionnent uniquement quand les containers sont sur un seul hôte.

• Si les containers sont répartis sur plusieurs hôtes, nous aurons besoin d'un réseau overlay pour les connecter ensemble.

• Docker est livré avec un plugin de réseau par défaut, overlay, qui implémente un réseau superposé exploitant le concept de VXLAN, qui s'active via le Mode Swarm.

• D'autres plugins (Weave, Calico...) peuvent aussi fournir des réseaux superposés.

• Une fois que vous avez un réseau superposé, toutes les fonctions utilisées dans ce chapitre fonctionnent de la même manière à travers plusieurs hôtes.

containers/Container_Network_Model.md

Connexion et déconnexion dynamique

• Jusqu'ici, nous avons choisi quel réseau utiliser au démarrage du container.

• Le Docker Engine permet aussi la connexion/déconnexion pendant que le container tourne.

• Cette fonction est exposée via l'API Docker, et à travers deux commandes:

  • docker network connect <network> <container>

  • docker network disconnect <network> <container>

containers/Container_Network_Model.md

Connexion dynamique à un réseau

• Nous avons un container nommé es connecté à un réseau nommé dev.

• Démarrons un simple container alpine sur le réseau par défaut:

  $ docker run -ti alpine sh
  / #

• Dans ce container, essayons de ping le container es:

  / # ping es
  ping: bad address 'es'

Cela ne fonctionne pas, mais nous allons corriger cela en connectant le container.

containers/Container_Network_Model.md

Trouver l'ID du container et le connecter

• Extraire l'ID de notre container alpine; voici deux méthodes:

  • jeter un oeil à /etc/hostname dans le container,

  • exécuter sur le hôte docker ps -lq.

• Lancer la commande suivant sur l'hôte:

  $ docker network connect dev <container_id>

containers/Container_Network_Model.md

Vérifier nos actions

• Essayez encore ping es depuis le container.

• Cela devrait fonctionner correctement normalement:

  / # ping es
  PING es (172.20.0.3): 56 data bytes
  64 bytes from 172.20.0.3: seq=0 ttl=64 time=0.376 ms
  64 bytes from 172.20.0.3: seq=1 ttl=64 time=0.130 ms
  ^C

• Stoppez-le avec Ctrl-C.

containers/Container_Network_Model.md

Examen du réseau dans le container

Nous pouvons lister les interfaces réseau avec ifconfig, ip a, ou ip l:

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
18: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
20: eth1@if21: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:14:00:04 brd ff:ff:ff:ff:ff:ff
    inet 172.20.0.4/16 brd 172.20.255.255 scope global eth1
       valid_lft forever preferred_lft forever
/ #

Chaque connexion réseau est matérialisée via une interface réseau virtuelle.

Comme nous pouvons le voir, nous pouvons être connectés à plusieurs réseaux en même temps.

containers/Container_Network_Model.md

Se déconnecter d'un réseau

• Essayons ce que donne la commande symétrique pour déconnecter le container:

  $ docker network disconnect dev <container_id>

• A partir de maintenant, si on cherche à ping es, ce ne sera pas résolu:

  / # ping es
  ping: bad address 'es'

• Si on essaie de ping l'adresse IP directement, cela ne fonctionne plus non plus:

  / # ping 172.20.0.3
  ... (rien ne se passe jusqu'à ce qu'on tape Ctrl-C)

containers/Container_Network_Model.md

Objectifs

A la fin de cette section, vous serez capable de:

• Partager du code entre conteneur et hôte.

• Utiliser un processus de développement local simple.

containers/Local_Development_Workflow.md

Développement local dans un conteneur

On veut résoudre les problèmes suivants:

• "Ça marche sur ma machine"

• "Pas la même version"

• "Manque une dépendance"

En utilisant les conteneurs Docker, on arrivera à un environnement de développement homogène.

containers/Local_Development_Workflow.md

Travailler à l'application "namer"

• Nous avons à travailler sur une application dont le code est sur:

  https://github.com/jpetazzo/namer.

• De quoi s'agit-il? On ne le sait pas encore!

• Récupérons le code.

$ git clone https://github.com/jpetazzo/namer

containers/Local_Development_Workflow.md

Examiner le code

$ cd namer
$ ls -1
company_name_generator.rb
config.ru
docker-compose.yml
Dockerfile
Gemfile

Examiner le Dockerfile

FROM ruby
COPY . /src
WORKDIR /src
RUN bundler install
CMD ["rackup", "--host", "0.0.0.0"]
EXPOSE 9292

• Cette appli utilise l'image de base ruby.
• Le code est copié dans /src.
• Les dépendances sont installées avec bundler.
• L'application est lancée via rackup.
• Elle écoute sur le port 9292.

containers/Local_Development_Workflow.md

Générer et lancer l'application "namer"

• Générons l'application grâce au Dockerfile!

Accéder à notre application

• Pointez le navigateur sur le serveur Docker, et sur le port alloué au conteneur.

Amender le code

Option 1:

• Modifier le code en local
• Re-générer une image
• Relancer un conteneur

Option 2:

• S'introduire dans le conteneur (avec docker exec)
• Installer un éditeur
• Changer le code depuis l'intérieur du conteneur

Option 3:

• Utiliser un volume pour monter les fichiers locaux dans le conteneur
• Opérer les changements en local
• Constater les changements dans le conteneur

containers/Local_Development_Workflow.md

Notre premier volume

On va indiquer à Docker de monter le dossier en cours sur /src dans le conteneur.

$ docker run -d -v $(pwd):/src -P namer

• -d: le conteneur doit tourner en mode détaché (en arrière-plan).

• -v: le dossier du hôte mentionné doit être monté à l'intérieur du conteneur.

• -P: tous les ports exposés par cette image doivent être publiés.

• namer est le nom de l'image à exécuter.

• Nous n'ajoutons pas la commande à lancer car elle est déjà dans le Dockerfile avec CMD.

Note: sur Windows, remplacer $(pwd)par %cd% (ou ${pwd} avec PowerShell).

containers/Local_Development_Workflow.md

Monter les volumes dans des conteneurs

L'option -v monte un dossier depuis votre hôte dans le conteneur Docker.

La structure de l'option est:

[chemin-hote]:[chemin-conteneur]:[rw|ro]

• Si [chemin-hote] ou [chemin-conteneur] n'existe pas, il sera créé.

• Vous pouvez contrôler l'option d'écriture du volume avec les options ro et rw.

• Si vous ne spécifiez ni rw ou ro, ce sera rw par défaut.

Il y aura un chapitre complet sur les volumes!

containers/Local_Development_Workflow.md

Tester le conteneur de développement