Découvrez comment Solomon Hykes et Docker ont popularisé les conteneurs, faisant des images, des Dockerfiles et des registries la manière standard d’empaqueter et déployer les applications modernes.
Solomon Hykes est l’ingénieur qui a aidé à transformer une idée ancienne — isoler le logiciel pour qu’il s’exécute de la même façon partout — en quelque chose que les équipes pouvaient réellement utiliser au quotidien. En 2013, le projet qu’il a présenté au monde est devenu Docker, et il a rapidement changé la façon dont les entreprises expédient des applications.
À l’époque, la douleur était simple et familière : une application fonctionnait sur l’ordinateur d’un développeur, puis se comportait différemment sur la machine d’un collègue, puis cassait à nouveau en staging ou en production. Ces « environnements incohérents » n’étaient pas seulement agaçants — ils ralentissaient les sorties, rendaient les bugs difficiles à reproduire et créaient d’innombrables transferts entre développement et exploitation.
Docker a donné aux équipes un moyen reproductible d’empaqueter une application avec les dépendances qu’elle attend — pour que l’application puisse s’exécuter de la même manière sur un portable, un serveur de test ou dans le cloud.
C’est pourquoi on dit que les conteneurs sont devenus « l’unité par défaut de packaging et de déploiement ». En termes simples :
Plutôt que de déployer « un fichier ZIP plus une page wiki d’instructions », beaucoup d’équipes déploient une image qui contient déjà ce dont l’application a besoin. Le résultat : moins de surprises et des sorties plus rapides et plus prévisibles.
Cet article mélange histoire et concepts pratiques. Vous apprendrez qui est Solomon Hykes dans ce contexte, ce que Docker a introduit au bon moment, et les mécanismes de base — sans supposer une connaissance approfondie de l’infrastructure.
Vous verrez aussi où les conteneurs s’insèrent aujourd’hui : comment ils se connectent aux workflows CI/CD et DevOps, pourquoi des outils d’orchestration comme Kubernetes sont devenus importants plus tard, et ce que les conteneurs ne résolvent pas automatiquement (notamment en matière de sécurité et de confiance).
À la fin, vous devriez pouvoir expliquer — clairement et avec assurance — pourquoi « ship it as a container » est devenu une hypothèse par défaut pour le déploiement d’applications modernes.
Avant que les conteneurs ne deviennent grand public, faire passer une application du portable d’un développeur à un serveur était souvent plus pénible que d’écrire l’application elle‑même. Les équipes ne manquaient pas de talent — elles manquaient d’un moyen fiable pour déplacer « la chose qui marche » entre environnements.
Un développeur pouvait exécuter parfaitement l’application sur son ordinateur, puis la voir échouer en staging ou en production. Pas parce que le code avait changé, mais parce que l’environnement l’avait fait. Différentes versions d’OS, des bibliothèques manquantes, des fichiers de configuration légèrement différents ou une base de données lancée avec d’autres paramètres pouvaient tous casser le même build.
Beaucoup de projets reposaient sur de longues instructions d’installation fragiles :
Même bien rédigés, ces guides vieillissaient vite. Un coéquipier mettant à jour une dépendance pouvait involontairement casser l’onboarding pour tout le monde.
Pire : deux applications sur le même serveur pouvaient nécessiter des versions incompatibles du même runtime ou d’une même bibliothèque, forçant des contournements maladroits ou des machines séparées.
« Packaging » signifiait souvent produire un ZIP, un tarball ou un installateur. « Déploiement » signifiait un autre ensemble de scripts et d’étapes serveur : provisionner une machine, la configurer, copier des fichiers, redémarrer des services, et espérer que rien d’autre sur le serveur ne soit impacté.
Ces deux préoccupations ne s’alignaient que rarement proprement. Le paquet ne décrivait pas complètement l’environnement nécessaire, et le processus de déploiement dépendait fortement du serveur cible étant « préparé correctement ».
Ce dont les équipes avaient besoin, c’était d’une unité unique et portable qui puisse voyager avec ses dépendances et s’exécuter de façon cohérente sur portables, serveurs de test et production. Cette pression — installation reproductible, moins de conflits et déploiement prévisible — a préparé le terrain pour que les conteneurs deviennent la méthode par défaut pour expédier des applications.
Docker n’est pas né d’un plan grandiose pour « changer le logiciel pour toujours ». Il a grandi à partir d’un travail d’ingénierie pragmatique mené par Solomon Hykes pendant la construction d’un produit de type platform-as-a-service. L’équipe avait besoin d’un moyen reproductible d’empaqueter et d’exécuter des applications sur différentes machines sans les habituelles surprises « ça marche sur ma machine ».
Avant que Docker ne soit un nom connu, le besoin sous‑jacent était simple : livrer une appli avec ses dépendances, l’exécuter de façon fiable, et recommencer pour de nombreux clients.
Le projet qui est devenu Docker a émergé comme une solution interne — quelque chose qui rendait les déploiements prédictibles et les environnements cohérents. Une fois que l’équipe a réalisé que ce mécanisme d’empaquetage et d’exécution était utile au‑delà de leur produit, ils l’ont publié.
Cette publication a compté parce qu’elle a transformé une technique privée de déploiement en une chaîne d’outils partagée que toute l’industrie pouvait adopter, améliorer et standardiser.
Il est facile de confondre les deux, mais ce sont des choses différentes :
Les conteneurs existaient sous diverses formes avant Docker. Ce qui a changé, c’est que Docker a emballé le flux de travail dans un ensemble de commandes et de conventions conviviales — construire une image, exécuter un conteneur, la partager.
Quelques étapes bien connues ont fait passer Docker de « intéressant » à « par défaut » :
Le résultat pratique : les développeurs ont arrêté de débattre sur la façon de reproduire les environnements et ont commencé à expédier la même unité exécutable partout.
Les conteneurs sont une façon d’empaqueter et d’exécuter une application pour qu’elle se comporte de la même manière sur votre portable, sur la machine d’un collègue et en production. L’idée clé est l’isolation sans un ordinateur complet.
Une machine virtuelle (VM) ressemble à la location d’un appartement entier : vous obtenez votre propre porte d’entrée, vos propres services et votre propre copie du système d’exploitation. C’est pourquoi les VM peuvent exécuter différents types d’OS côte à côte, mais elles sont plus lourdes et démarrent généralement plus lentement.
Un conteneur, c’est plutôt louer une chambre verrouillée dans un immeuble partagé : vous apportez vos meubles (code + librairies), mais les utilités de l’immeuble (le noyau de l’OS hôte) sont partagées. Vous obtenez une séparation par rapport aux autres chambres sans démarrer un OS complet à chaque fois.
Sur Linux, les conteneurs s’appuient sur des fonctionnalités d’isolation intégrées qui :
Vous n’avez pas besoin de connaître les détails du noyau pour utiliser des conteneurs, mais savoir qu’ils exploitent des fonctions OS aide à comprendre qu’il ne s’agit pas de magie.
Les conteneurs sont populaires parce qu’ils sont :
Les conteneurs ne constituent pas une frontière de sécurité par défaut. Parce qu’ils partagent le noyau de l’hôte, une vulnérabilité au niveau du noyau peut potentiellement affecter plusieurs conteneurs. Cela signifie aussi qu’on ne peut pas exécuter un conteneur Windows sur un noyau Linux (et vice versa) sans virtualisation supplémentaire.
Donc : les conteneurs améliorent l’empaquetage et la cohérence — mais il faut encore des pratiques solides de sécurité, de patching et de configuration.
Docker a réussi en partie parce qu’il a donné aux équipes un modèle mental simple avec des « parties » claires : un Dockerfile (instructions), une image (l’artéfact construit) et un conteneur (l’instance en cours d’exécution). Une fois cette chaîne comprise, le reste de l’écosystème Docker devient plus logique.
Un Dockerfile est un fichier texte qui décrit comment construire votre environnement d’application étape par étape. Pensez‑y comme une recette de cuisine : il ne nourrit personne en soi, mais il vous dit exactement comment produire le même plat à chaque fois.
Les étapes typiques incluent : choisir une base (runtime), copier votre code, installer les dépendances et déclarer la commande à exécuter.
Une image est le résultat bâti d’un Dockerfile. C’est un instantané empaqueté de tout ce dont on a besoin pour exécuter : votre code, les dépendances et des valeurs par défaut de configuration. Ce n’est pas “vivant” — c’est plutôt une boîte scellée que l’on peut expédier.
Un conteneur est ce que vous obtenez quand vous exécutez une image. C’est un processus vivant avec son propre système de fichiers isolé et ses paramètres. Vous pouvez le démarrer, l’arrêter, le redémarrer et créer plusieurs conteneurs à partir de la même image.
Les images sont construites en couches. Chaque instruction d’un Dockerfile crée généralement une nouvelle couche, et Docker tente de réutiliser (« cacher ») les couches qui n’ont pas changé.
En clair : si vous ne changez que votre code applicatif, Docker peut souvent réutiliser les couches qui ont installé les paquets système et dépendances, rendant les reconstructions beaucoup plus rapides. Cela encourage aussi la réutilisation entre projets — beaucoup d’images partagent des couches de base communes.
Voici à quoi ressemble le flux « recette → artéfact → instance » :
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
CMD ["node", "server.js"]
docker build -t myapp:1.0 .docker run --rm -p 3000:3000 myapp:1.0C’est la promesse centrale que Docker a popularisée : si vous pouvez construire l’image, vous pouvez exécuter la même chose de façon fiable — sur votre portable, dans le CI ou sur un serveur — sans réécrire les étapes d’installation à chaque fois.
Exécuter un conteneur sur son propre portable est utile — mais ce n’est pas la percée. Le vrai changement est survenu quand les équipes ont pu partager exactement le même build et l’exécuter n’importe où, sans les disputes « ça marche sur ma machine ». Docker a rendu ce partage aussi naturel que partager du code.
Un registre de conteneurs est un magasin pour les images. Si une image est l’application empaquetée, un registre est l’endroit où vous gardez les versions empaquetées pour que d’autres personnes et systèmes puissent les récupérer.
Les registries soutiennent un flux simple :
Les registries publiques (comme Docker Hub) ont facilité le démarrage. Mais la plupart des équipes ont rapidement eu besoin d’un registre adapté à leurs règles d’accès et exigences de conformité.
Les images sont généralement identifiées comme name:tag — par exemple myapp:1.4.2. Ce tag est plus qu’une étiquette : c’est la façon dont les humains et l’automatisation s’accordent sur quel build exécuter.
Une erreur commune est de se reposer sur latest. Ça paraît pratique, mais c’est ambigu : “latest” peut changer sans avertissement, provoquant une dérive des environnements. Un déploiement peut récupérer une build plus récente que le précédent — même si personne n’a voulu mettre à jour.
Bonnes habitudes :
1.4.2) pour les releasesDès que vous partagez des services internes, des dépendances payantes ou du code d’entreprise, vous voulez généralement un registre privé. Il permet de contrôler qui peut pull/push, s’intégrer au single sign‑on et garder le logiciel propriétaire hors des index publics.
C’est le saut « portable → équipe » : une fois les images dans un registre, votre CI, vos collègues et vos serveurs de production peuvent tous pull la même artefact — et le déploiement devient reproductible, pas improvisé.
Le CI/CD fonctionne mieux quand il peut traiter votre application comme une seule « chose » reproductible qui avance à travers les étapes. Les conteneurs fournissent exactement cela : un artefact empaqueté (l’image) que vous pouvez construire une fois et exécuter plusieurs fois, avec bien moins de « ça marche sur ma machine ».
Avant les conteneurs, les équipes essayaient souvent de reproduire des environnements avec des docs d’installation longues et des scripts partagés. Docker a changé le workflow par défaut : cloner le repo, construire une image, exécuter l’application. Les mêmes commandes fonctionnent souvent sur macOS, Windows et Linux parce que l’application s’exécute à l’intérieur du conteneur.
Cette standardisation accélère l’onboarding. Les nouveaux venus passent moins de temps à installer des dépendances et plus de temps à comprendre le produit.
Un bon setup CI/CD vise une sortie unique de pipeline. Avec les conteneurs, la sortie est une image taggée avec une version (souvent liée au SHA du commit). Cette même image est promue de dev → test → staging → production.
Plutôt que de reconstruire l’application différemment selon l’environnement, vous modifiez la configuration (variables d’environnement) tout en gardant l’artéfact identique. Cela réduit la dérive des environnements et facilite le débogage des releases.
Les conteneurs se mappent proprement aux étapes d’un pipeline :
Comme chaque étape s’exécute contre la même application empaquetée, les échecs sont plus signifiants : un test qui passe en CI a plus de chances de se comporter de la même façon après déploiement.
Si vous peaufinez votre process, il vaut aussi la peine d’établir des règles simples (conventions de tagging, signature d’images, scans basiques) pour que le pipeline reste prévisible. Vous pourrez ensuite étendre ces pratiques à mesure que l’équipe grandit (voir /blog/common-mistakes-and-how-to-avoid-them).
Où cela se connecte aux workflows modernes accélérés par l’IA : des plateformes comme Koder.ai peuvent générer et itérer des applications full‑stack (React pour le web, Go + PostgreSQL pour le backend, Flutter pour le mobile) via une interface de chat — mais il vous faut toujours une unité d’empaquetage fiable pour passer de « ça marche » à « ça s’expédie ». Traiter chaque build comme une image de conteneur versionnée maintient même le développement assisté par IA aligné avec les attentes CI/CD : builds reproductibles, déploiements prévisibles et releases prêtes au rollback.
Docker a rendu pratique l’empaquetage d’une appli une fois et son exécution partout. Le défi suivant est vite apparu : les équipes n’exécutaient pas un conteneur sur un portable — elles en exécutaient des dizaines (puis des centaines) sur de nombreuses machines, avec des versions qui changeaient constamment.
À ce stade, « démarrer un conteneur » cesse d’être la partie difficile. Le défi devient la gestion d’une flotte : décider où exécuter chaque conteneur, maintenir le bon nombre d’exemplaires en ligne et récupérer automatiquement quand ça casse.
Quand vous avez beaucoup de conteneurs répartis sur plusieurs serveurs, vous avez besoin d’un système pour les coordonner. C’est ce que font les orchestrateurs : ils traitent votre infrastructure comme un pool de ressources et s’efforcent continuellement de maintenir les applications dans l’état souhaité.
Kubernetes est devenu la réponse la plus courante (mais pas la seule). Il fournit un ensemble commun de concepts et d’API sur lesquels beaucoup d’équipes et de plateformes se sont standardisées.
Il est utile de séparer les responsabilités :
Kubernetes a introduit (et popularisé) plusieurs capacités pratiques dont les équipes ont eu besoin lorsque les conteneurs ont dépassé un hôte unique :
En bref, Docker a rendu l’unité portable ; Kubernetes a aidé à la rendre opérable — de façon prévisible et continue — quand il y a beaucoup d’unités en mouvement.
Les conteneurs n’ont pas seulement changé la manière dont on déploie le logiciel — ils ont aussi encouragé les équipes à concevoir le logiciel différemment.
Avant les conteneurs, fractionner une appli en nombreux petits services multipliait souvent la douleur opérationnelle : runtimes différents, dépendances conflictuelles, scripts de déploiement compliqués. Les conteneurs ont réduit cette friction. Si chaque service s’expédie comme une image et s’exécute de la même façon, créer un nouveau service paraît moins risqué.
Ceci dit, les conteneurs fonctionnent aussi bien pour les monolithes. Un monolithe dans un conteneur peut être plus simple qu’une migration microservices incomplète : une seule unité déployable, un seul flux de logs, un seul levier de montée en charge. Les conteneurs n’imposent pas un style — ils rendent plusieurs styles plus gérables.
Les plateformes de conteneurs ont encouragé les applications à se comporter comme des « boîtes noires » avec des entrées et sorties prévisibles. Conventions courantes :
Ces interfaces facilitent le remplacement de versions, les rollbacks et l’exécution de la même application sur portables, CI et production.
Les conteneurs ont popularisé des composants réutilisables comme les sidecars (un conteneur d’assistance à côté de l’application principale pour logs, proxies ou certificats). Ils ont aussi renforcé la recommandation d’un processus par conteneur — pas une règle absolue, mais un défaut utile pour la clarté, l’évolutivité et le diagnostic.
Le piège principal est le sur‑fractionnement. Juste parce que vous pouvez transformer tout en service ne signifie pas que vous devez le faire. Si un « microservice » ajoute plus d’overhead en coordination, latence et déploiement qu’il n’en retire, conservez‑le jusqu’à ce qu’une frontière claire apparaisse (besoins de scalabilité différents, responsabilité distincte, ou isolation des pannes).
Les conteneurs facilitent l’expédition du logiciel, mais ils ne le rendent pas automatiquement plus sûr. Un conteneur reste du code plus des dépendances, et il peut être mal configuré, obsolète ou carrément malveillant — surtout lorsque les images sont pull depuis Internet sans examen.
Si vous ne pouvez pas répondre à « D’où vient cette image ? », vous prenez déjà un risque. Les équipes tendent à établir une chaîne de responsabilité claire : construire les images dans un CI contrôlé, signer ou attester ce qui a été construit et garder un registre de ce qui est entré dans l’image (dépendances, version de l’image de base, étapes de build).
C’est aussi là que les SBOM (Software Bills of Materials) aident : ils rendent le contenu de votre conteneur visible et auditable.
Le scan est l’étape pratique suivante. Scannez régulièrement les images pour des vulnérabilités connues, mais traitez les résultats comme des éléments d’entrée pour vos décisions — pas comme une garantie de sécurité.
Une erreur fréquente est d’exécuter des conteneurs avec des permissions trop larges — utilisateur root par défaut, capacités Linux excessives, réseau hôte, ou mode privilégié « parce que ça marche ». Chacun de ces choix élargit le rayon d’impact en cas de problème.
Les secrets sont un autre piège. Variables d’environnement, fichiers de config intégrés ou .env commités peuvent fuir des identifiants. Préférez des magasins de secrets ou les mécanismes fournis par l’orchestrateur et organisez la rotation comme si l’exposition était inévitable.
Même des images « propres » peuvent être dangereuses à l’exécution. Surveillez les sockets Docker exposés, les montages de volumes trop permissifs et les conteneurs qui peuvent atteindre des services internes dont ils n’ont pas besoin.
Souvenez‑vous aussi : patcher l’hôte et le noyau reste important — les conteneurs partagent le noyau.
Pensez en quatre phases :
Les conteneurs réduisent la friction — mais la confiance doit toujours être gagnée, vérifiée et maintenue en continu.
Docker rend l’empaquetage prévisible, mais seulement si vous l’utilisez avec un peu de discipline. Beaucoup d’équipes rencontrent les mêmes nids de poule — puis reprochent aux « conteneurs » des problèmes qui sont en réalité des failles de workflow.
Une erreur classique est de construire des images énormes : utiliser des images de base OS complètes, installer des outils de build inutiles au runtime, et copier tout le repo (tests, docs, node_modules). Le résultat : téléchargements lents, CI lent et plus de surface d’attaque.
Autre problème courant : des builds lents qui cassent le cache. Si vous copiez tout le code source avant d’installer les dépendances, chaque petit changement force une réinstallation complète des dépendances.
Enfin, les équipes utilisent souvent des tags flous comme latest ou prod. Cela rend les rollbacks douloureux et transforme les déploiements en devinettes.
Cela tient généralement à des différences de configuration (variables d’environnement ou secrets manquants), de réseau (noms d’hôtes, ports, proxies, DNS différents) ou de stockage (données écrites dans le filesystem du conteneur au lieu d’un volume, ou permissions de fichiers différentes entre environnements).
Utilisez des images de base slim quand c’est possible (ou distroless si votre équipe est prête). Pinez les versions des images de base et des dépendances clés pour que les builds soient reproductibles.
Adoptez les multi‑stage builds pour garder compilateurs et outils de build hors de l’image finale :
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:20-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
CMD ["node","dist/server.js"]
Aussi, taggez les images avec quelque chose de traçable, comme le SHA git (et éventuellement un tag de release lisible).
Si une application est vraiment simple (un binaire statique, exécuté rarement, sans besoin de scalabilité), les conteneurs peuvent ajouter de la complexité inutile. Les systèmes legacy fortement couplés à un OS ou nécessitant des drivers matériels spécialisés peuvent aussi être de mauvais candidats — parfois une VM ou un service géré est un choix plus propre.
Les conteneurs sont devenus la valeur par défaut parce qu’ils ont résolu une douleur très spécifique et reproductible : faire tourner la même appli de la même manière sur portables, serveurs de test et production. Empaqueter l’application et ses dépendances ensemble a rendu les déploiements plus rapides, les rollbacks plus sûrs et les transferts entre équipes moins fragiles.
Tout aussi important, les conteneurs ont standardisé le workflow : build once, ship, run.
« Par défaut » ne veut pas dire que tout s’exécute dans Docker partout. Cela signifie que la plupart des pipelines de livraison modernes traitent une image de conteneur comme l’artéfact principal — plus qu’un zip, un snapshot VM ou un ensemble d’étapes manuelles.
Ce défaut inclut généralement trois éléments qui fonctionnent ensemble :
Commencez petit et concentrez‑vous sur la reproductibilité.
.dockerignore tôt.1.4.2, main, sha-…) et définissez qui peut pousser vs qui peut tirer.Si vous expérimentez des moyens plus rapides de construire du logiciel (y compris des approches assistées par IA), conservez la même discipline : versionner l’image, la stocker dans un registre et faire en sorte que les déploiements promeuvent cet artéfact unique en avant. C’est une des raisons pour lesquelles les équipes utilisant Koder.ai profitent toujours d’une livraison axée conteneur — l’itération rapide est excellente, mais la reproductibilité et la capacité de rollback sont ce qui la rend sûre.
Les conteneurs réduisent les problèmes de « ça marche sur ma machine », mais ils ne remplacent pas de bonnes pratiques opérationnelles. Vous devez toujours disposer de monitoring, d’une réponse aux incidents, de gestion des secrets, de patching, de contrôle d’accès et d’une responsabilité claire.
Traitez les conteneurs comme un standard d’empaquetage puissant — pas comme un raccourci qui évite la rigueur engineering.
Solomon Hykes est un ingénieur qui a mené le travail transformant l’isolation au niveau du système d’exploitation (les conteneurs) en un flux de travail accessible aux développeurs. En 2013, cette initiative a été publiée sous le nom de Docker, ce qui a rendu pratique pour des équipes quotidiennes le fait d’empaqueter une application avec ses dépendances et de l’exécuter de manière cohérente sur différents environnements.
Les conteneurs sont le concept sous-jacent : des processus isolés qui utilisent des fonctionnalités du système d’exploitation (comme les namespaces et les cgroups sur Linux). Docker est l’ensemble d’outils et de conventions qui a rendu les conteneurs faciles à construire, exécuter et partager (par exemple : Dockerfile → image → conteneur). Aujourd’hui, on peut utiliser les conteneurs sans Docker, mais Docker a popularisé ce flux de travail.
Il a résolu le problème du « ça marche sur ma machine » en regroupant le code de l’application et ses dépendances attendues dans une unité portable et reproductible. Plutôt que de déployer un ZIP et des instructions d’installation, les équipes déploient une image de conteneur qui peut s’exécuter de la même façon sur un poste de dev, dans le CI, en staging et en production.
Un Dockerfile est la recette de construction.
Une image est l’artéfact construit (un instantané immuable que l’on peut stocker et partager).
Un conteneur est une instance en cours d’exécution de cette image (un processus vivant avec un système de fichiers et des paramètres isolés).
Évitez latest parce que c’est ambigu et peut changer sans préavis, provoquant une dérive entre environnements.
Meilleures pratiques :
1.4.2sha-<hash>)Un registre est l’endroit où vous stockez les images de conteneur afin que d’autres machines et systèmes puissent récupérer exactement le même build.
Flux typique :
Pour la plupart des équipes, un devient nécessaire pour contrôler les accès, répondre aux exigences de conformité et garder le code propriétaire hors des index publics.
Les conteneurs partagent le noyau de l’hôte, ils sont donc généralement plus légers et démarrent plus vite que des machines virtuelles.
Modèle mental simple :
Une limite pratique : on ne peut généralement pas exécuter des conteneurs Windows sur un noyau Linux (et vice versa) sans virtualisation supplémentaire.
Ils permettent de produire une sortie unique pour le pipeline : l’image.
Une pratique CI/CD courante :
On change la configuration (variables d’environnement / secrets) en fonction de l’environnement, pas l’artéfact, ce qui réduit la dérive et facilite les rollbacks.
Docker a rendu « exécuter ce conteneur » facile sur une seule machine. À grande échelle, il faut aussi :
Kubernetes fournit ces capacités pour opérer des flottes de conteneurs de manière prévisible sur plusieurs machines.
Les conteneurs améliorent la cohérence de livraison, mais ne rendent pas automatiquement le logiciel sûr.
Principes pratiques :
privileged, minimiser les capacités, ne pas exécuter en root si possible)Pour les pièges courants (images volumineuses, builds qui cassent le cache, tags flous), voir aussi : /blog/common-mistakes-and-how-to-avoid-them