Ce tutoriel explique comment créer un registry Docker privé avec Podman et Quadlet, en mode rootless pour plus de sécurité. Après avoir installé Podman et créé un utilisateur dédié, on génère un certificat auto-signé et un fichier d’authentification (htpasswd). Le registry est lancé via un conteneur Docker officiel, puis configuré pour démarrer automatiquement avec un fichier registry.container dans ~/.config/containers/systemd/. Une redirection de port (443 → 5000) est configurée via firewalld, et un nettoyage automatique des fichiers temporaires est mis en place. Pour tester, on pousse une image (hello-world) depuis une machine cliente après avoir configuré l’accès en mode insecure dans /etc/containers/registries.conf. Une solution simple et locale pour héberger ses images conteneurisées.
Exemple de commande clé :
podman run -d --name registry -p 5000:5000 -v ~/podman-registry/data:/var/lib/registry:Z [...]
Ce partage explique comment utiliser Symfony 7 et Mercure pour créer une session live réactive sans WebSocket. L'auteur, Jean-Sébastien Christophe, explore l'intégration de Mercure, un protocole de Server-Sent Events (SSE), pour gérer des états de session en temps réel, comme la présence des utilisateurs, sans nécessiter de requêtes répétées ou de boucles côté client. Il détaille la stack technique utilisée (Symfony 7.3, PHP 8.4, Docker, PostgreSQL, MailCatcher) et les avantages de Mercure pour des applications temps réel, tout en prévoyant une future intégration avec FrankenPHP pour optimiser les performances et la sécurité.
Ce billet détaille l’expérience de passage à FrankenPHP en production, comparant l’ancienne stack Nginx/PHP-FPM à une technologie dépassée comme le Minitel. L’auteur explique comment il a déployé FrankenPHP sur un VPS à l’aide d’un Makefile optimisé, en abordant la création d’un Dockerfile de production, l’intégration CI/CD, et une astuce de multiplexing SSH pour éviter les blocages par fail2ban. Une lecture utile pour ceux qui veulent moderniser leur infrastructure PHP avec simplicité et efficacité.
Le billet explique comment FrankenPHP rend obsolètes les configurations traditionnelles utilisant Nginx et PHP-FPM pour les applications PHP. L'auteur partage son retour d'expérience sur le déploiement d'un projet Symfony avec FrankenPHP sur un VPS, mettant en avant sa simplicité et ses performances, même en production. L'article souligne que FrankenPHP offre une alternative moderne, plus légère et efficace, pour les environnements Docker, tout en évitant les problèmes classiques comme les timeouts SSH. Une solution idéale pour ceux qui cherchent à optimiser leur infrastructure PHP.
L’article raconte une expérience douloureuse : l’utilisation du tag latest pour une image Docker a causé une panne en production après qu’une mise à jour silencieuse de l’image de base (PostgreSQL) ait changé la version de collation du système d’exploitation, rendant la base de données incompatible. L’auteur explique que latest n’est pas synonyme de « stable » ou « sûr », mais simplement de « dernière version disponible », ce qui peut varier à tout moment. Il détaille trois raisons d’éviter latest : stabilité (comportement cohérent), reproductibilité (diagnostic et audit facilités), et contrôle des mises à jour (éviter les surprises). La solution ? Toujours spécifier un tag explicite (ex: postgres:15.3-alpine) dans Docker, Docker Compose ou Kubernetes. Un rappel utile : ne jamais laisser le choix de la version à quelqu’un d’autre, surtout en production.
L’article explique comment FrankenPHP a rendu obsolètes les stacks traditionnelles à base de Nginx + PHP-FPM, en offrant une solution plus simple, performante et moderne pour exécuter des applications PHP. L’auteur détaille son passage à une architecture Docker intégrant FrankenPHP (basé sur le serveur web Caddy) et PostgreSQL, mettant en avant plusieurs avantages clés : une isolation complète des services, une parité parfaite entre développement et production, et une expérience développeur optimisée (hot reload, HTTPS local automatique, débogage facilité avec Xdebug). FrankenPHP se distingue par son mode "worker", qui maintient l’application PHP en mémoire, éliminant ainsi les temps de démarrage à chaque requête. Le billet décrit aussi l’utilisation de Docker multi-stage pour générer des images légères et sécurisées, et l’importance d’une configuration adaptée pour le développement (logs détaillés, désactivation du cache) comme pour la production (optimisation des performances). En résumé, FrankenPHP simplifie la stack technique tout en améliorant significativement les performances et la productivité. Une lecture utile pour les développeurs PHP souhaitant moderniser leur environnement.
L’article explique comment mettre en place un système de visioconférence performant dans Nextcloud, en dépassant les limites des solutions traditionnelles comme Talk ou l’intégration de BigBlueButton. Il propose deux méthodes d’installation : un script de déploiement pour un serveur dédié, ou un déploiement en conteneurs Docker (pour le signaling et l’enregistrement), avec des exemples de fichiers docker-compose et de configurations Apache. L’objectif est d’offrir une solution scalable, intégrée à Nextcloud, permettant notamment l’enregistrement de webinaires ou de démonstrations. L’auteur partage aussi des captures d’écran et un exemple concret d’utilisation réussie. Idéal pour ceux qui cherchent à optimiser la visio et l’enregistrement dans leur instance Nextcloud.
L’article explique deux approches pour gérer plusieurs environnements (développement, staging, production) avec Docker : une approche inspirée de Rails, utilisant des Dockerfiles séparés (ex: Dockerfile.dev, Dockerfile.prod), et une approche idiomatique Docker basée sur les multi-stage builds. La première méthode offre une séparation claire, mais peut entraîner de la duplication de code, tandis que la seconde permet de centraliser la configuration dans un seul fichier, réduisant la redondance et facilitant la maintenance, bien qu’elle puisse devenir complexe à mesure que les builds se sophistiquent. L’auteur souligne que le choix dépend de la complexité des environnements et de l’expérience de l’équipe avec Docker.
Ce shaarli explique comment utiliser Podman comme un substitut à Docker, en permettant l'exécution des commandes Docker habituelles avec Podman. L'article détaille l'installation du paquet podman-docker, qui fournit un script docker émulant les commandes Docker, ainsi que la suppression du message d'avertissement via la création du fichier /etc/containers/nodocker. Il aborde aussi la compatibilité avec docker-compose grâce à l'installation de podman-compose, et présente deux solutions pour gérer le démarrage automatique des conteneurs (via Quadlet ou en activant le service podman-restart). L'objectif est de faciliter la transition pour les utilisateurs habitués à Docker, tout en profitant des avantages de Podman, notamment son absence de démon.
L’article présente Warpgate, un outil open source qui simplifie la gestion des accès sécurisés (SSH, PostgreSQL, MySQL, HTTP) en agissant comme un bastion moderne. Facile à déployer (binaire ou Docker), il centralise l’authentification (avec support SSO), offre une connexion transparente et un audit en temps réel des sessions. L’auteur souligne sa simplicité, sa sécurité renforcée et son interface intuitive, idéale pour remplacer les solutions complexes de machines de rebond. Un exemple de déploiement avec Docker Compose est fourni, illustrant la rapidité de mise en place. Une pépite pour les administrateurs système en quête d’efficacité et de traçabilité.
Ce billet explique comment résoudre en DNS les noms de conteneurs Docker sous le domaine local .docker en utilisant systemd-resolved plutôt que dnsmasq, une solution plus simple et performante depuis systemd 258. L’auteur utilise toujours dnsdock pour gérer la résolution DNS, mais délègue désormais la zone .docker à ce service via un fichier de configuration /etc/systemd/dns-delegate.d/docker.dns-delegate. Après avoir lancé dnsdock et configuré resolved, il devient possible de résoudre les noms des conteneurs (basés sur leur nom, alias ou étiquettes) directement depuis la machine hôte, facilitant ainsi la gestion de plusieurs services comme PostgreSQL sans conflit de ports. Une mise à jour pratique pour les utilisateurs de Docker et systemd.
Cet article explique comment configurer WordPress avec MariaDB et Traefik en utilisant des réseaux Docker séparés pour améliorer la sécurité et faciliter la duplication de sites. L’article détaille la création d’une architecture où chaque site WordPress et sa base de données sont isolés dans leur propre réseau privé, inaccessible depuis internet, tandis que Traefik gère le routage et les certificats SSL automatiquement via Let’s Encrypt. Le tutoriel propose une configuration étape par étape : installation de Traefik avec SSL, création de réseaux Docker dédiés, déploiement d’un premier site WordPress, puis duplication aisée pour ajouter d’autres sites. Les avantages soulignés sont la sécurité renforcée, la simplicité de gestion et la possibilité d’ajouter facilement de nouveaux sites. L’auteur évoque aussi des pistes d’amélioration, comme l’automatisation des sauvegardes des bases de données. Idéal pour qui veut héberger plusieurs sites WordPress de manière sécurisée et scalable.
L’article explique pourquoi l’auteur a abandonné Docker pour Podman, mettant en avant plusieurs avantages clés : Podman est sans démon, ce qui améliore la sécurité (moins de vulnérabilités liées à un processus root permanent) et réduit la consommation de ressources. Il s’intègre nativement avec systemd et Kubernetes, facilitant la gestion des conteneurs comme des services système et permettant une transition fluide vers des environnements de production. La migration est simple, car Podman utilise les mêmes commandes et fichiers Dockerfile que Docker, tout en offrant une approche plus sécurisée (mode rootless par défaut) et une meilleure alignement avec les pratiques Linux modernes. L’auteur souligne aussi que Podman encourage une architecture plus propre, comme l’utilisation d’un reverse proxy plutôt que l’exposition directe de ports privilégiés. En résumé, Podman se présente comme une évolution naturelle pour les développeurs cherchant plus de sécurité, de légèreté et de cohérence entre le développement et la production.
L’article explique comment simplifier le déploiement d’agents IA en conteneurisant une application Symfony avec Docker. Il présente trois stratégies (monolithique, sidecar, hybride) pour adapter la conteneurisation aux besoins du projet, en privilégiant une approche hybride combinant Nginx, PHP-FPM et Supervisord dans un seul conteneur, tout en permettant des tâches spécifiques via des sidecars. L’auteur détaille la configuration des fichiers Nginx, PHP, PHP-FPM et Supervisord, ainsi que la création d’un Dockerfile et d’un docker-compose.yml pour une image auto-suffisante et scalable. L’objectif est d’assurer la portabilité, la robustesse et l’évolutivité, notamment pour des environnements Kubernetes, tout en évitant les anti-patterns comme la reconstruction d’image par environnement. L’article insiste sur l’utilisation de UTC, la séparation des configurations par environnement et l’automatisation via CI/CD pour un déploiement fiable et reproductible.
Dockeriser une application Symfony pour déployer un agent IA de manière scalable : Cet article explique comment containeriser une application Symfony avec Docker et Docker Compose, en explorant trois stratégies (monolithique, sidecar, hybride). L’approche hybride est privilégiée pour allier simplicité et flexibilité, en utilisant Supervisord pour gérer Nginx, PHP-FPM et les consommateurs de messages. Les fichiers de configuration (Nginx, PHP, PHP-FPM) sont intégrés à l’image, et un Dockerfile optimisé permet de créer un environnement reproductible et portable. L’article souligne l’importance d’utiliser UTC pour la gestion du temps, de séparer les configurations par environnement, et d’éviter de reconstruire l’image pour chaque déploiement. Enfin, un fichier docker-compose.yml orchestrerait le tout, avec Redis pour la gestion des messages, offrant une base solide pour un déploiement scalable et observable, prêt pour Kubernetes.
Pour optimiser les Dev Containers, l’auteur propose une approche basée sur les prebuilds : créer une image Docker générique (avec Zsh, Oh My Zsh, Docker-in-Docker, etc.) et la réutiliser comme base pour tous ses projets. Cela évite de reconstruire l’environnement à chaque fois et réduit le temps de démarrage. Il utilise aussi des volumes Docker pour persister l’historique des commandes et les dépendances Maven entre les conteneurs. Grâce à la CLI des Dev Containers, il construit et pousse ces images pré-configurées, puis les utilise directement dans ses projets (ex. : Java avec Maven, JBang, Quarkus). Résultat : des environnements prêts en quelques secondes, même si la taille des images reste conséquente. Une méthode idéale pour gagner en efficacité, surtout lors des changements de machine ou pour standardiser ses outils de dev.
Cet article explore des techniques avancées pour personnaliser les Dev Containers, allant au-delà de la simple configuration de base. L’auteur illustre comment installer un outil comme SliDesk via différentes méthodes : en utilisant postCreateCommand (simple mais répétitif), en créant une feature (réutilisable et versionnable, idéale pour partager des configurations), ou en construisant une image Docker custom (pour un environnement sur mesure et optimisé). Il aborde aussi l’utilisation de Docker in Docker pour construire des images directement depuis le conteneur, et de Docker Compose pour gérer des environnements complexes incluant des bases de données ou d’autres services. Enfin, il présente les templates, qui permettent de pré-configurer des Dev Containers pour des projets similaires, évitant ainsi la duplication de code. Une lecture essentielle pour qui veut industrialiser et standardiser ses environnements de développement avec flexibilité et efficacité !
Ce tutoriel détaillé explique comment mettre en place une solution de supervision complète de vos serveurs avec Prometheus (pour la collecte et le stockage des métriques système) et Grafana (pour leur visualisation sous forme de tableaux de bord interactifs).
Il couvre l’installation et la configuration de Prometheus et Grafana via Docker sur un serveur dédié, ainsi que le déploiement d’exporters comme node_exporter (métriques système), cAdvisor (métriques containers Docker), process_exporter (métriques processus), et blackbox_exporter (tests de disponibilité des services). Le guide aborde aussi la sécurisation des interfaces, la création d’alertes, et l’intégration d’Alert Manager pour la gestion des notifications. Idéal pour surveiller en temps réel l’état de votre infrastructure et recevoir des alertes en cas de dépassement de seuils, avec des exemples concrets et des tableaux de bord Grafana prêts à l’emploi.
Un super outil à auto héberger qui permet de convertir des fichiers dans plein de formats
L’article présente l’utilisation de Make pour simplifier et standardiser les commandes courantes dans un projet Symfony, surtout en environnement Docker. L’auteur partage ses Makefiles personnalisés, qui permettent de lancer des tâches comme l’installation des dépendances (make composer), l’exécution des tests (make test), l’analyse statique (make static-analysis), ou encore la gestion de la base de données (make db-reset), le tout avec des paramètres optionnels pour l’environnement (env=prod) ou des arguments supplémentaires (arg=--testdox). Grâce à Make, les commandes Docker complexes deviennent simples et documentées (ex: make qa pour lancer la vérification de code, l’analyse statique et les tests en une seule commande). L’article propose trois versions de Makefile : pour Docker Compose, Docker seul, et PHP natif, inspirées du projet symfony-docker. L’objectif est d’améliorer la productivité en évitant de retaper des commandes longues et en centralisant la documentation des tâches disponibles. Une solution élégante pour uniformiser les workflows entre projets Symfony.