Planète Warez

Je pensais pouvoir encore éditer mon premier message, mais apparemment non 😅

Il y a du nouveau pour BookHub.
Le projet a beaucoup changé dans son fonctionnement et dans les scripts utilisés, mais pas dans le but !

Suite à beaucoup de tests, des problèmes ont été corrigés, des améliorations faites et une certaine simplification.
Je souhaitais aussi éditer les métadonnées et que ce soit cohérent pour tous les ebooks. Constatation faite : avec Calibre, je ne parvenais pas à avoir des métadonnées cohérentes et surtout une gestion très aléatoire des séries.

Je n’ai pas trouvé une meilleure solution que :

Possible que le fonctionnement avec l’IA soit un peu lourd, mais cela me permettrait ensuite d’implémenter probablement aussi la gestion des livres audio et des BD.

Le but étant de pouvoir changer facilement d’outils
(Kavita, Audiobookshelf, etc.) si nécessaire.
Avec une bonne hiérarchie de dossiers et des métadonnées complètes, ce ne sera pas un problème.

Traefik est un reverse proxy (et un load balancer) open source conçu pour les applications web (HTTP/HTTPS) et la gestion des connexions TCP. Créé par le Français Émile Vauge, Traefik s’est imposé comme une solution incontournable pour publier des applications exécutées au sein de conteneurs Docker, bien que ce ne soit pas le seul cas d’utilisation. Comment fonctionne-t-il ? Comment installer Traefik ? Réponse dans ce guide complet.

Dans un environnement basé sur Docker, il est fréquent d’héberger plusieurs applications web sur un même serveur. Chaque conteneur peut exposer un port différent, mais il devient vite difficile d’organiser les accès, de gérer les certificats TLS, et d’ajouter ou retirer des services sans casser les autres. La solution naturelle pour publier ces applications et mieux s’y retrouver, c’est d’utiliser un reverse proxy. Et parmi les reverse proxy capables de tirer parti de Docker de manière dynamique, Traefik s’est imposé comme une référence en tant que reverse proxy pour microservices.

La force de Traefik, c’est notamment sa capacité à détecter automatiquement vos conteneurs et à simplifier l’intégration d’applications avec de simples labels. À cela s’ajoute la possibilité d’obtenir automatiquement des certificats TLS via Let’s Encrypt (ACME).

Dans ce tutoriel, nous allons installer Traefik sur un serveur Linux (Debian 13) avec Docker Compose, puis déployer une première application pour valider que tout fonctionne correctement. Cette application sera publiée avec Traefik en HTTP puis en HTTPS (avec l’obtention automatique d’un certificat TLS). L’objectif est de comprendre les briques fondamentales de Traefik.

Avant même d’écrire un fichier Docker Compose et de foncer dans le déploiement du reverse proxy Traefik, il est nécessaire de comprendre comment il est structuré. Le schéma ci-dessous met en évidence le positionnement central de Traefik dans l’accès aux applications web et aux API. Du côté backend, même si ce tutoriel est axé sur l’intégration avec Docker, il est envisageable de router le trafic vers d’autres destinations (Kubernetes, machine virtuelle, etc.).

Traefik a quatre briques fondamentales :

Bien qu’il y ait une partie de la configuration de Traefik qui soit statique, il y a aussi une partie de la configuration qui est vivante, voire même dynamique. En pratique, comme nous le verrons par la suite, pour exposer une app via Traefik, nous devons simplement ajouter les labels qu’il faut sur le conteneur, et Traefik récupère la configuration via Docker.

Pour la suite, il faut un serveur (Linux) sur lequel Docker et Docker Compose sont installés. Le tutoriel s’applique aussi bien sur un VPS cloud que sur un serveur physique local. Vous devez aussi disposer d’un nom de domaine : it-connectlab.fr sera utilisé pour cette démonstration. Un enregistrement DNS a été fait pour une application dont l’adresse IP correspond au serveur Traefik, ce dernier étant en charge de router le trafic (principe du reverse proxy).

Pour installer Docker sur Linux, vous pouvez suivre ce tutoriel :

Nous allons commencer par créer un dossier pour stocker les données de l’application Traefik.

À la racine de ce dossier, nous allons créer le fichier docker-compose.yml.

En guise de point de départ, nous allons utiliser le** fichier Docker Compose** disponible dans la documentation de Traefik. La version 3.6 de Traefik sera utilisée, il s’agit de la dernière version stable actuelle. Deux ports sont exposés au niveau de ce conteneur : 80, pour bénéficier d’un entryPoint en HTTP (pour publier une application en HTTP) et 8080 pour l’accès au tableau de bord de Traefik.

Trois commandes sont aussi associées à l’exécution de ce conteneur en tant qu’arguments :

Enfin, une dernière ligne importante est intégrée à ce fichier : /var/run/docker.sock:/var/run/docker.sock. Elle permet à Traefik d’accéder au socket Docker pour “voir” en temps réel les autres conteneurs. C’est important pour l’intégration de Traefik avec Docker, notamment pour lire les labels.

Vous remarquerez que ce Docker Compose ne contient pas de directives pour la connexion au réseau du conteneur. C’est la première évolution que nous allons lui apporter. Nous allons créer un réseau Docker nommé frontend, ce qui me semble être un nom adapté dans le contexte d’un reverse proxy.

Une fois le réseau créé, vérifiez qu’il est bien présent :

Dans le fichier Docker Compose, nous allons associer ce réseau au conteneur Traefik. Il sera déclaré comme un réseau externe (external: true) pour ne pas que Docker cherche à le créer.

Note: le port HTTPS, à savoir 443, n’est pas exposé pour le moment. Si vous envisagez dès maintenant de publier une application HTTPS, vous pouvez ajouter le port dès maintenant via l’ajout d’une ligne supplémentaire.

La configuration globale et statique de Traefik se déclare par l’intermédiaire du fichier traefik.yml, au format YAML.

Nous allons ajouter une ligne sous volumes pour déclarer le fichier de configuration de Traefik, afin qu’il soit persistant et modifiable, tout en étant lu par le conteneur. Par la suite, nous manipulerons à plusieurs reprises le fichier traefik.yml pour ajouter différentes directives.

