Configurer Nginx manuellement demande de maîtriser sa syntaxe et de gérer les certificats SSL à la main. Nginx Proxy Manager expose une interface web qui automatise ces deux aspects : création de règles de routage via une UI, et renouvellement automatique des certificats Let's Encrypt. Il génère du vrai Nginx sous le capot : les configurations avancées restent accessibles via des blocs personnalisés.
Kubernetes expose une API déclarative : l'utilisateur décrit l'état souhaité via des ressources YAML, et le cluster converge vers cet état (voir l'architecture de Kubernetes). Quatre ressources couvrent la majorité des besoins : Pod, Deployment, StatefulSet, Service. Comprendre pourquoi chacune existe, et pas seulement comment l'écrire, évite les mauvais choix d'architecture.
Faire tourner quelques conteneurs sur une seule machine se gère avec Docker ou Docker Compose. Gérer des centaines de conteneurs répartis sur des dizaines de machines, avec des contraintes de disponibilité, de mise à l'échelle et de mise à jour sans interruption, est un problème fondamentalement différent. Kubernetes répond à ce problème : un système d'orchestration qui prend en charge le placement, le redémarrage, la mise à l'échelle et la communication des conteneurs à l'échelle d'un cluster.
Une image Docker doit être identique entre les environnements : dev, staging, prod. Ce qui change entre environnements, c'est la configuration : URL de base de données, niveau de log, clés API. Kubernetes fournit deux ressources pour externaliser cette configuration : ConfigMap pour les données non sensibles, Secret pour les credentials.
Les pods sont éphémères. Quand un pod est supprimé ou recréé, son système de fichiers disparaît avec lui. Pour les workloads qui ont besoin de conserver des données (bases de données, systèmes de fichiers partagés, queues persistantes), Kubernetes fournit un système de stockage découplé du cycle de vie des pods.
Voici un résumé de ma roadmap DevOps personnelle pour 2025. Cette roadmap s’appuie sur les réalisations de l’année précédente et vise à approfondir l’orchestration, l’observabilité et l’Infrastructure as Code. Elle évolue au fil des projets, des expérimentations et des apprentissages partagés sur le blog.
Nginx est un serveur web événementiel conçu pour gérer un grand nombre de connexions simultanées avec une faible empreinte mémoire. Contrairement aux serveurs qui dédient un processus ou un thread à chaque connexion (Apache avec les MPM prefork ou worker), il utilise un modèle non-bloquant à base de boucle d'événements : chaque worker process gère des milliers de connexions sans créer un thread par connexion. Cette architecture le rend particulièrement adapté comme reverse proxy en frontal d'une infrastructure.
Un proxy et un reverse proxy remplissent tous les deux un rôle d'intermédiaire réseau, mais ils se positionnent de chaque côté de la connexion : l'un représente le client, l'autre protège le serveur. Confondre les deux mène à des architectures mal configurées et à des règles de sécurité inefficaces.
Conteneurs et machines virtuelles répondent au même besoin d'isolation des applications, mais à des niveaux différents de la pile système. Comprendre cette différence architecturale explique pourquoi les deux technologies coexistent plutôt que l'une remplace l'autre.
Une image Docker mal construite peut peser plusieurs gigaoctets, exposer des secrets dans ses couches, ou s'exécuter en root sans raison valable. Ces problèmes découlent directement du fonctionnement des couches et du cache de build, décrits dans l'article Docker : conteneurs et images, et s'évitent avec quelques principes de construction appliqués systématiquement.