Chaque appel à une API de LLM hébergée envoie votre prompt vers le serveur de quelqu’un d’autre et vous facture par token. Coupez la connexion, et elle arrête de répondre. Ollama supprime ces deux problèmes : il récupère un modèle à poids ouverts sur votre machine et le sert via une API REST sur localhost:11434. Un seul binaire fait office de gestionnaire de modèles, de client de chat et de serveur. ...
docker build && docker push depuis votre poste fonctionne tant que personne d’autre n’a besoin de publier la même image, ou tant que cela n’a pas à se produire à chaque merge sans que vous soyez devant le clavier. GitHub Actions exécute cette build sur les runners de GitHub, tague l’image selon ce qui a déclenché le workflow, et la publie sur un registry depuis lequel votre étape de déploiement peut faire un pull. Rien ne tourne en local. ...
Où finissent les variables d’environnement d’un conteneur Démarrez un conteneur avec -e DB_PASSWORD=hunter2 et lancez docker inspect dessus : 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] Le mot de passe reste là en clair, lisible par quiconque a accès au socket Docker, par docker exec api env, et par n’importe quel processus qui tourne dans le conteneur. Ce n’est pas un bug : c’est exactement à ça que servent les variables d’environnement. Le problème, c’est de les utiliser pour des valeurs qui ne devraient jamais être aussi visibles. ...
Pourquoi une image Docker pèse dix fois plus que l’application Un service Node avec quelques centaines de kilo-octets de code source finit dans une image de plus de 1 Go. C’est le résultat normal d’un build qui fonctionne, pas une erreur sur une ligne précise. Le poids vient d’une image de base qui traîne un système d’exploitation complet, une chaîne d’outils de build que l’application en cours d’exécution n’appelle jamais, et un cache de gestionnaire de paquets que personne n’a demandé au build de supprimer. ...
Ce que vous coûte un mauvais Dockerfile 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Quatre lignes, et chacune vous coûte quelque chose. docker build relance npm install à chaque changement de code, parce que COPY . . casse le cache des couches avant même que l’étape d’installation ait une chance d’être réutilisée. L’image finale traîne toute la base Debian, l’arbre complet de node_modules avec les dépendances de développement, et tous les outils de build que npm install a récupérés pour compiler des modules natifs. Rien n’est jeté. Le conteneur tourne en root, parce que rien ne l’en empêche, et node:latest veut dire que l’image de base peut changer entre deux builds sans laisser de trace de ce que vous avez réellement livré. ...
Pourquoi deux conteneurs sur le même hôte ne se voient pas par défaut Lancez Postgres et votre API avec un simple docker run, et l’API n’arrive pas à joindre la base de données, alors que les deux conteneurs tournent sur la même machine. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Les deux atterrissent sur la bridge par défaut de Docker, celle que reçoit tout conteneur Docker sauf indication contraire. Ils obtiennent une adresse IP. Ce qu’ils n’obtiennent pas, c’est un moyen de se trouver par leur nom : l’API devrait donc coder en dur l’IP interne de la base de données, une adresse qui change à chaque redémarrage du conteneur. ...
Le problème que Compose résout Une vraie application, c’est rarement un seul conteneur. Une API web a besoin d’une base de données, la base de données a besoin d’un volume pour que ses données survivent à un redémarrage, puis vous ajoutez un cache Redis et un worker en arrière-plan. Cela fait quatre commandes docker run, chacune avec ses options pour les ports, les volumes, les variables d’environnement et un réseau partagé. Dans le bon ordre. Chaque fois que vous vous remettez au travail. ...
Docker et Podman exécutent les mêmes images avec les mêmes commandes. Ce qui les sépare, c’est l’architecture : Podman n’a pas de daemon en arrière-plan et tourne rootless par défaut, tandis que Docker apporte l’outillage mature, Docker Desktop et un Compose de première classe. Voici les différences qui pèsent vraiment sur votre travail : daemon, root, Compose et pods. Qu’est-ce que Podman ? Podman (Pod Manager) est un outil pour gérer les conteneurs et les pods, développé par Red Hat comme alternative open source à Docker. Sa caractéristique principale ? Il n’a pas besoin d’un daemon en cours d’exécution. ...
Pourquoi un conteneur perd ses données au redémarrage Écrivez une ligne dans une base de données qui tourne dans un conteneur Docker, arrêtez le conteneur, relancez-le : la ligne a disparu. Chaque conteneur reçoit son système de fichiers neuf depuis son image à chaque démarrage. Tout ce que le conteneur écrit lui-même — fichiers de base de données, uploads, logs — va dans une couche accessible en écriture qui est jetée quand le conteneur est supprimé. Un volume Docker sert à garder ces données hors du conteneur, là où elles survivent. ...
Ce que fait Docker, concrètement Docker est une plateforme open source qui empaquette une application avec tout ce qu’il lui faut pour tourner — code, bibliothèques, runtime, configuration — dans un conteneur qui se comporte de la même façon sur n’importe quelle machine. Le déménagement rend le compromis concret. Vous avez deux options : Transporter tous vos objets en vrac, en espérant qu’ils arrivent intacts Tout mettre dans des cartons organisés, étiquetés et faciles à déplacer Docker fait exactement cela avec les applications logicielles : il les “emballe” dans des conteneurs qui contiennent tout le nécessaire pour fonctionner. ...