Le fichier doit donc être créé à cet emplacement : /opt/docker-compose/traefik/traefik.yml.

Éditez le fichier et ajoutez le code précisé ci-dessous pour définir les bases de Traefik en mode proxy inverse pour HTTP et HTTPS.

Nous désactivons l’envoi de statistiques anonymisées (sendAnonymousUsage) et la vérification automatique de nouvelles versions (checkNewVersion). Nous activons le tableau de bord interne (port 8080) en mode non sécurisé (pas adapté à la production !) afin de pouvoir y accéder dans un premier temps pour visualiser les routes de Traefik. Enfin, on déclare deux entryPoints : un pour le trafic HTTP classique sur le port 80 (nommé web), et un second pour le trafic HTTPS sécurisé sur le port 443 (nommé websecure). Cela prépare Traefik à écouter sur ces deux ports et à accepter des requêtes entrantes que l’on pourra ensuite router vers nos conteneurs.

Enregistrez et fermez le fichier.

Pour éviter les doublons entre la configuration statique et les arguments en ligne de commande, je vous invite à supprimer la ligne command et les trois lignes associées dans le fichier Docker Compose, à savoir :

Dans le fichier Docker Compose, le nécessaire a été fait pour que le conteneur Traefik dispose d’un accès au socket de Docker (/var/run/docker.sock). Mais ce lien n’est pas exploité en l’état actuel de la configuration. Dans le fichier de configuration⁣ traefik.yml, il est nécessaire d’ajouter un nouveau fournisseur (Provider) correspondant à Docker.

Éditez de nouveau le fichier traefik.yml et ajoutez ce bloc à la fin du fichier :

La directive exposedByDefault joue un rôle important ! Si elle est sur false comme ici, cela signifie que Traefik va détecter les conteneurs Docker sans les exposer automatiquement : seuls les conteneurs qui auront des labels Traefik seront pris en compte et routés, ce qui évite d’exposer par erreur un service qui ne devrait pas être accessible depuis l’extérieur.

Désormais, enregistrez la configuration et lancez la construction du conteneur Traefik (depuis le répertoire /opt/docker-compose/traefik).

Ouvrez un navigateur web et accédez au tableau de bord de Traefik via l’adresse IP de l’hôte Docker sur le port 8080. Par exemple : http://192.168.10.200:8080. Ce tableau de bord ne permet pas d’effectuer la configuration en ligne, mais il présente l’avantage d’afficher l’état de la configuration actuelle. Vous devriez notamment visualiser les 3 entryPoints de notre configuration Traefik (celui du dashboard est automatique quand ce dernier est activé).

Traefik tourne sur notre serveur, c’est une bonne chose. Mais, pour le moment, il ne sert pas à grand-chose car aucun service n’est exposé par son intermédiaire. Pour commencer, nous allons exposer une application facile à héberger : IT-Tools, une boite à outils en ligne. Dans un premier temps, l’accès sera effectué en HTTP, puisque la gestion du certificat rajoute une couche de complexité supplémentaire.

Créez un dossier pour ce projet :

Dans ce répertoire, créez un fichier docker-compose.yml et insérez le code ci-dessous. Ce service lance l’application IT-Tools à partir de l’image officielle ghcr.io/corentinth/it-tools:latest et nomme le conteneur it-tools. Il est important de noter aussi que ce conteneur est rattaché au réseau Docker externe frontend, le même réseau que Traefik : c’est ce qui permet à Traefik de le découvrir et de router le trafic vers lui (grâce au montage du socket Docker côté Traefik et au provider Docker activé). Il n’y a donc pas de port exposé sur l’hôte pour ce conteneur.

Il y a aussi une section labels essentielle pour permettre la découverte par Traefik.

Les Labels Traefik : ce qu’ils font

Petite parenthèse : il est à noter que Traefik va automatiquement associer un service à ce routeur. Chaque service est associé à un module load balancer Traefik (équilibrage de charge), car c’est une fonction indispensable pour chaque reverse proxy pour distribuer la charge en plusieurs serveurs de backends. Même s’il n’y a qu’un seul serveur de backend, comme c’est le cas ici avec un seul conteneur, il y a le load balancer. Dans le cas présent, afin de compléter la configuration, nous pourrions ajouter ce label supplémentaire (c’est important sur les conteneurs où plusieurs ports sont en écoute) :

Enregistrez le fichier et lancez le déploiement de l’application :

À partir d’un navigateur Web, vous devriez pouvoir accéder à l’application :

L’application a été correctement publiée par l’intermédiaire de Traefik !

Un accès en HTTP en 2025, ce n’est pas l’idéal tant le HTTPS s’est démocratisé depuis plusieurs années. Surtout, il n’est pas nécessaire de payer pour obtenir un certificat TLS valide : merci Let’s Encrypt. La bonne nouvelle, c’est que Traefik supporte deux Certificate Resolvers : **ACME **(donc Let’s Encrypt) et **Tailscale **pour les services internes et accessibles via cette solution.

Dans le contexte de la méthode ACME, Traefik prend en charge plusieurs types de challenges pour demander automatiquement le certificat. Il y a le challenge HTTP (httpChallenge) qui est surement le plus classique, mais qui implique que l’hôte soit accessible en HTTP sur le port 80. Surtout, il y a le challenge DNS (dnsChallenge) grâce à l’intégration de Lego, ce qui permet de jouer sur les enregistrements DNS de façon automatique en ciblant les API des gestionnaires de zones DNS.

Par exemple : vous disposez d’un domaine enregistré chez OVHCloud, vous pouvez effectuer des demandes de certificats Let’s Encrypt via le composant ACME intégré à Traefik, le tout via l’API de OVHCloud. Autrement dit, c’est un processus pleinement automatisé. Cela est aussi vrai pour des dizaines d’autres providers DNS compatibles Traefik, comme Cloudflare, Azure DNS, Gandi, Hostinger ou encore Ionos (voir cette page).

Pour la suite de cet article, l’objectif sera le suivant : obtenir un certificat TLS pour le domaine it-tools.it-connectlab.fr afin de publier l’application en HTTPS. Ce domaine étant enregistré chez OVHCloud, nous devrons utiliser leur API.

