Construction d'une image docker pour diagnostic au sein d'un POD Kubernetes

Introduction sur les images docker publique

Les images docker que certains éditeurs proposent pour leur solution logiciel sont souvent très optimisés. Ils construisent une image avec uniquement le nécessaire au bon fonctionnement de leur application.

C’est une très bonne approche puisque cela permet d’avoir des images les plus légères et sécurisés possible.

 

L’inconvénient peut être que dans le cas de debug ou d’analyse avancée, les outils classiques de dépannage tel que la commande ping, curl , telnet ou autres ne sont pas disponibles depuis l’image.

 

Il n’y a également souvent pas de shell qui pourrait permettre d’ouvrir une session interactive dans le contexte du conteneur.

 

Beaucoup de solutions sont possibles pour pallier à ce problème, de mon côté, j’utilise souvent une petite image diag que je peux associer si nécessaire à mes pods pour pouvoir faire des tests depuis le même contexte que les autres images déployées par le pod.

 

Je vous propose donc juste de partager mon image avec vous et d’en profiter pour donner un exemple de création d’une image docker.

 

Comme d’habitude je suis partie d’un tutorial qui me permet aujourd’hui d’avoir toujours la même logique dans la création de mes images

 

Création d'une image docker

 

Organisation et composants nécessaires pour la création de l'image

Je commence par créer une arboresence de travail:

Usage de docker-compose

Comme vous pouvez le constater j'utilise l’outil « docker-compose » pour faciliter la description de mon image.

J’ai donc toujours un fichier docker-compose.yml avec le contenu minimal suivant:

    version: '3.3'
    services:
        coolcorp:
            build:
                context: ./docker
                args:
                    VERSION: ${VERSION}
            hostname: diag

coolcorp va être le nom de mon service avec comme hostname de mon image diag. Je charge les variables d’environnement si nécessaire en les listant dans « args »

J’indique que la description de mon image est dans le sous-répertoire docker

 

Fichier Dockerfile

C’est dans ce répertoire que j’ai mon fichier Dockerfile qui décrit la construction de mon image dont voici le contenu:

 

FROM ubuntu:19.10
          
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
nano \
sudo \
openssh-server \
net-tools \
wget \
curl \
vim \
iputils-ping \
telnet

COPY files/consul /usr/local/bin/consul
RUN chmod +x /usr/local/bin/consul

COPY files/entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chmod +x /usr/local/bin/entrypoint.sh
     
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]
     
CMD tail -f /dev/null

 Dans le cas de l’image « diag », sa construction est très simpliste. Je pars d’une image d’Ubuntu puis j’y ajoute un certain nombre de packages pouvant être utile pour faire des diagnostics.

J’ajoute des binaires supplémentaires comme consul par exemple.Enfin, j’ajoute l’entrypoint.sh qui est un script que j’ai repris du tutorial que j’ai suivi.

#!/bin/bash
set -e
     
printf "\n\033[0;44m---> Starting the SSH server.\033[0m\n"
     
service ssh start
service ssh status
     
exec "$@"

Il permet de lancer le service SSH.

Cette entrypoint n’est qu’une excuse pour maintenir en vie mon conteneur. En effet, un conteneur n’existe que le temps où l’application qu’il fait tourner est active. Si le processus associé est stopper, alors le conteneur s’arrête.

 

Pour mon image de diag, le service SSH est le processus du conteneur, le laissant ainsi tourner, je peux ouvrir une session interactive sur le conteneur et travailler comme je le souhaite dans son contexte d’exécution.

 

Génération de l'image

Il me suffit ensuite de générer l’image avec la commande docker-compose build depuis la racine de mon dossier de travail.

 

 

Tag de l'image et publication

Je peux ensuite tagger l’image et l’envoyer sur ma registry pour qu’elle puisse être appelée par mes pods si nécessaires.