Hey mais on dirait bien que c'est Red Hat qui débarque sur le marché des apps desktop pour conteneurs... mais lol ! Car oui, pendant que Docker Desktop trône depuis des années et qu'OrbStack séduit de plus en plus d'utilisateurs macOS, Red Hat se réveille ENFIN avec sa propre version Enterprise de Podman Desktop .
Bah mieux vaut tard que jamais !
Pour ceux qui débarquent (bouuuuh) Podman Desktop, c'est un outil open source qui existe depuis des années pour gérer vos conteneurs, images et pods via une interface graphique. C'est dispo sous Linux, macOS, Windows et le projet a même rejoint la CNCF (rien à voir avec les trains... lool) en janvier 2025 en même temps que d'autres briques Red Hat (Buildah, Skopeo, bootc, Composefs... chacun en projet séparé).
Interface de Podman Desktop
Et donc Red Hat a décidé de lancer sa propre "build" enterprise de cette app de conteneurs. En gros, c'est la même base que Podman Desktop, mais avec une couche admin par-dessus. Les responsables IT peuvent donc verrouiller des paramètres au niveau de la flotte tels que les registry mirrors, proxies HTTP, certificats custom... On est dans une ambiance un peu plus corporate quoi.
Côté Kubernetes, c'est également plutôt bien pensé. Vous créez vos pods en local, l'outil génère le YAML correspondant, et hop, déploiement sur Kind, Minikube ou directement sur OpenShift, les doigts dans le nez.
Pour ceux qui se demandent si ça remplace Docker Desktop, bah, ça dépend en fait. Podman tourne sans daemon et en rootless, du coup c'est un vrai plus côté sécurité. Mais par contre, le support Docker Compose passe par un système d'aliasing... ça marche bien, sauf si vous avez des configs Docker très exotiques... là faudra tester avant de tout basculer comme le early adopter fifou que vous êtes.
D'ailleurs, si vous êtes sur RHEL, Podman est déjà inclus dans votre abonnement et Red Hat a aussi bossé sur des extensions pour les images bootable OCI et le mode image RHEL.
Le truc, c'est que Red Hat arrive tard. TRÈS tard. Docker Desktop, c'est le standard de facto depuis des lustres, OrbStack a conquis les devs macOS avec sa légèreté sans oublier que Rancher Desktop et Portainer Business Edition occupent aussi le terrain. Du coup, leur stratégie c'est de cibler les boîtes déjà full Red Hat plutôt que d'essayer de convertir les utilisateurs Docker. C'est une ambition plutôt réaliste, je trouve.
Ça vient donc de passer en disponibilité générale via les canaux développeurs Red Hat, c'est gratuit, open source, et plutôt bien fichu pour ceux qui bossent dans un environnement RHEL au quotidien. Après, c'est pas non plus la révolution car ça reste Podman Desktop avec un petit chapeau d'entreprise.
Je pense que pour un usage hors Red Hat, Docker Desktop ou OrbStack restent devant. Mais si vous avez l'abonnement RHEL, ça peut valoir le coup d'y jeter un oeil.
Si vous avez déjà eu besoin de montrer une app en dev à un client ou de tester un webhook Stripe sans vous farcir une config nginx, y'a de fortes chances que vous connaissiez ngrok .
Hé bien Tunnelto fait sensiblement la même chose, mais en Rust et avec un truc en plus qui fait la différence : un dashboard d'introspection pour voir tout ce qui passe dans le tunnel.
Du coup, vous lancez une commande, vous récupérez une URL publique genre votresite.tunnelto.dev, et hop, votre localhost devient accessible depuis n'importe où. Et surtout, vous pouvez inspecter toutes les requêtes HTTP qui transitent. Super utile quand vous débuguez une API ou que vous essayez de comprendre pourquoi ce foutu webhook ne se déclenche pas.
Pour l'installer, plusieurs options s'offrent à vous :
Sur macOS via Homebrew :
Connexionbrew install agrinman/tap/tunnelto
Via Cargo :
cargo install tunnelto
Et pour exposer votre app qui tourne sur le port 8000 :
tunnelto --port 8000
C'est tout ! Le service vous file une URL avec un sous-domaine aléatoire. Mais si vous voulez quelque chose de plus mémorable, vous pouvez demander un sous-domaine custom :
tunnelto --port 8000 --subdomain monprojet
Et vous obtenez monprojet.tunnelto.dev. Pas mal pour une démo client, non ?
Bon, si vous avez suivi mes articles sur Bore ou Tunnl.gg , vous vous demandez peut-être la différence. Bore est ultra-minimaliste, Tunnl.gg ne nécessite même pas de client à installer... Tunnelto se situe entre les deux : plus complet que Bore avec son dashboard d'introspection, mais plus léger que ngrok avec son approche open source.
D'ailleurs, y'a un truc cool avec Tunnelto c'est que vous pouvez héberger votre propre serveur si vous ne voulez pas dépendre d'un service tiers. Pratique pour les entreprises qui veulent garder le contrôle sur leurs tunnels. Sous le capot, ça utilise également tokio pour l'async Rust, donc c'est rapide et ça consomme que dalle en ressources.
Bref, si ngrok vous paraît trop usine à gaz et que Bore manque de fonctionnalités pour vous, Tunnelto fera bien le taf surtout avec son module d'inspection du trafic HTTP, qui fait la diff quand on débugue des intégrations...
Le dossier .github est un petit répertoire magique que vous avez sûrement déjà croisé à la racine de vos dépôts préférés. Il est là, non pas pour faire joli ou pour planquer vos secrets de fabrication (pour ça, y'a les secrets GitHub, hein), mais plutôt pour centraliser plusieurs fichiers de configuration reconnus nativement par la plateforme.
C'est un peu le centre de commande de votre repo. Et le truc qui est fort, c'est que si vous avez une organisation avec 50 projets, vous pouvez même créer un dépôt public spécial nommé .github qui servira à fournir des fichiers de santé communautaire et des templates par défaut pour tous les dépôts de votre organisation qui n'ont pas déjà leurs propres fichiers équivalents.
Et comme ça, dès qu'un dépôt a quoi que ce soit dans son propre .github/ISSUE_TEMPLATE/, il ne prendra plus les templates par défaut de l'orga.
Pratique pour les grosses flemmasses comme vous quoi !
On a tous reçu une issue qui dit juste "ça marche pas". C'est relou, ça fait perdre du temps et on a envie de répondre par un gif de chat qui boude.
Alors pour éviter ça, créez un dossier .github/ISSUE_TEMPLATE/. Vous pouvez y coller des fichiers Markdown ou YAML pour encourager les gens à donner les infos de base (version de l'OS, étapes pour reproduire, etc.). Et faites pareil pour les Pull Requests avec un fichier PULL_REQUEST_TEMPLATE.md (à la racine, dans docs/, ou dans .github/, selon votre tambouille).
En gros, ça vous permet de guider vos contributeurs pour qu'ils ne fassent pas n'importe quoi.
C'est LE grand classique !
Dans .github/workflows/, vous balancez vos fichiers YAML pour automatiser vos tests, votre linting ou vos déploiements. Bien sûr, pour vraiment ne pas "casser la prod", il faudra coupler ça à des règles de protection de branche (status checks requis) pour bloquer les merges si les tests échouent.
D'ailleurs, si vous voulez tester vos actions sans attendre la file d'attente des runners GitHub, je vous avais parlé de Wrkflw pour tester ça en local . C'est un outil tiers bien pratique pour valider vos workflows sur votre machine.
Si vous voulez que votre projet open source ressemble à autre chose qu'un champ de bataille au petit matin, il faut poser des règles.
GitHub reconnaît automatiquement des fichiers comme CODE_OF_CONDUCT.md, CONTRIBUTING.md ou même FUNDING.yml pour gratter quelques pièces pour votre café ;). Ce sont des fichiers qui aident à dire aux gens comment se comporter et comment vous aider efficacement sans avoir à surveiller votre voisin.
C'est la petite nouveauté qui vous permet d'ajouter un fichier .github/copilot-instructions.md avec à l'intérieur, une liste de vos standards de code, vos libs préférées ou vos conventions de nommage.
Comme ça, hop, Copilot tiendra compte de ces instructions pour ses suggestions (même s'il garde parfois son petit caractère, hihi). Et vous pouvez même aller plus loin avec des fichiers NAME.instructions.md dans .github/instructions/ qui ciblent des dossiers specifiques via des patterns glob... à condition de mettre un frontmatter applyTo: au début, sinon Copilot les ignorera gentiment...
C'est parfait pour garder un code propre.
Enfin, pour les projets qui commencent à prendre de l'ampleur, le fichier CODEOWNERS (placé dans .github/, ou à la racine, ou dans docs/... GitHub prend celui de .github/ en premier s'il y en a plusieurs) permet de définir qui est responsable de quelle partie du code. Dès qu'une PR touche à un fichier sensible, GitHub demande automatiquement la review aux bonnes personnes.
Et n'oubliez pas .github/dependabot.yml pour que l'outil vous ouvre des pull requests dès qu'une dépendance est à la bourre.
On automatise le bien relou pour ne garder que du criss de fun !
Voilà les amis, si vous aimez bidouiller vos dépôts pour qu'ils tournent tout seuls ou presque et garder un semblant d'organisation, ce dossier .github sera votre meilleur poto !
Bonne nouvelle pour tous les dev qui n'ont pas peur de l'IA : GitHub vient de sortir gh-aw, une extension CLI qui permet d’écrire des workflows agentiques… en markdown. Au chiotte le YAML à rallonge pour vos pipelines CI/CD, vous rédigez vos instructions en langage naturel et c'est une IA (Copilot, Claude ou Codex au choix) qui se charge de les exécuter dans GitHub Actions.
En gros, vous décrivez ce que vous voulez dans un fichier .md, genre"em>fais-moi un rapport quotidien des issues ouvertes" ou "refactorise les fonctions trop longues", et l'agent s'en occupe. Il analyse le contexte de votre dépôt, prend des décisions et livre le résultat sous forme de pull request. Par contre, attention, si votre prompt dans le fichier .md est trop vague genre "améliore
le code
", l'agent risque de partir dans tous les sens et vous pondre une PR de 200 fichiers. Faut être précis dans vos instructions, sinon c'est la loterie.
Côté sécurité, ils ont pas rigolé parce que lâcher une IA en roue libre sur votre code, ça pourrait vite tourner au cauchemar (J'en avais d'ailleurs parlé avec les backdoors planquées dans les fichiers de config ). Ici, tout est sandboxé avec des permissions en lecture seule par défaut sur le runner. Les opérations d’écriture passent par des "safe-outputs" préapprouvés, y'a de l'isolation réseau, du pinning SHA sur chaque dépendance npm/pip… Bref, ils ont pas fait les choses à moitié, côté garde-fous.
Côté moteurs IA, vous avez le choix entre GitHub Copilot, Claude d'Anthropic (via l'API, faut un compte payant), OpenAI Codex ou même votre propre processeur custom. Claude pour du refactoring ça peut être pas mal je pense parce que la fenêtre de contexte est capable d'avaler un dépôt entier, mais pour du triage d'issues, Copilot suffira largement. Comme d'hab, ça dépend de vos besoins (et de votre portefeuille).
Coolify, c'est un PaaS open source que vous installez sur vos propres serveurs pour déployer vos apps, vos bases de données et vos services... sans vous farcir Docker à la main. En gros, un Heroku ou un Vercel, mais en version self-hosted sans enfermement propriétaire comme on pourrait dire en bon français.
La version auto-hébergée est donc TOTALEMENT gratuite. Pas de limite sur le nombre de serveurs, pas de restriction sur les features, pas de "ah pour les teams faut upgrader". Y'a R comme disait mon grand-père... Vous avez SSH sur une machine ? Ça suffit. VPS, Raspberry Pi, dédié, vieux laptop qui traîne dans un coin... Hop, une seule commande et c'est installé.
Côté déploiement, Coolify détecte automatiquement votre stack via Nixpacks (c'est-à-dire qu'il devine le langage et génère le build tout seul). Mais vous pouvez aussi balancer un Dockerfile, un Docker Compose ou un simple site statique. Du coup, que vous bossiez en Next.js, Django, Laravel, Rails, Phoenix ou SvelteKit, ça passe sans config particulière.
Pour les bases de données, c'est pas mal non plus : PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse... tout se déploie en quelques clics. Et au total, le catalogue compte plus de 280 services one-click (Plausible, Gitea, Minio, n8n, et j'en passe). Y'a de quoi monter une infra complète avant même d'ouvrir un terminal.
Le workflow Git est solide puisque c'est du push-to-deploy avec GitHub, GitLab, Bitbucket ou Gitea, avec en prime des déploiements de preview par pull request. Pratique pour tester une branche avant de tout péter en prod (ouais, je vous connais...). Vous avez aussi les webhooks, une API REST documentée, et un terminal temps réel directement dans le navigateur.
Côté ops, les certificats SSL sont automatiques via Let's Encrypt, les backups de vos bases partent vers du stockage S3 compatible , et vous avez du monitoring intégré avec alertes Discord, Telegram ou email. Ça permet de dormir tranquille le vendredi soir. Pour le multi-serveur, Coolify supporte aussi Docker Swarm, donc vous pouvez répartir la charge sur plusieurs machines sans trop de prise de tête.
Si vous voulez pas gérer l'instance Coolify vous-même, y'a Coolify Cloud à 5$/mois (2 serveurs inclus, +3$ par serveur supplémentaire). Vos apps tournent toujours sur VOS machines et c'est juste le dashboard qui est hébergé chez eux. Pour les allergiques à l'admin système, ça peut valoir le coup.
Pour installer Coolify, il vous faut un serveur Linux (Ubuntu LTS recommandé, mais Debian, CentOS, Fedora, Alpine ou même Raspberry Pi OS 64-bit passent aussi), avec au minimum 2 coeurs, 2 Go de RAM et 30 Go de stockage. Un accès SSH root est requis.
L'install tient en une ligne :
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
Le script pose Docker, configure les clés SSH, crée les répertoires dans /data/coolify et démarre le tout. À la fin, il vous affiche l'URL de votre dashboard, généralement http://VOTRE_IP:8000. Premier réflexe : créez votre compte admin TOUT DE SUITE (car le premier qui tombe sur la page d'inscription prend le contrôle du serveur...).
Une fois connecté, la logique est simple. Vous créez un Projet (le conteneur logique de votre app), puis un Environnement dedans (dev, staging, prod...). Ensuite, vous ajoutez une Ressource, c'est-à-dire votre app, votre base de données ou un des 280 services one-click.
Pour déployer un repo Git, vous branchez votre compte GitHub, GitLab ou Gitea, vous sélectionnez le repo et la branche, et Coolify détecte le build pack adapté (Nixpacks, Dockerfile ou Compose). Vous configurez votre domaine, le reverse proxy (Traefik ou Caddy au choix) gère le SSL automatiquement, et hop... git push, c'est déployé.
Si vous voulez ajouter des serveurs distants, même principe : clé SSH, connexion root, et Coolify valide que tout est OK. Chaque serveur a son propre proxy, donc le trafic va directement dessus sans passer par le serveur principal. Pensez juste à pointer vos DNS vers le bon serveur.
Pour ceux qui explorent les alternatives, Dokploy est plus minimaliste (et plus récent), et Tipi reste centré sur les applis grand public type Nextcloud ou Plex. Coolify, c'est plutôt le couteau suisse du dev qui veut TOUT contrôler sur son infra.
Bref, si Docker Compose c'est plus votre truc, Coolify mérite clairement un petit test.
Merci lorenper !
VirtualBox, le bon vieux logiciel de virtualisation d'Oracle, vient de franchir un cap plutôt inattendu. Le code de développement supporte désormais KVM comme backend sur Linux ! En gros, au lieu de s'appuyer uniquement sur son propre module noyau (qui, soyons honnêtes, a toujours été un poil galère à maintenir), l'outil de virtualisation peut maintenant utiliser l'hyperviseur natif de Linux.
Et c'est pas rien quand on sait que le logiciel d'Oracle et KVM se marchaient dessus depuis des années. C'était impossible de faire tourner les deux en même temps... Du coup, plutôt que de continuer à se battre, Oracle a décidé de faire copain-copain avec KVM. C'est pas bête !
L'idée vient à l'origine de Cyberus Technology qui avait pondu une implémentation open source en 2024. Et aujourd'hui, c'est Oracle qui intègre le truc directement dans le code officiel. Alors pour l'instant, c'est dispo uniquement en version de dev dans les dépôts Git et les builds de test et ça fonctionne "à peu près".
Vous pouvez dès à présent activer le backend KVM quand le module noyau classique de VirtualBox refuse de coopérer. C'est pratique mais attention par contre, si vous avez besoin du réseau NAT avancé ou du mode pont avec VLAN, ça passera pas encore via KVM... faudra rester sur le module maison.
Notez aussi que l'hyperviseur maison d'Oracle garde quand même des avantages notamment pour tout ce qui est modes réseau avancés, émulation précise pour les vieux OS, et émulation fine de périphériques.
Mais n'empêche, la tendance est claire, tout le monde converge vers l'hyperviseur du noyau Linux. Faut dire que QEMU/KVM c'est devenu tellement solide ces dernières années que ça n'a plus trop de sens de réinventer la roue dans son coin.
Voilà, donc pour ceux qui utilisent l'outil d'Oracle au quotidien sur Linux, c'est une bonne nouvelle. Moins besoin de jongler avec le module vboxdrv, moins de conflits avec d'autres solutions de virtualisation , et surtout des mises à jour noyau qui cassent moins souvent.
Bref, gardez un œil sur les prochaines releases car Oracle a l'air d'y aller sérieusement. Le support KVM final et officiel devrait atterrir pour tous dans une version stable courant 2026. J'ai hâte !
Brice, un lecteur de Korben, m'a bel et bien scotché. Il y a quelques semaines, je vous parlais du Pineapple Pager et ça a visiblement réveillé une fibre nostalgique chez certains d'entre vous. Donc merci à Brice pour l'info, car il a carrément passé sa soirée à coder un truc énoooOOOooorme (et super utile) qui s'appelle MonitorBox .
Parce qu'on va pas se mentir, on croule tous sous les notifications. Entre Slack, les emails, et les alertes de sécurité, notre cerveau a fini par développer un mécanisme de défense radical : il ignore TOUT !!! C'est ce qu'on appelle la "fatigue de l'alerte". J'avoue que pour un admin sys en astreinte, c'est le début de la fin. Le jour où le serveur de prod tombe vraiment, on swipe la notif comme si c'était une pub pour des croquettes bio... Pas terrible donc pour la continuité de service.
L'interface de MonitorBox - sobre mais efficace ( Source )
Et c'est là que Brice intervient justement avec son idée de génie : Ressusciter le bon vieux pager des années 90. Au début je pensais que c'était juste pour le fun (un délire de vieux geek quoi), mais en réalité c'est un vrai outil de surveillance pro.
MonitorBox est conçu pour tourner sur un vieux PC recyclé (genre un vieux Dell Optiplex GX270 ou un ThinkPad T60) sous Debian 12 Bookworm et l'idée, c'est de sortir l'alerte critique du flux continu de votre smartphone pour l'envoyer sur un appareil qui ne sert qu'à ça. Ainsi, quand le beeper à votre ceinture se met à gueuler sur la fréquence 466.975 MHz, vous savez que la maison brûle, sans même regarder l'écran.
Et techniquement, c'est hyper propre !!! Le système utilise une vue Terminal (parfaite pour un vieil écran CRT qui traîne) et un dashboard web moderne sous JavaScript pour le suivi. L'arme secrète reste ensuite le support du protocole POCSAG.
Via le port série (type /dev/ttyS0 ou un adaptateur FTDI), MonitorBox pilote un émetteur radio qui se charge de balancer les infos sur les ondes. Et toudoum, voilà comment votre vieux Tatoo ou Tam-Tam reprend du service !
⚠️ Attention quand même, émettre sur des fréquences radio est ultra-réglementé. Vérifiez donc bien la législation avant de jouer les apprentis sorciers, car pas moyen de plaider l'ignorance si les mecs de l'ANFR débarquent chez vous avec leur camionnette de détection Agence Tous Risques...
J'adore perso son approche qui vise le "Zéro faux positif". En effet, le script s'appuie sur Shell, curl et espeak pour la synthèse vocale locale, et intègre une logique de "Retry" comme ça si un service ne répond pas, l'outil vérifie à nouveau avant de vous réveiller en pleine nuit. Ça réduit drastiquement les fausses alertes, contrairement aux outils de monitoring habituels qui hurlent parfois au loup pour une micro-latence passagère de rien du tout.
MonitorBox est léger (pas besoin de base de données SQL compliquée, juste un fichier servers.conf), souverain, et permet de redonner vie à du matos qu'on croyait bon pour la déchetterie.
Brice nous propose en gros un mix parfait entre low-tech et haute performance. Et si vous voulez tester le bousin, tout le code est open source (licence MIT) et disponible sur GitHub . Seul petit bémol, il vous faudra bel et bien un vrai câble DB9 ou DB25 et un adaptateur qui tient la route, sinon votre VM va juste vous envoyer bouler violemment. Aaaah ces drivers USB chinois, je vous jure...
Bref, merci Brice pour l'inspiration et pour ce beau projet à la fois rétro et moderne !
Découvrez mon infrastructure pour 2025, des nouvelles diverses et mon avis sur l'intelligence artificielle dans nos métiers.
L’article Mon infrastructure pour 2025, des news diverses et mon abandon de Proxmox est apparu en premier sur The Abyss Project.