Vous devez commencer par exposer le 443 au niveau du conteneur Traefik en éditant le fichier docker-compose.yml de ce projet.

Vous devez commencer par créer une nouvelle API d’application à partir du portail OVHCloud. Pour l’Europe, il faut accéder à la page eu.api.ovh.com/createApp/, tandis que pour les États-Unis et le Canada, c’est sur la page ca.api.ovh.com/createApp/.

Donnez un nom à l’application et précisez une description. Par exemple :

En retour, vous obtenez une clé d’application et un secret associé. Vous devez garder précieusement ces deux informations.

Ensuite, à l’aide d’une console PowerShell (passez par PowerShell ISE ou VSCode, ce sera plus pratique), vous devez envoyer une requête sur l’API pour donner des droits à cette application. Utilisez le code ci-dessous, en adaptant le nom DNS pour cibler le bon domaine, ainsi que la valeur à la suite de X-Ovh-Application en précisant la clé d’application.

L’exécution de cette commande retourne deux informations importantes :

L’URL à laquelle vous avez accédé précédemment affiche une demande de confirmation comme celle ci-dessous. Pensez à ajuster la durée de validité de cet accès et cliquez sur le bouton “Authorize”.

5bbf2121-2cc0-476a-bc54-da96bb1d384a-image.png

Vous serez redirigé vers la page indiquée lors de l’exécution de la commande curl. Même si le domaine ne renvoie vers rien, ce n’est pas gênant.

Voilà, l’accès est prêt au niveau de l’API OVHCloud et de votre compte.

Puisque Traefik intègre Lego, vous devez consulter la documentation du fournisseur DNS correspondant à vos besoins pour savoir comment le configurer. Vous pouvez consulter, par exemple, la page concernant ovh. Ici, nous allons ajouter 4 variables d’environnement au fichier docker-compose.yml de Traefik :

Dans le fichier Docker Compose, ces variables sont introduites sans valeur directe, car nous allons utiliser un fichier externe. En même temps, dans la section volumes, rajoutez le montage du dossier ./certs (soit /opt/docker-compose/traefik/certs/ que vous devrez créer).

Enregistrez et fermez ce fichier. Aux côtés du fichier Docker Compose, créez le fichier .env et associez les bonnes valeurs aux variables. Mise à part pour la première variable, pour les autres, ce sont des informations confidentielles spécifiques à votre environnement.

Pour autant, la configuration ne s’arrête pas là. Ensuite, vous allez devoir ouvrir le fichier de configuration traefik.yml. Vérifiez la présence d’un entryPoint HTTPS, comme websecure dans l’exemple ci-dessous.

Dans cette configuration, nous devons définir un nouveau résolveur de certificats ACME pour OVHCloud utilisé par Traefik pour obtenir automatiquement des certificats SSL/TLS via Let’s Encrypt.

Dans cet exemple, le résolveur sera simplement nommé ovhcloud, une adresse e-mail ([email protected]) est associée au compte ACME, tandis que le fichier /var/traefik/certs/ovh-acme.json stocke les certificats et clés générés. Le paramètre caServer indique l’URL de l’API Let’s Encrypt, ici en mode production (avec une alternative en mode staging, moins limitée). Vous pouvez tout à fait utiliser le mode staging pour tester la configuration, puis basculer en mode production ensuite.

Enfin, la section dnsChallenge précise que la validation du domaine s’effectue via OVHCloud, en créant automatiquement un enregistrement DNS (demandé par Let’s Encrypt au cours du processus). Le delayBeforeCheck de 10 secondes associé laisse le temps à la propagation DNS avant la vérification du certificat. Si vous indiquez 0, cela améliore la réactivité mais c’est aussi une source d’erreur, ce qui est contreproductif.

Enregistrez et fermez le fichier. La configuration de Traefik est terminée ! Pensez à faire un Down/Up sur le conteneur pour recharger la configuration.

Pour que notre application IT-Tools soit accessible en HTTPS, sa configuration doit être adaptée. Je vous rappelle que ses labels actuels s’appuient sur l’entryPoint en HTTP. Ouvrez le fichier Docker Compose de l’application, puis ajoutez quatre lignes supplémentaires dans les labels regroupées avec le nom de routeur it-tools-https :

Ces directives configurent le routeur HTTPS de Traefik pour l’application it-tools. L’entrée entrypoints=websecure indique que ce routeur utilise le point d’entrée HTTPS. Le paramètre tls=true active le chiffrement TLS pour sécuriser les connexions. Enfin, tls.certresolver=ovhcloud précise que les certificats TLS/SSL doivent être obtenus automatiquement via le résolveur ACME nommé ovhcloud (nom précisé dans traefik.yml).

Arrêter ce projet et relancez-le (Down/Up).

Il ne reste plus qu’à tester l’accès en HTTPS à l’application : https://it-tools.it-connectlab.fr. Si vous êtes en mode STAGING sur Let’s Encrypt, il y aura bien un certificat mais il n’est pas valide (ce qui est normal). Cela permet de valider le bon fonctionnement de la configuration.

Pour finaliser la configuration, il me semble judicieux de configurer la redirection HTTP vers HTTPS. De ce fait, les applications publiées seront accessibles uniquement au travers d’une connexion sécurisée. Les requêtes HTTP seront redirigées, plutôt que de finir dans le vide…

À ce sujet, il y a une technique évoquée dans la documentation de Traefik et que nous pouvons appliquer. Au sein du fichier traefik.yml, nous allons éviter l’entryPoint web pour ajouter une redirection en HTTPS vers l’entryPoint websecure.

Ce qui correspond à l’ajout de ces lignes :

Vous n’avez plus qu’à relancer le conteneur Traefik et à tester !

Dans le cas où la configuration ne fonctionne pas, vous devez aller faire un tour dans les journaux de Traefik. Par défaut, seules les erreurs sont retournées, ce qui peut être trop limite pour du troubleshooting Traefik.

Ouvrez le fichier traefik.yml et ajoutez ces lignes pour ajuster le niveau de logs. Ici, nous configurons le mode DEBUG qui est le plus verbeux.

Ensuite, arrêtez et relancez le conteneur. Attention, les journaux ne sont pas persistants, donc le redémarrage implique un effacement des journaux.

