Pourquoi construire ses propres images
Fondamental : Le Docker Hub
Le Docker Hub est un marché ou l'on peut télécharger gratuitement tout type d'image Docker.
On y retrouve différents types d'images :
Les images officielles
Les images vérifiées
Les images d'utilisateurs
Exemple : Les images officielles
Les images officielles sont des images qui sont créées par les équipes de Docker. On y retrouve un catalogue de produits ou de distributions open sources. Ces images sont mises à jour régulièrement et sont considérées comme dignes de confiance. |  |
Exemple : Les images vérifiées
Les images vérifiées sont issues de personnes ou d'organisation vérifiées par Docker. Ces images sont publiées et maintenues par une organisation commerciale. Lorsqu'un utilisateur souhaite bénéficier du support commercial de son produit, il doit utiliser ces images. Elles sont mises à jour régulièrement et peuvent être considérées comme étant dignes de confiance. |  |
Remarque :
Les images officielles et les images vérifiées sont construites automatiquement et les sources sont disponibles pour les utilisateurs. Il est donc possible de voir ce que contiennent ces images et comment elles fonctionnent et même y contribuer pour les améliorer.
Exemple : Les images d'utilisateurs
Le Docker Hub peut aussi héberger les images de n'importe quel utilisateur. Ces images sont à utiliser avec précaution. En effet, contrairement aux deux autres types d'images, les sources des images ne sont pas obligatoirement publiées. De la même manière, les images ne sont pas toujours mises à jour. Il faut donc être très prudent lors du choix de ses images. Utiliser ce genre peut être risqué. Un utilisateur malveillant peut par exemple cacher dans une image a priori inoffensive un programme qui va dérober les données des utilisateurs ou encore miner des cryptomonnaies en utilisant votre puissance de calcul. Les images d'utilisateurs du Docker Hub ne sont soumises à aucun test de sécurité ou test fonctionnels. Il est par exemple possible d'envoyer sur le Docker Hub une image s'appelant "hacker/postgresql" qui contient en réalité une porte dérobée pour prendre le contrôle du serveur de l'utilisateur. Entre 2017 et 2018, Docker a supprimé 17 images du Docker Hub contenant des programmes malicieux. Ces images ont été utilisées par des millions d'utilisateurs. Il a fallu pas moins d'un an pour que les premiers chercheurs en sécurité alertent les utilisateurs sur la dangerosité de ces images. Aujourd'hui encore certains serveurs sont toujours infectés même après avoir supprimé les conteneurs infectés. |  |
Remarque :
Le Docker Hub n'est pas l'unique endroit où l'on peut récupérer des images. Il est tout à fait possible d'avoir son propre système d'hébergement d'image ou d'utiliser des systèmes tiers comme quay.io
Image VS Conteneur
Avant de rentrer dans le vif du sujet, quelques éléments de vocabulaire qui vont nous aider à nous y retrouver
Fondamental : Image Docker
Une image Docker est un ensemble de fichiers constituant une application. Cette collection comprend l'application elle-même, ainsi que toutes les bibliothèques (libraries), les fichiers binaires et d'autres dépendances, telles que les fichiers de configurations, nécessaires à l'exécution de l'application.
Lorsque l'on construit une nouvelle image, on se rend compte que tous les fichiers contenus dans l'image Docker sont en lecture seule et par conséquent, le contenu de l'image ne peut pas être modifié. Si vous choisissez de modifier le contenu de votre image, la seule option permise par Docker est d'ajouter une autre couche (un layer) avec les nouvelles modifications. En d'autres termes, une image Docker est composée layers que vous pouvez réviser. La commande docker history, permet de lister tous ces layers et de savoir ce qu'ils contiennent.
~ docker history mon-conteneur
IMAGE CREATED CREATED BY SIZE COMMENT
3e12e812ffba 3 days ago bash 19B
de8b49d4b0b3 2 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 2 weeks ago /bin/sh -c #(nop) ADD file:da71baf0d22cb2ede... 101MB
L'architecture des images Docker tire efficacement parti de ce concept de superposition pour ajouter de manière transparente des fonctionnalités supplémentaires aux images existantes. Ce système permet également de mutualiser certains layers et ainsi de réutiliser les layers identiques entre plusieurs images.
En d'autres termes, des fonctionnalités peuvent être ajoutées aux images existantes en ajoutant des layers supplémentaires par-dessus une image existante donnant naissance à une nouvelle image.
Les images Docker ont une relation parent-enfant et l'image la plus basse est appelée image de base. L'image de base est une image spéciale sans parent.
Exemple :
L'image Debian Docker est un ensemble minimaliste de librairies et de fichiers binaires essentiels à l'exécution d'une application. Il n'inclut pas le noyau Linux (le kernel), les pilotes de périphériques et divers autres services fournis par un système d'exploitation de la machine hôte. |  |
Comme vous pouvez le voir dans la figure ci-contre, on utilise une image de base. Dans cet exemple, il s'agit de Debian. Dans un premier layer, on ajoute le paquet Chaque ajout apporté à l'image de base d'origine est stocké dans un layer séparé. La construction d'une image donne naissance à un identifiant unique qui regroupe tous les layers et qu'il est ensuite possible de partager au travers d'un registre comme le Docker Hub |  |
Fondamental : Conteneur Docker
Les images Docker sont donc des modèles d'application composés de layer et qui sont en lecture seule.
Le conteneur Docker est dérivé de l'image Docker auquel il ajoute un layer de lecture-écriture au-dessus des layers d'image statiques. En programmation-objet, on pourrait comparer l'image a une classe alors qu'un conteneur est une instance de cette classe.
L'image Docker définit le comportement du conteneur Docker, par exemple le processus à exécuter lors du démarrage du conteneur. Ce sont les images Docker qui vont par la suite définir le comportement du conteneur une fois lancé. Comme l'illustre la figure ci-contre, lorsque le conteneur est créé, un layer en écriture (lecture-écriture) est ajoutée au-dessus de l'image afin de conserver l'état de l'application. Il pourrait y avoir plusieurs images en lecture seule sous la couche conteneur (en écriture). |  |
Remarque : Réutilisation des layers et cache
Docker possède un système intelligent de cache qui est en mesure d'utiliser des layers déjà existant si les instructions ainsi que les images de base sont les mêmes.
Ce principe permet de limiter la taille des images sur les registy en utilisant au maximum la déduplication. Il permet également d'accélérer le build des images en ne rejouant pas systématiquement les actions des layers lors de la construction des images.
Exercice
De quoi est composée une image Docker
Un conteneur
Une image de base
De layers en lecture seule
Un volume
Peut-on écrire dans un layer d'une image après sa construction
oui
non
Quelle commande permet de lister les layers d'une image
docker layers ls <mon_image>
docker history <mon_image>
docker inspect <mon_image>
docker describe <mon_image>
Un conteneur est une instance d'une image
Oui
Non
Lorsque j'execute un conteneur il est possible d'écrire à l'intérieur
Oui
Non
Le processus de construction des images est optimisé avec l'utilisation de :
cache
mutualisation de layers
utilisation de conteneurs
d'images de base
De quoi est composée une image Docker
Un conteneur
Une image de base
De layers en lecture seule
Un volume
Un conteneur
Un conteneur est une instance d'une image
Une image de base
Chaque image Docker se repose sur une image de base qui est ensuite enrichie
De layers en lecture seule
Chaque instruction d'une image va être stockée dans un layer qu'il ne sera pas possible d'éditer
Un volume
Un volume représente un emplacement de stockage partagé entre un conteneur et la machine docker
Peut-on écrire dans un layer d'une image après sa construction
oui
non
Une fois construit, il n'est plus possible de modifier le contenu d'un layer d'une image. Si l'on souhaite éditer son contenu, on doit ajouter un layer supplémentaire à l'image et effectuer les modifications dans ce nouveau layer.
Quelle commande permet de lister les layers d'une image
docker layers ls <mon_image>
docker history <mon_image>
docker inspect <mon_image>
docker describe <mon_image>
Un conteneur est une instance d'une image
Oui
Non
Un conteneur dérive d'une image. Lorsqu'il est exécuté, il va lancer les instructions contenues au sein de l'image.
Lorsque j'execute un conteneur il est possible d'écrire à l'intérieur
Oui
Non
Lorsqu'un conteneur est lancé, un nouveau layer est ajouté à celui de l'image de laquelle il découle. Ce layer a la particularité d'être en lecture et en écriture ce qui permet à l'utilisateur de pouvoir ajouter ou modifier des fichiers dans le conteneur. | |
Le processus de construction des images est optimisé avec l'utilisation de :
cache
mutualisation de layers
utilisation de conteneurs
d'images de base
cache
Lorsque des layers ont déjà été construits, Docker ne va pas systématiquement les reconstruire et va réutiliser les layer existant pour la construction de nouvelles images
mutualisation de layers
Si deux images ayant la même image parente effectuent les mêmes actions, le layer reprenant ces actions sera le même au sein des deux images
utilisation de conteneurs
Les conteneurs ne sont pas utilisés dans le processus de build d'une image
d'images de base
L'utilisation de l'image de base n'optimise pas la construction de l'image
Conteneur Nginx
Exercice
L'objectif de cet exercice est de créer votre propre conteneur Docker Nginx personnalisé. Pour cela, nous allons dans un premier temps construire notre propre image Nginx puis dans un second temps la personnaliser en y ajoutant un le contenu d'un site web
Construisez une image Nginx en se basant sur l'image de base de debian en version stretch
L'instruction FROM permet de sélectionner l'image de base
Il est nécessaire de modifier le fichier /etc/nginx/nginx.conf pour faire fonctionner nginx dans un conteneur.
daemon off;user www-data;worker_processes 1;error_log stderr error;events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; access_log stdout; server { listen 80; root /var/www/html; index index.php index.html index.htm index.nginx-debian.html; client_max_body_size 100M; client_body_buffer_size 128k; location ~ /\.ht { deny all; } location ~ /(data|conf|bin|inc|config|lib)/ { deny all; } }}On utilise l'instruction COPY pour remplacer le fichier.
Pour lancer nginx, on utilise la commande /usr/sbin/nginx
FROM debian:stretch
RUN apt-get update && \
apt-get install -y nginxCOPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80CMD ["/usr/sbin/nginx"]docker build -t nginx .On peut maintenant lancer notre nouvelle image et vérifier son bon fonctionnement
On peut maintenant ouvrir son navigateur à l'adresse http://127.0.0.1:80 et vérifier que l'on a bien accès à la page d'accueil d'nginx |  |
Nous avons développé une nouvelle application web que nous souhaitons héberger dans notre conteneur nginx. https://github.com/abarbare/api-run-app
Faites un nouveau Dockerfile utilisant en image de base l'image Nginx que nous venons de construire
Vous pouvez télécharger l'application sur votre ordinateur puis la copier dans le conteneur. Il est aussi possible de télécharger l'app directement dans votre Dockerfile à l'aide de la commande git
L'application est à ajouter dans le dossier /var/www/html.
Les fichiers de l'application doivent appartenir à l'utilisateur www-data:www-data
FROM nginx
COPY --chown=www-data:www-data api-run-app/ /var/www/html/
FROM nginx
ARG APP=https://github.com/abarbare/api-run-app.git
RUN apt-get update && \
apt-get install -y git && \
rm -Rf /var/www/html/ && \
git clone $APP /var/www/html/ && \
chown -R www-data:www-data /var/www/html/
L'utilisation de la directive ARG permet de construire une image différente sans avoir à modifier le Dockerfile. Si l'on souhaite construire une image pour une application similaire https://github.com/abarbare/ansible-meetup-app il suffit de construire l'image avec la commande suivante
docker build -t mon-app --build-arg APP=https://github.com/abarbare/ansible-meetup-app.git .
On peut maintenant ouvrir son navigateur à l'adresse http://127.0.0.1:80 et vérifier que l'on a bien accès à notre application |  |