Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Kubernetes
  3. Compilation et stockage d’images Docker
Extrait - Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (2e édition)
Extraits du livre
Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (2e édition)
1 avis
Revenir à la page d'achat du livre

Compilation et stockage d’images Docker

Objectifs du chapitre et prérequis

Ce chapitre est une introduction au mécanisme de compilation et au stockage d’image Docker dans un registre privé.

Une petite application sera créée afin de comprendre les étapes essentielles à la compilation d’une image ainsi que sur certaines astuces à appliquer dans le cas d’un programme réclamant une phase de compilation.

Viendront ensuite la présentation du mécanisme à utiliser pour la récupération d’image venant d’un registre privé ainsi que la présentation de quelques services managés.

Création d’une image Docker

1. Application d’exemple Flask HealthCheck

a. Présentation de l’application

Cette application sert d’exemple dans le chapitre Cycle de vie d’un container dans Kubernetes. Elle contient une page d’accueil ainsi que les points d’entrée suivants :

  • Affichage du contenu des variables d’environnements.

  • Affichage de l’état du container (healthcheck).

Son contenu étant relativement simple, cette application servira à présenter les mécanismes de compilation à mettre en œuvre pour créer une image de container ainsi qu’un exemple d’intégration dans Kubernetes.

b. Présentation des dépendances

L’application sera écrite à l’aide du framework Flask (bibliothèque Python).

L’application en elle-même sera composée des parties suivantes :

  • Import des dépendances.

  • Initialisation de l’application.

  • Exposition de l’état de santé du container et affichage des variables d’environnements.

  • Affichage d’un message d’accueil à la racine.

c. Description des dépendances

Le programme s’appuie sur Flask. Il s’agit d’une bibliothèque Python très légère permettant la création de sites web.

Le contrôle de l’état du container se fera à l’aide de la fonction HealthCheck de la librairie healthcheck.

Afin de pouvoir contrôler l’environnement d’exécution du programme, la fonction EnvironmentDump (toujours dans la librairie healthcheck) sera également importée.

Ci-dessous le code Python permettant de réaliser ces imports :

from flask import Flask 
from healthcheck import HealthCheck, EnvironmentDump 

d. Installation des dépendances

Les dépendances Python sont stockées dans un fichier texte. Ci-dessous le contenu de ce fichier :

Flask 
healthcheck 
six 

 Sauvegardez ce contenu sous le nom requirements.txt.

L’installation se fera à l’aide de la commande suivante :

$ sudo -H pip3 install -r requirements.txt 

Remplacez la commande pip3 par pip si votre poste ne dispose que de la version 3 de Python.

e. Initialisation de l’application

Pour l’essentiel, l’initialisation...

Image Docker multi-étape (multi-stage)

1. Origine du besoin

Dans le cas d’une application simple comme celle présentée (Python + Flask), le fichier Dockerfile n’a pas besoin d’être particulièrement complexe. En effet, il n’y a aucune compilation et la copie des fichiers suffit.

En revanche, lorsqu’une compilation est requise, la situation est plus complexe. Pour contourner ce problème, vous pouvez faire appel aux solutions suivantes :

  • Installer puis compiler le programme dans l’image.

  • Compiler le programme en dehors de l’image.

La première solution pose problème puisque l’image résultante sera plus grosse et contiendra des outils de compilation. De manière générale, il est déconseillé de laisser ce type d’outils dans l’image du container puisque leur présence peut entraîner des problèmes de sécurité.

La seconde solution pose également problème étant donné que la génération du programme n’est pas gérée par Docker, mais par une entité externe (une usine logicielle Jenkins, Gitlab, etc.).

La réponse à ces deux problèmes est de passer par une image multi-étape. Ces images utilisent plusieurs images sources (une pour la compilation et une pour le lancement du programme) et sont référencées...

Analyse d’images

1. Historique des commandes

Un bon moyen d’analyser le contenu d’une image est de récupérer l’historique des instructions utilisées pour construire l’image. Cet historique se récupère à l’aide de la commande docker suivie des éléments suivants :

  • Le mot-clé history.

  • Le nom de l’image à analyser.

Ci-dessous l’historique de l’image docker.io/yannig/flask-healthcheck:v1 :

$ docker history docker.io/yannig/flask-healthcheck:v1 

Cette commande renverra le contenu suivant :

IMAGE        CREATED      CREATED BY                       ... 
f78d6979355e 2 hours ago  /bin/sh -c #(nop)  CMD ["run" "--... 
c31b1d411468 2 hours ago  /bin/sh -c #(nop)  ENTRYPOINT ["f... 
8d2e89c71994 2 hours ago  /bin/sh -c #(nop) COPY dir:98a0fa... 
... 

2. Analyse de l’image : Dive

a. Présentation de Dive

Dive est un outil intéressant pour analyser le contenu d’une image. Ce dernier permet de récupérer l’historique de l’image, mais également - pour chaque modification - la liste des fichiers présents.

Pour en savoir plus sur ce logiciel, consultez l’adresse suivante : https://github.com/wagoodman/dive

b. Installation de Dive...

Utilisation de registres Docker privés

1. Origine du besoin

Dans les exemples précédents, le stockage des images s’est fait sur un registre public (Docker Hub). Pour différentes raisons, le développement d’une application peut avoir besoin de se faire dans un contexte confidentiel (sécurité, développement propriétaire, etc.).

Dans pareil cas, il est impératif de faire appel à un registre privé. Ces registres privés peuvent être hébergés par un acteur tiers (Google, Azure ou Amazon offrent ce type de service) ou sur un registre d’images interne.

La procédure de mise à jour d’image sur un registre privé n’est pas différente de celle à utiliser sur un registre public. La différence se fera au niveau de la récupération de l’image sur le cluster.

2. Déploiement d’image d’un registre privé

a. Exposition de la problématique

L’image est publiée, mais comme cette dernière n’est pas publique, Kubernetes va devoir disposer d’un compte pour pouvoir la récupérer.

Ce compte se présente sous la forme suivante :

  • Un identifiant (ex. : my-pull-user).

  • Un mot de passe.

  • Une adresse de registre (ex. : registry.gitlab.com/my-company).

b. Création du secret

À l’aide de ces informations, il est possible de créer un secret de type docker-registry à l’aide de la commande kubectl et des options suivantes :

  • L’action create suivie du type (secret).

  • Le type de secret à créer (docker-registry) suivi de son nom.

  • L’option --docker-server suivie de l’adresse du registre.

  • L’option --docker-username suivie d’un identifiant de connexion.

  • L’option --docker-password suivie du mot de passe.

Un secret fait partie d’un espace de noms. Ne pas oublier de spécifier ce dernier à l’aide de l’option --namespace s’il doit être utilisé dans un autre espace que celui par défaut.

Ci-dessous un exemple de création du secret my-docker-registry-cred dans l’espace de noms my-namespace :

$ kubectl create secret docker-registry my-docker-registry-cred \ 
  --docker-server=registry.gitlab.com/my-company \ 
  --namespace=my-namespace \ ...