Consultez les journaux du conteneur Traefik, vous devriez voir de nombreuses informations passer dans la console. Si tout se passe bien, il y aura quand même des informations dans les logs, c’est aussi tout l’intérêt du mode debug.

Je vous encourage aussi à vérifier :

Grâce à ce guide d’introduction à Traefik, vous devriez être capable de mettre en place un reverse proxy dans des environnements basés sur Docker. Vous disposez des bases nécessaires pour bien comprendre le fonctionnement de Traefik, afin de l’adapter à vos besoins et votre contexte.

Pour aller plus loin, consultez la documentation officielle de Traefik et notamment cette page qui regroupe tous les labels Docker. Aimeriez-vous d’autres tutoriels sur Traefik ? N’hésitez pas à partager vos suggestions en commentaire.

Traefik est un reverse proxy et un load balancer qui simplifie la gestion du trafic réseau vers des applications, conteneurs ou services, tout en automatisant la configuration grâce à l’intégration avec Docker, Kubernetes, ou d’autres orchestrateurs. Il a été créé par Émile Vauge, un Français.

Traefik se connecte à un “provider” (tel que Docker ou Kubernetes) et détecte les conteneurs ou services exposés. Il crée automatiquement les routes et règles associées selon les labels configurés. La découverte automatique peut être désactivée pour éviter que des services inappropriés soient exposés. Le provider agit comme une source de configuration dynamique.

Traefik prend en charge Let’s Encrypt et plus particulièrement l’ACME. Ainsi, il peut demander, renouveler et gérer automatiquement les certificats SSL/TLS pour les domaines associés à vos applications, garantissant un accès HTTPS avec un certificat valide et sans configuration complexe.

Oui. Chaque domaine ou sous-domaine peut être routé vers un service différent grâce aux règles (comme Host()) dans la configuration ou via des labels Docker.

Le tableau de bord (Dashboard) de Traefik permet de visualiser en temps réel la configuration active : routes, middlewares, services, certificats et métriques. Il aide au diagnostic et à la supervision du trafic. Mais, il ne permet pas de faire la configuration en ligne : c’est uniquement de la lecture seule.

Les middlewares servent à transformer les requêtes : ajout d’en-têtes, authentification avant de pouvoir accéder à une application, filtrage applicatif (WAF), etc. On peut dire qu’ils ajoutent des capacités supplémentaires à Traefik.

Traefik produit deux types de logs : les access logs (requêtes HTTP) et les logs applicatifs (erreurs, warnings, événements internes). Comme l’explique cet article, il y a notamment un paramètre permettant d’ajuster le niveau de log.

Traefik expose des métriques au format OpenTelemetry et dans des formats adaptés pour des solutions comme Prometheus et InfluxDB2. Il y a également un tableau de bord prêt à l’emploi pour Grafana. Un bloc de configuration metrics: permet d’ajuster la configuration des métriques exposées et leur accès.

– Source :

https://www.it-connect.fr/tuto-traefik-reverse-proxy-avec-docker/

Dans un environnement Docker, certains services ont besoin d’un accès au socket de Docker pour fonctionner correctement, notamment pour consulter l’état des conteneurs Docker en cours d’exécution. Dans ce cas, on peut avoir tendance à aller au plus simple : exposer directement le socket Docker. Malheureusement, cette pratique ouvre la porte à un contrôle total du daemon Docker, et donc de l’ensemble de vos conteneurs. Se pose alors une question : comment exposer de manière sécurisée le Socket Docker ?

Dans ce tutoriel, nous allons voir comment utiliser un proxy pour accéder au socket de Docker pour apporter plus de sécurité aux échanges avec l’API Docker. Pour cela, nous allons utiliser l’image d’un projet nommé docker-socket-proxy qui s’appuie sur une image Alpine et HAProxy pour filtrer les accès à l’API Docker.

Le simple fait de monter docker.sock dans un conteneur lui donne un pouvoir total sur le démon Docker. En disant cela, je référence à ce type d’instruction que nous pouvons retrouver dans les fichiers Docker Compose :

Concrètement, si un attaquant parvient à compromettre ce conteneur, il peut agir sur l’ensemble de votre environnement conteneurisé. Il peut envisager les actions suivantes :

Monter le socket de Docker en lecture seule ne permet pas de se prémunir contre une attaque potentielle : l’attaquant peut créer un conteneur Docker avec un shell au sein duquel il monte la racine du volume système, qui lui ouvrira la voie royale.

C’est précisément pour éviter ce scénario catastrophe que le proxy pour le socket Docker entre en jeu…

Le Docker Socket Proxy joue un rôle d’intermédiaire entre vos applications et Docker. Ainsi, au lieu d’exposer directement docker.sock à vos conteneurs (et risquer le pire), ce proxy agit comme un filtre qui ne laisse passer que ce qui est strictement nécessaire et autorisé selon la configuration. C’est lui qui définit quelles actions sont autorisées.

Dans le cas du projet Docker Socket Proxy que nous allons utiliser, le principe est le suivant :

Vous souhaitez autoriser un accès dans votre proxy ? Vous devez l’autoriser explicitement avec une directive sous la forme suivante : CONTAINERS=1.

Au final, ce proxy est un moyen efficace de concilier praticité et sécurité, sans bouleverser l’architecture existante. Vous n’aurez qu’à effectuer quelques ajustements dans la configuration de vos conteneurs.

Note: la mise en place d’un proxy pour le socket Docker est un très bon moyen de réduire la surface d’attaque de votre système.

Désormais, nous allons passer au déploiement de Docker Socket Proxy dans un conteneur Docker. Vous devez disposer d’une machine sur laquelle Docker est installé et vous y connecter.

Créez un dossier pour ce projet, puis enchainez sur la création du fichier Docker Compose :

Voici le code utilisé pour déployer cette application :

Comme toujours, quelques explications s’imposent :

Nous pouvons constater également la ligne précisée ci-dessous, dont l’objectif est de donner accès à l’endpoint /containers/ de l’API. Il y a un lien entre les variables d’environnement supportées par le proxy et les endpoints présents dans l’API de Docker (voir cette documentation).

