¶ Introduction
Comment construisez-vous des images de conteneur localement ? La réponse est très probablement que vous exécutez des commandes comme :
$ docker image build [OPTIONS] PATH | URL | -
Mais passons au cluster et voyons comment construire des images de conteneurs à l’intérieur des clusters Kubernetes dans le cadre de votre pipeline d’intégration continue ou de tout autre processus. Parce que n’oubliez pas que nous déplaçons la plupart des choses vers Kubernetes et cela s’applique à la création d’images de conteneurs.
Au sein des clusters Kubernetes, Docker est une mauvaise option car il ne peut pas fonctionner à l’intérieur des conteneurs. L’utilisation de Docker pour créer des images dans des conteneurs ou dans des clusters Kubernetes nécessite une communication avec le moteur Docker qui fonctionne dans les nœuds du cluster. Et cela pose un gros problème de sécurité.
Mais si ce problème de sécurité n’est pas suffisant, Dockershim, le responsable de la communication entre Kubernetes et Docker, est déprécié dans Kubernetes v1.20. Et bientôt, selon le moment où vous lirez ce blog, il sera supprimé de Kubernetes. Donc, même si vous êtes d’accord pour exécuter Docker à l’intérieur des conteneurs, même s’il ne s’agit que d’un client qui communique avec le moteur Docker fonctionnant sur le nœud et qui effectue la communication par le biais de sockets et toutes ces folies, même si vous êtes d’accord avec tout cela, ce qui ne devrait pas être le cas, sous quelque forme que ce soit, Docker sera supprimé, maintenant qu’il est déprécié, des clusters Kubernetes. Cela signifie que vous devrez utiliser d’autres moteurs de conteneurs, puisqu’il n’y aura plus de Docker.
Avant de plonger dans Kaniko, il est crucial de clarifier brièvement ce qu’est un conteneur dans l’industrie du logiciel.
Dans la couche applicative, les conteneurs sont une abstraction où le code et les dépendances sont construits ou emballés ensemble. Il s’agit d’une pièce de logiciel que vous pouvez utiliser pour envelopper votre processus logiciel ou microservice et le rendre exécutable dans n’importe quel environnement informatique. D’une manière générale, les conteneurs peuvent être utilisés pour contenir tout type de fichier exécutable, y compris les fichiers de configuration, les bibliothèques, le code et les fichiers binaires.
Sur un même système, plusieurs conteneurs peuvent être en cours d’exécution. Chaque instance de conteneur s’exécute comme un processus distinct tout en partageant le noyau du système d’exploitation avec d’autres conteneurs. Une application ou un microservice type est déployé pour être utilisé via la plate-forme de conteneurs après avoir été emballé dans une image de conteneur.
En outre, une image de conteneur est le code, le moteur d’exécution, les outils système, les bibliothèques et les paramètres d’une application, tous regroupés dans un paquet exécutable léger et indépendant.
¶ Qu’est-ce que Kaniko ?
Kaniko est un constructeur d’images de conteneurs sans démon qui permet aux utilisateurs de construire des images de conteneurs, à l’intérieur d’un conteneur ou d’un cluster Kubernetes. Comme Kaniko ne dépend pas du démon Docker, il crée des images de conteneurs dans le cluster Kubernetes dans l’espace utilisateur sans utiliser le démon Docker. Il s’agit d’un projet initié par Google pour supprimer la nécessité de disposer de privilèges élevés lors de la création d’images de conteneurs.
¶ Pourquoi Kaniko ?
Vous ne devriez pas construire d’images de conteneurs sur Docker à l’intérieur de clusters Kubernetes et même si vous m’ignorez et que vous dites que vous dites n’importe quoi, que ferez-vous lorsque Docker disparaîtra de Kubernetes ? Donc, vous devez chercher une méthode alternative pour construire des images car Docker ne sera plus une option dans Kubernetes.
Quelles sont les alternatives ?
Il existe plus de 10 alternatives viables, mais aujourd’hui nous allons parler de celle que j’aime le plus et qui s’appelle Kaniko.
Il s’agit d’un outil permettant de créer des images de conteneurs à partir d’un fichier Docker, comme le fait Docker, mais la principale différence est que Kaniko peut fonctionner à l’intérieur des conteneurs, ce qui signifie qu’il peut fonctionner à l’intérieur des clusters Kubernetes. Il n’y a pas besoin de mode privilégié ni d’exposer des sockets. Il n’est pas nécessaire d’exécuter Docker sur les nœuds de notre cluster, car le moteur de conteneurs que nous utilisons pour exécuter les conteneurs n’a pas vraiment d’importance. Ce qui importe, c’est que Kaniko peut créer des images de conteneurs à l’intérieur des conteneurs et automatiquement à l’intérieur des clusters Kubernetes.
Maintenant, explorons le fonctionnement de Kaniko à l’aide d’une démonstration pratique.
¶ Comment fonctionne Kaniko ?
Creusons dans les entrailles de Kaniko et explorons comment Kaniko lance les conteneurs.
Le système de fichiers de l’image de base est extrait dans un répertoire local (par exemple, /kaniko/imagename) par Kaniko une fois qu’il a analysé le Dockerfile et récupéré l’image de base. Les commandes contenues dans le fichier Docker sont ensuite traduites en commandes shell et utilisées pour construire plusieurs étapes. En effectuant ces actions, Kaniko modifie directement le système de fichiers local. Cela ne présente aucun problème car Kaniko est conçu pour s’exécuter dans un conteneur déjà existant, mais s’il devait s’exécuter depuis un hôte, les choses pourraient mal se passer.
La procédure consistant à prendre un instantané, à compiler les fichiers de modification dans une archive tarball et à ajouter des fichiers à une carte de couches ou à un voile blanc a alors lieu. Kaniko utilise un algorithme de hachage qui incorpore le temps de modification du fichier (mtime) pour détecter si les fichiers ont été modifiés.
Kaniko nécessite les instructions suivantes pour construire une image Docker :
- Chemin d’accès au Dockerfile
- Chemin d’accès au contexte de construction
- URL/destination du dépôt où l’image sera poussée.
Conditions préalables :
- Cluster Kubernetes
- Compte Dockerhub
- Fichiers de configuration (pod.yaml, volume.yaml, volume-claim.yaml)
¶ Démonstration
¶ Étape 1
Préparer le répertoire local monté et y créer un Dockerfile simple
FROM alpine:3.16
ENTRYPOINT ["/bin/sh", "-c", "echo hello"]
$ pwd
/home/<user-name>/kaniko # copy this path in volume.yaml file
¶ Étape 2
Pour s’authentifier avec le registre de Docker, créez un secret nommé « regcred ».
kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
¶ Étape 3
Creer la ressource:
# create persistent volume
$ kubectl create -f volume.yaml
persistentvolume/dockerfile created# create persistent volume claim
$ kubectl create -f volume-claim.yaml
persistentvolumeclaim/dockerfile-claim created# check whether the volume mounted correctly
$ kubectl get pv dockerfile
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
dockerfile 10Gi RWO Retain Bound default/dockerfile-claim local-storage 1m# create pod
$ kubectl create -f pod.yaml
pod/kaniko created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
kaniko 0/1 ContainerCreating 0 7s# check whether the build complete and show the build logs
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
kaniko 0/1 Completed 0 34s
$ kubectl logs kaniko
➜ kubectl logs kaniko
INFO[0000] Resolved base name ubuntu to ubuntu
INFO[0000] Resolved base name ubuntu to ubuntu
INFO[0000] Downloading base image ubuntu
INFO[0000] Error while retrieving image from cache: getting file info: stat /cache/sha256:1bbdea4846231d91cce6c7ff3907d26fca444fd6b7e3c282b90c7fe4251f9f86: no such file or directory
INFO[0000] Downloading base image ubuntu
INFO[0001] Built cross stage deps: map[]
INFO[0001] Downloading base image ubuntu
INFO[0001] Error while retrieving image from cache: getting file info: stat /cache/sha256:1bbdea4846231d91cce6c7ff3907d26fca444fd6b7e3c282b90c7fe4251f9f86: no such file or directory
INFO[0001] Downloading base image ubuntu
INFO[0001] Skipping unpacking as no commands require it.
INFO[0001] Taking snapshot of full filesystem...
INFO[0001] ENTRYPOINT ["/bin/bash", "-c", "echo hello"]
¶ Étape 4
Si vous avez suivi correctement les étapes mentionnées ci-dessus, une image sera construite par Kaniko et poussée vers Dockerhub. Tirez cette image de Dockerhub vers votre machine locale et exécutez-la pour la tester.
$ sudo docker run -it <user-name>/<repo-name>
Unable to find image 'debuggy/helloworld:latest' locally
latest: Pulling from debuggy/helloworld
5667fdb72017: Pull complete
d83811f270d5: Pull complete
ee671aafb583: Pull complete
7fc152dfb3a6: Pull complete
Digest: sha256:2707d17754ea99ce0cf15d84a7282ae746a44ff90928c2064755ee3b35c1057b
Status: Downloaded newer image for debuggy/helloworld:latest
hello
Félicitations ! Vous avez terminé avec succès la section « Hello World ». Pour plus d’informations, veuillez consulter le projet.
¶ Problèmes avec Kaniko
- Kaniko n’a pas le support de l’API de registre v1
- Kaniko ne supporte pas les conteneurs Windows
- En dehors de l’image officielle de Kaniko, l’exécution de Kaniko dans toute autre image Docker n’est pas prise en charge.
- Les performances de Kaniko peuvent être médiocres dans certains cas, car elle doit effectuer fréquemment des instantanés du fichier et aussi en raison de l’absence de mise en cache appropriée.
¶ Conclusion
Kaniko est l’un des nouveaux outils qui permet de créer des images de conteneurs dans un cluster Kubernetes et vise à éviter la dépendance de longue date envers le démon Docker. Il s’agit d’un outil efficace qui permet de créer en toute sécurité des images de conteneurs dans Kubernetes. Il accomplit efficacement cette tâche et offre à Kubernetes un outil fiable de développement d’images de conteneurs. Et il l’a fait sans le cauchemar de sécurité habituel qui accompagne la création d’images sur le démon.
La documentation officielle de Kaniko se trouve à l’adresse suivante