Pourquoi fabriquer son image OCI au lieu de se baser une image dockerhub ?
Table of Contents
Le titre de l’article est une question que je me suis poser dès lors que j’ai commencé à me servir de l’environnement Docker (Docker pull, stack docker compose et tout le tralala).
Quand est-ce qu’il faut se servir dans la liste longue comme le bras de Docker Hub ou alors passé du temps à écrire son propre Dockerfile pour chacun de ses modules de son projet ?
Note : Je trouve cela intéressant de voir que par défaut si vous faite un docker pull nginx, si vous n’avez pas d’image nommé “nginx” en local alors docker va aller chercher ce nom dans docker hub.
Ce comportement ne permet pas selon moi de montrer aux utilisateurs de docker à qu’elle point cela peut être dangereux. Il pousse à une consommation d’images sans réflexion critique, ce qui peut mener (et mène !) à des problèmes de sécurité.
Les différents type d’image sur DockerHub
Docker Official Image
« Docker Official Images are a curated set of Docker open source and “drop-in” solution repositories. »
- Docker Hub
Ces images sont publiées et maintenues directement par l’entreprise Docker. Elles sont le fruit d’une collaboration entre Docker, les mainteneurs de logiciels open source en amont, et la communauté dans certains cas.
Elles sont généralement considérées comme le point de départ par défaut pour les utilisateurs, car elles sont bien documentées, régulièrement mises à jour et suivent les meilleures pratiques de l’industrie.
Quelques exemples notables:
Dans quel cas les utiliser ?
Utilisez les Docker Official Images comme premier choix pour la plupart des projets, surtout si vous cherchez une base fiable, sécurisée et bien maintenue pour une application ou un langage de programmation courant. C’est le standard de l’industrie, idéal pour la production.
Verified Publisher
« High-quality images from publishers verified by Docker. These products are published and maintained directly by a commercial entity. These images are not subject to rate limiting. »
- Docker Hub
Les images “Verified Publisher” proviennent d’éditeurs commerciaux qui ont été vérifiés par Docker.
Quelques exemples notables:
- grafana/grafana
- cAdvisor de Google
- portainer-ce
Dans quel cas les utiliser ?
Choisissez pour les images Verified Publisher lorsque vous souhaitez utiliser un produit commercial ou open source spécifique, maintenu directement par l’entreprise qui le développe (comme Grafana ou Portainer). Vous avez la garantie que l’image est officiellement supportée, qu’elle est à jour et qu’elle respecte les standards de qualité de l’éditeur. Généralement les entreprises son fièrent d’avoir cette médaille, vous le saurez rapidement si le soft que vous voulez tester dans cette catégorie.
Sponsored OSS
« Docker-Sponsored Open Source Software. These are images published and maintained by open-source projects that are sponsored by Docker through our open source program. »
- Docker Hub
Docker paye les mainteneurs de ces projets pour continuer à développer, maintenir et publier régulièrement ces images.
Un excellent de éditeur d’image open-source vérifié est LinuxServer.io. Ce groupe de développeurs maintient une large collection d’images Docker pour des applications de serveur, axées sur le self-hosting. Ces images peuvent être un bon point de départ pour tester ou déployer un logiciel rapidement.
Cependant !
Bien que ces images soient considérées comme fiables, il est essentiel de se rappeler que, dans la plupart des cas, la chaîne d’approvisionnement logicielle (ou software supply chain de nos amis Anglais) reste vulnérable. Chaque image est construite sur une base, qui elle-même est construite sur une autre, créant un arbre de dépendances complexe. Évitons les problèmes comme avec les failles récentes sur NPM du coté de nos très chère dev. web.
Et c’est justement dans ce cas qu’on peut se poser la question : “Pourquoi fabriquer ses images au lieu de se baser des images dockerhub ?”
Fabrication de ses images
Construire ses propres images Docker peut paraître fastidieux, mais cela apporte un contrôle bien plus fin sur ce qui tourne réellement dans nos infrastructures. En repartant d’une base minimale (par exemple alpine, debian:slim ou même scratch) on peut facilement créer une base solide pour déployer un logiciel.
Construire ses images pour un usage interne
Ici, l’objectif est maîtrise et sécurité. On fabrique nos propres images, uniquement destinées à notre SI.
Construire ses images pour rendre public son logiciel
Quand un soft est distribué à l’extérieur (open source ou produit commercial), les enjeux changent:
- Un grand besoin en accessibilité : rendre ses images disponible sur Docker Hub avec les architectures x86 et ARM64.
Les images officielles de docker hub contiennent généralement plus d’une dizaine de tags différents représentant :
Principalement: la version du logiciel
Exemple: python:**3** alpine:**3.21** debian:**12** node:**jod**
Le système d’exploitation (si ce n’est pas un OS lui-même)
Exemple: python:3-**alpine** node:22-**bookworm** python:3.13.3-**windowsservercore-1809**
D’autres informations secondaire (comme un add-on)
Exemple: nginx:1.27.5-bookworm**-perl**
Tout ceci n’est qu’une convention /!
Toutes les images officielles docker l’utilise mais cela reste dépendant de l’éditeur de l’image.