Il est important de noter que par défaut, la méthode POST est désactivée ! C’est essentiel d’un point de vue sécurité, car cela signifie que tous les endpoints de l’API sont accessibles en lecture seule. Sinon, un accès à l’endpoint CONTAINERS pourrait, en principe, permettre de créer un conteneur, mais là ce n’est pas le cas.

Vous n’avez plus qu’à lancer la construction du projet :

La suite se passe du côté de vos applications.

Pour commencer, nous allons voir comment configurer Portainer avec le Docker Socket Proxy. Pour rappel, Portainer est une application open source qui facilite l’administration des conteneurs Docker et des éléments associés : volumes, réseaux, images… De ce fait, l’application a besoin d’un ensemble de permissions.

Tout d’abord, dans le fichier Docker Compose de Portainer, vous devez supprimer la liaison avec le socket Docker :

À la place, ajoutez une commande pour connecter Docker via le proxy (attention au nom du conteneur) :

Ce qui donne le fichier docker-compose.yml suivant :

Néanmoins, en l’état, cela ne fonctionnera pas car la configuration de notre proxy est trop restrictive. En effet, nous autorisons uniquement un accès en lecture seule aux conteneurs, ce qui n’est pas suffisant pour Portainer. Il doit pouvoir gérer le réseau, les images, les volumes, etc… Vous devez donc ajuster les permissions de votre proxy pour adopter cette configuration :

L’instruction POST=1 est uniquement utile si vous souhaitez autoriser la création d’éléments via Portainer. Ainsi, nous autorisons les requêtes POST vers les endpoints de l’API qui sont autorisés, donc création / modification de ressources (démarrer/arrêter des conteneurs, créer des services, etc.). Si vous l’utilisez seulement pour de la lecture, ce n’est pas nécessaire d’ajouter cette instruction.

À l’inverse, nous bloquons l’exécution de docker exec via l’API grâce à l’instruction EXEC=0, donc c’est un bon point pour la sécurité. L’idée ici étant de trouver un bon compromis entre sécurité et fonctionnement de Portainer. Nous bloquons aussi les accès sur l’endpoint système avec SYSTEM=0.

Note: rien ne vous empêche de déployer un proxy socket spécifique pour Portainer afin de ne pas ouvrir les permissions pour tous les conteneurs.

Vous pouvez modifier les permissions du proxy à tout moment. Ensuite, en consultant les journaux, vous verrez quelles sont les requêtes autorisées ou refusées en regardant les codes HTTP.

Portainer pourra ensuite se connecter à votre instance Docker par l’intermédiaire de notre proxy (en mode API).

Cette section explique comment utiliser le proxy Socket Docker avec le reverse proxy Traefik. C’est un très bon exemple, car Traefik est souvent couplé avec Docker et il a un accès aux conteneurs Docker, notamment pour lire les informations sur les labels. Ainsi, un accès en lecture seule sur les conteneurs lui suffit pour fonctionner ! Soit la configuration suivante dans le proxy :

Dans le fichier Docker Compose de Traefik, il convient donc de supprimer cette ligne :

Puis, dans le fichier de configuration⁣ traefik.yml, le fournisseur Docker doit être modifié. En principe, vous avez l’instruction endpoint: "unix:///var/run/docker.sock" qui donne un accès direct au socket Docker grâce au volume.

Celle-ci doit être remplacée par une connexion TCP vers le conteneur du proxy sur le port 2375. Ce qui donne :

Une fois l’opération arrêtée, vous devez relancer la construction du conteneur Traefik avec cette nouvelle configuration. Voilà, votre reverse proxy Traefik fonctionne normalement, et en plus, l’accès aux conteneurs est sécurisé.

L’utilisation d’un proxy pour exposer le Socket de Docker est une bonne manière de filtrer les accès entre vos applications et l’API de Docker. Rien ne vous oblige à le faire, mais c’est un plus pour réduire la surface d’attaque de votre hôte Docker, dans le cas où vous utilisez des applications qui “se connectent” au socket Docker.

Le socket Docker donne un accès direct au Docker Daemon, c’est-à-dire au moteur Docker en lui-même. Tout conteneur ou application ayant accès à docker.sock sans contrôle peut créer, modifier ou supprimer des conteneurs, accéder aux volumes, manipuler les réseaux et potentiellement compromettre l’hôte en lui-même.

Le Docker Socket Proxy agit comme un intermédiaire sécurisé (rôle de base du proxy) entre les conteneurs et le démon Docker. Il permet de définir précisément quelles actions sont autorisées (lecture des informations des conteneurs, création de conteneurs, gestion des images, etc.). Cela évite d’exposer le socket brut et réduit considérablement les risques d’escalade : la surface d’attaque est maîtrisée.

Oui. Il peut limiter les permissions liées à Docker Swarm. Cela implique d’ajuster la configuration du proxy pour autoriser les endpoints nécessaires (SERVICES, TASKS, NETWORKS, etc.).

Oui, à condition de configurer précisément les endpoints autorisés : des tests approfondis peuvent s’avérer nécessaires pour bien identifier les besoins de certaines applications. Le Docker Socket Proxy permet de respecter un principe de moindre privilège, essentiel dans une architecture Docker en production.

– Source :

https://www.it-connect.fr/docker-comment-ameliorer-la-securite-avec-un-docker-socket-proxy/

Alternative intéressante. Il faut reconnaître que la gestion Portainer sur smartphone est une vraie tannée, il faut zoomer pour cliquer au bon endroit, puis dézoomer pour voir plus large…
Ce qui pourrait m’empêcher de basculer, outre le problème des droits que tu mentionnes, c’est la confiance. En effet, ce type d’app nécessite un accès étendu au socket Docker, droit sensible que je n’accorde sur sur des outils répandus, reconnus et donc supposés fiables. C’est le cas pour Portainer, est-ce aussi le cas pour Arcane ?

Je ne sais pas vraiment, je n’ai pas trop suivi

Si ça fait du webRTC, c’est du SIP over websocket… ce n’est donc carrément pas mieux que Zoom ou Teams…

Sorry Docker, y’a un nouveau sheriff en ville ! Apple vient de lâcher un bombe à la WWDC 2025 avec son outil de containerisation natif pour macOS 26, et franchement, ça sent le roussi pour Docker. Fini les galères de performance, les ressources qui partent en vrille et les contournements foireux pour faire tourner vos containers Linux sur machine Apple ! Cool, hein ?

Si vous développez sous Mac, vous connaissez le refrain : Docker Desktop qui bouffe la RAM comme un goret (facilement 4-5 Go en idle), des performances de container dignes d’un Pentium II sous Windows ME, et cette sensation permanente que votre MacBook M3 Ultra à 4000 balles se comporte comme un Raspberry Pi dès qu’il s’agit de faire du container.

Et bien c’est fini tout ça, parce qu’Apple a décidé de reprendre les choses en main avec son framework Containerization écrit en Swift et taillé spécialement pour l’Apple Silicon.

L’outil s’appelle sobrement “Container” et c’est optimisé, et surtout natif. Le truc qui change tout c’est que c’est totalement compatible OCI, donc vos images Docker existantes fonctionnent sans modification. Vous pouvez pull depuis Docker Hub, push vers n’importe quel registry standard, et même faire tourner vos stacks existantes sans rien changer.

–Interface du CLI Apple Container en action

Apple utilise son framework Virtualization.framework pour créer des VM minimalistes qui ne font que ce qu’il faut. Chaque container tourne dans sa propre bulle sécurisée, avec une isolation qui ferait rougir les solutions concurrentes. Et comme tout est optimisé pour les puces Apple Silicon, les performances sont juste hallucinantes. Plus de virtualisation lourde, plus de couche d’abstraction qui bouffe vos ressources… juste des machines virtuelles ultra-légères qui tournent comme des moteurs de fusée.

D’abord, il vous faut macOS 26 Beta 1 minimum pour profiter de toutes les fonctionnalités (même si ça fonctionne sur macOS 15, Apple recommande la beta). Ensuite, un Mac avec Apple Silicon obligatoire car les Intel, c’est mort, Apple a définitivement tourné la page sur cette architecture pour les nouveautés.

Pour l’installation, direction le GitHub officiel d’Apple. Le projet est open source avec une licence Apache 2.0, ce qui montre qu’Apple comprend l’importance de l’écosystème pour les développeurs. Vous téléchargez le package signé depuis la page des releases, et là, respect à Apple, pas de brew install hasardeux ou de compilation depuis les sources, c’est du package propre qui s’installe sous /usr/local avec les bonnes permissions.

Une fois installé, ouvrez votre Terminal favori et tapez container --help pour voir si tout fonctionne. Si vous voyez le help s’afficher avec la liste des commandes disponibles, c’est que vous êtes prêt pour la suite.

Première étape : démarrer le service. Apple a pensé à tout avec un système de démarrage propre :

Si c’est votre première utilisation, l’outil va vous demander d’installer un kernel Linux. Pas de panique, c’est normal et c’est même plutôt malin : Apple récupère automatiquement un kernel optimisé depuis les dépôts officiels. Vous dites oui, vous attendez quelques secondes, et voilà.

Pour vérifier que tout roule, listez vos containers avec :

Normal si c’est vide pour l’instant, on n’a encore rien créé.

Maintenant, testons avec quelque chose de simple. Lançons un petit serveur web Nginx :

Cette commande vous balance toutes les infos de votre container, y compris son adresse IP. Collez cette IP dans votre navigateur avec le port 80, et normalement vous devriez voir la magnifique page d’accueil Nginx qui dit ‘Welcome to nginx!’.

Le plus impressionnant, c’est les performances. Là où Docker Desktop galère et transforme votre Mac en radiateur électrique, l’outil d’Apple reste d’un calme olympien. La consommation mémoire est ridicule comparée à ce qu’on avait avant, et niveau CPU, on sent vraiment la différence. Les VM sont créées à la demande, utilisent juste ce qu’il faut de mémoire, et se ferment proprement quand vous avez plus besoin du container. Apple a optimisé chaque ligne de code pour tirer parti de l’architecture ARM et de la virtualisation hardware des puces Silicon.

L’autre point fort, c’est l’intégration système. Plus besoin d’une appli séparée qui squatte vos ressources en arrière-plan comme un parasite. Le framework Containerization est intégré directement dans macOS, ce qui veut dire que vos containers démarrent plus vite, consomment moins, et s’intègrent mieux avec le reste de votre système.

Plus de dépendance à des solutions tierces, plus de frais de licensing pour Docker Desktop en entreprise, juste un outil natif qui fait exactement ce qu’on attend de lui. Et accessoirement, qui respecte votre batterie et vos cycles CPU. Côté fonctionnalités, Apple a pensé à l’essentiel. Vous pouvez builder vos images avec container build, les pousser sur vos registres avec container push, et même faire du multi-architecture avec les flags --arch arm64 --arch amd64. Bref, tout ce qu’il faut pour un workflow de dev moderne.

Et là où Docker Desktop vous balance une interface graphique avec 50 onglets et des settings dans tous les sens, Apple a opté pour un CLI épuré mais puissant. Stratégiquement, c’est énorme pour Apple car après avoir bouffé une partie du marché des éditeurs de code avec Xcode et les outils de dev natifs, voilà qu’ils s’attaquent maintenant à Docker. C’est un signal fort envoyé aux développeurs : “Restez dans l’écosystème Apple, on a tout ce qu’il vous faut.”

Le timing n’est pas anodin non plus. Avec la montée en puissance des Mac M1/M2/M3 dans les environnements de développement, Apple positionne son outil comme LA solution native pour faire du développement cross-platform. Plus besoin d’émulation x86, plus de compromis sur les performances puisque tout tourne nativement sur ARM64 avec une efficacité énergétique qui laisse Docker sur le carreau.

Bon, c’est pas non plus la révolution absolue hein. On reste sur de la containerisation Linux classique, avec les mêmes contraintes et limitations. L’outil est encore en beta et il manque quelques fonctionnalités avancées qu’on trouve dans Docker Desktop. Docker a des années d’avance sur l’écosystème, les outils, et la documentation.

Si vous bossez sur Mac et que vous en avez marre des performances pourries de Docker Desktop, je vous conseille vraiment de tester l’outil d’Apple. C’est gratuit, c’est open source, et ça marche déjà plutôt bien pour un outil en beta. Au pire, vous pourrez toujours revenir à Docker si ça vous convient pas, mais j’ai comme l’impression que beaucoup de devs vont faire le switch définitivement.

Allez-y, téléchargez macOS 26 Beta 1, installez l’outil Container, et faites-vous votre propre opinion. Dans six mois, on en reparle et on verra si Apple a réussi son pari de détrôner Docker sur Mac.

–Sources :

https://github.com/apple/container

https://korben.info/apple-container-swift-revolution-docker.html

Si votre site web est devenu le buffet à volonté préféré des bots de sociétés IA, débarquant par milliers, se servant dans votre bande passante et repartant sans même dire vous laisser un mot sur l’oreiller, alors j’ai une solution pour vous ! Ça s’appelle Anubis et c’est un outil qui vérifie si vos visiteurs sont de vrais humains ou des aspirateurs à données déguisés.

Car oui, personne n’est épargné ! Par exemple, le bon vieux site kernel.org a dû mettre en place une protection contre ces scrapers qui menaçaient sa disponibilité et ce n’est pas un cas isolé. Codeberg, ScummVM, FreeCAD et même certains sites de l’ONU ont adopté la même solution pour rester en ligne face à cette nouvelle forme de DDoS “légitime”.

Bref, pendant que vous lisez ces lignes, une bataille fait rage avec d’un côté, les développeurs qui maintiennent des sites utiles à la communauté et de l’autre, des armées de robots envoyés par les géants de l’IA pour aspirer tout le contenu possible afin d’entraîner leurs modèles.

Bien sûr, Cloudflare et autres services similaires peuvent vous aider, mais ils créent une dépendance à des intermédiaires centralisés, contraires à l’esprit même du web. Et franchement, si vous hébergez un petit projet open-source, vous n’avez probablement pas envie de payer pour une protection contre un problème que vous avez pas créé.

Heureusement, Anubis est là et s’inspire d’une idée plutôt ancienne : Hashcash
Il s’agit d’une idée remontant aux années 2000 pour lutter contre le spam email. Le principe est simple et génial à la fois : imposer un petit coût “computationnel” à chaque requête. Grosso merdo, comme mettre un péage sur une route qui serait insignifiant pour un conducteur occasionnel, mais super ruineux pour une entreprise qui fait passer des milliers de camions par jour.

Voici comment ça marche concrètement :

Pour un navigateur moderne sur un PC normal, ce calcul prend quelques secondes, ce qui en fait une petite friction acceptable. Mais pour un scraper industriel qui doit traiter des millions de pages… c’est une autre histoire. Et ce système est totalement configurable puisqu’il permet d’ajuster la difficulté (nombre de zéros requis, par défaut 4-5), d’utiliser un algorithme intentionnellement lent pour punir les bots identifiés, et de créer des règles personnalisées via des expressions régulières et un langage d’expression appelé CEL.

Voici par exemple une règle permettant d’autoriser les requêtes API tout en bloquant le reste :

Ou encore, bloquer spécifiquement les bots d’Amazon :

La bonne nouvelle, c’est qu’Anubis est ridiculement simple à mettre en place. Un VPS basique avec Docker suffit amplement et l’outil consommera moins de 32 Mo de RAM en moyenne, autant dire rien du tout à l’échelle d’un serveur récent.

La méthode la plus simple pour mettre Anubis en place, c’est comme d’hab : Docker Compose. 5 lignes de config et vous êtes protégé :

Et si vous préférez les packages natifs, sachez qu’Anubis est disponible pour Debian, Ubuntu, RHEL et autres distributions populaires. Les plus bidouilleurs peuvent même l’installer depuis les sources.

La configuration avec les serveurs web les plus courants est bien documentée :

Une fois tout configuré, vérifiez quand même que tout fonctionne correctement en visitant votre site. Et si vous voyez la jolie page de challenge la première fois, puis accédez normalement au site après, c’est que tout est bon !

Si vous hésitez, sachez que avantages d’Anubis sont nombreux :

Mais il y a aussi des arguments plus émotionnels, et tout aussi valables :

Par contre, sachez que :

Mais comparé aux alternatives commerciales, le rapport bénéfice/contrainte penche largement en faveur d’Anubis.

Bref, si vous en avez marre de voir votre bande passante dévorée par des bots trop gourmands, c’est le moment d’agir. Quelques minutes de configuration aujourd’hui pourraient vous épargner des heures de maintenance demain.

Et si vous avez des questions sur l’installation ou la configuration, n’hésitez pas à consulter la documentation officielle. Et un grand merci à Lorenper pour le partage !

– Source :

https://korben.info/anubis-protection-site-web-bots-ia.html

Ba on va dire que le serveur le supporte largement, mais largement. C’est sur qu’il faut doser, si t’es limite tu évites sinon lâche les chevaux.

L’intérêt d’un WAF n’est plus à faire non plus… N’importe quel adminsys compétent te le dira.
Puis bon, on est plus sur du pentium 4. On peut faire relativement pas mal de choses.

Si ta machine le supporte, il n’y a aucune raison valable de se priver de sécurité, bien au contraire. Ce serait suicidaire de ne pas le faire.

Vous en avez marre de galérer avec Plex ou Jellyfin pour streamer vos films et séries ? Alors laissez-moi vous présenter Kyoo, un petit nouveau dans la cour des media centers open source qui risque bien de vous faire de l’œil !

Kyoo, c’est un peu comme si Plex et Jellyfin avaient eu un bébé bourré de fonctionnalités bien pensées. Déjà, son crédo, c’est la simplicité. Une fois installé, vous pouvez dire adieu aux prises de tête pour gérer votre bibliothèque multimédia. Il scanne automatiquement vos fichiers et hop, magie, tout est ajouté sans effort. Pas besoin de renommer vos fichiers ou de suivre une structure de dossiers précise, puisqu’il est suffisamment futé pour s’y retrouver.

Côté fonctionnalités, il offre du transcodage dynamique qui vous permet de streamer dans la qualité que vous voulez, en changeant à la volée grâce à l’auto qualité. Vous pouvez même faire des seek sans attendre que le transcodeur rattrape son retard. Et l’historique automatique garde une trace de ce que vous avez maté, avec une fonction “continuer à regarder” bien pratique pour reprendre direct là où vous vous étiez arrêté.

Pour les métadonnées, Kyoo utilise la puissance de guessit et themoviedb pour récupérer les infos de vos fichiers, même si les noms sont un peu exotiques. Et pour les animes, il utilise thexem pour gérer ça comme un pro. Vous pouvez accéder à Kyoo sur Android et sur le web, pour streamer de partout, la recherche est hyper rapide grâce à Meilisearch et vous avez même le support du fast scrubbing pour naviguer dans vos médias à toute berzingue.

Un truc bien cool aussi, c’est que vous pouvez télécharger vos médias pour les regarder hors-ligne, et votre historique se synchronise quand vous êtes de nouveau en ligne. Il gère les sous-titres comme un chef, avec le support des formats SSA/ASS et des polices personnalisées et vous pourrez vous connecter avec vos comptes Google, Discord ou autre via OIDC, et marquer automatiquement vos épisodes comme vus sur des services comme SIMKL.

Techniquement, là où Plex et Jellyfin entassent tout dans un seul conteneur avec SQLite, lui n’hésite pas à séparer les composants dans des conteneurs dédiés quand c’est pertinent, comme pour la recherche avec Meilisearch ou le transcodage. Ça permet une meilleure scalabilité et d’exploiter pleinement les avantages de chaque brique logicielle.

Comme ça plus de prise de tête pour configurer et maintenir votre serveur de streaming. Une fois en place, il se fait oublier et vous laisse profiter de vos films et séries sans friction. Si vous voulez voir Kyoo en action, foncez voir la démo sur https://kyoo.zoriya.dev qui propose des films libres de droits.

Et si jamais vous avez des questions ou besoin d’aide pour installer et configurer Kyoo, n’hésitez pas à consulter la doc ou à rejoindre la communauté sur Discord https://discord.gg/E6Apw3aFaA.

– Source :

https://korben.info/kyoo-alternative-open-source-plex-jellyfin-streaming.html

– Pour l’installation sous Docker allez voir ici :

https://belginux.com/installer-kyoo-avec-docker/

text alternatif

La définition de « cloud » a vraiment évolué ces dernières années. On est passé de :

« Je vais mettre tous mes fichiers dans le cloud de Google et d’Amazon »

à :

« Je me suis monté un serveur de cloud personnel »

Cela n’a plus aucun sens, mais on va faire comme si de rien n’était. Partons du principe que dans la tête des gens, aujourd’hui, cloud ça veut dire stockage personnel ou quelque chose comme ça.

Bref, si je vous dis tout ça c’est surtout pour vous présenter CasaOS, un logiciel open source qui vous propose de créer votre cloud à la maison. Oui, lol. N’empêche l’outil est cool puisqu’il vous permet grâce à Docker de déployer et gérer facilement tous vos usages personnels.

Logo de CasaOS, le système d'exploitation pour le cloud personnel

Ainsi, vous pouvez remplacer Dropbox, eBay, Google Drive ou encore Netflix par Syncthing, Bazaar, Nextcloud ou encore Plex très facilement, sans avoir à taper une seule ligne de commande. Vous l’aurez compris, l’idée c’est justement de vous passer du cloud pour héberger à nouveau votre contenu chez vous à l’aide d’applications qui ont fait leurs preuves (j’en ai présenté la plupart sur ce site d’ailleurs).

Avec CasaOS, vous pourrez gérer toutes vos données et vos usages depuis votre ordinateur ou votre smartphone et à terme, l’outil encore un peu jeune, vous permettra également de gérer vos scénarios domotique, de stocker les vidéos de vos caméras de surveillance ou de récupérer les infos d’un tas de matériel IoT.

CasaOS fonctionne sous Linux, mais a surtout été testé sous Ubuntu, mais également Raspberry Pi OS Bullseye, ce qui est une bonne nouvelle si vous avez un Raspberry Pi.

Pour l’installer, il suffit d’entrer la commande suivante dans votre terminal :

Si cela vous intéresse, une démo est disponible ici (mot de passe: casaos)

Source : korben.info

Merci du partage d’info. On peut y éditer directement un compose ?

pngfind.com-starbound-logo-png-5378357.png

– Portainer vous permets de gérer Docker dans une interface web.

– Portainer lui-même se lance en tant que container Docker, très léger avec ses 4 Mo seulement.

– D’abord, il faut créer/monter le socket local de docker en tant que volume Docker , vous pouvez le voir comme un partage qui sera monté dans votre conteneur.

Si vous ne créez pas ce volume, à chaque redémarrage de votre conteneur toutes les données seront effacées pour revenir à l’état initial. C’est ce volume que vous devez sauvegarder à minima. Bref, vous pouvez le créer comme ça:

– Puis on créé simplement le conteneur pour Portainer :

– L’accès via l’URL suivante:

http://ip.de.votre.machine:9000

– Une fois sur l’interface, paramétrer le mot de passe admin:

38a0107e-7fac-4b1a-a4d2-bc7f97aa70aa-image.png

– La prochaine étape est de configurer l’environnement Docker sur lequel se connecter et que Portainer pourra gérer.

– Ici, nous allons sélectionner Docker-Manage the local Docker environment (on a déjà monté le socket Docker en tant que volume.)
et on clique sur Connect:

1f653289-a323-435b-b94d-ef13a0f6f926-image.png

– On se retrouve connecté sur l’interface d’accueil, le dashboard, où vous aurez un résumé des environnements Docker que Portainer peut administrer.

– En cliquant dessus, vous accéderez aux différentes fonctions de gestion des images, des containers, des stacks, …
– Il suffit de cliquer sur local ci-dessous pour lister vos dockers disponibles :

28cee6e0-c46b-4ddf-b2ca-48a5f2b61d4f-image.png

– Vous pouvez afficher, les containers Docker que vous avez déjà sur votre hôte en cliquant sur containers :

5fa2d29f-1e47-4888-a702-b13395a153e6-image.png

– On retrouve alors les 2 conteneurs que l’on a mis en place:

f9d6e028-6192-48c8-96f2-72da96e11466-image.png

ou

– On stoppe le conteneur docker :

– On redémarre nginx:

– On redémarre le conteneur docker :

– Accès HTTPS en reverse proxy:

https://XXX.XXX/portainer/