Contnap

Au boulot, je lance les tests en local — ça implique de démarrer Postgres, et parfois OpenSearch. Le problème : une fois les tests terminés, ces conteneurs continuent de tourner. OK pour Postgres, mais OpenSearch est en Java, donc il reste là à bouffer de la RAM et à vider la batterie de mon PC portable pour rien. Je voulais quelque chose qui arrête les conteneurs quand ils sont inactifs et les relance de façon transparente à la demande, sans avoir à toucher la configuration des clients.

C’est contnap : un proxy transparent qui gère le cycle de vie des conteneurs automatiquement. Il maintient le port ouvert pendant que le conteneur est arrêté. Quand une connexion arrive, il met les paquets en tampon, démarre le conteneur, attend qu’il soit prêt, puis redirige le trafic comme si de rien n’était. Quand le conteneur est à nouveau inactif, il l’arrête.

Pour le trafic HTTP, au lieu de laisser le client attendre en silence, contnap affiche une page « Démarrage… » qui se rafraîchit automatiquement dans le navigateur jusqu’à ce que le conteneur soit prêt.

Configuration

Contnap se configure entièrement via des labels Docker sur les conteneurs eux-mêmes — pas de fichier de configuration séparé.

Obligatoires :

• contnap.enabled: "true" — active le proxy pour ce conteneur
• contnap.tcp_ports ou contnap.udp_ports — ports à proxyfier, séparés par des virgules

Optionnels :

• contnap.timeout — durée d’inactivité en secondes avant l’arrêt (défaut : 300)
• contnap.http_ports — ports qui reçoivent la page de réveil plutôt qu’un simple tampon brut
• contnap.group — nom de groupe pour démarrer/arrêter un ensemble de conteneurs ensemble
• contnap.pre_start / contnap.post_stop — commandes shell à exécuter avant le démarrage ou après l’arrêt
• contnap.machines — adresses IP ou noms d’hôtes à surveiller
• contnap.autostart — réveille le conteneur quand les machines listées apparaissent sur le réseau
• contnap.only_listed_machines — restreint l’accès aux IPs spécifiées uniquement
• contnap.schedule — limite le réveil à des plages horaires (ex. Mon-Fri 08:00-19:00)

Contnap s’intègre avec les health checks Docker : il attend que le conteneur soit déclaré sain avant de rediriger le trafic, afin que les clients n’atteignent jamais un service à moitié démarré.

Observabilité

Contnap expose une API via socket Unix pour des requêtes en temps réel et peut écrire des snapshots JSON périodiques dans un fichier, utiles pour surveiller l’état des conteneurs ou écrire des scripts autour de celui-ci.

Alternatives

Deux autres projets open source font quelque chose de similaire :

ContainerNursery (TypeScript/Node.js) agit comme un reverse proxy HTTP qui arrête les conteneurs inactifs et les redémarre à la réception d’une requête. Il affiche une page de chargement pendant le démarrage et peut surveiller l’utilisation CPU pour éviter d’arrêter un conteneur encore actif. HTTP uniquement — pas de support TCP ou UDP.

Sablier (Go) s’intègre comme plugin dans des reverse proxies existants (Traefik, Caddy, Nginx). Il supporte Docker, Kubernetes, Podman, Docker Swarm et Proxmox LXC. Il propose aussi un « mode scale » qui limite le CPU et la mémoire au lieu d’arrêter complètement les conteneurs, échangeant des économies de ressources contre une latence de démarrage nulle. Principalement orienté HTTP, bien qu’un projet compagnon tiers (sablier-proxy) ajoute un support TCP basique — blocage uniquement, sans page de réveil.

ContainerNursery est HTTP uniquement. Contnap proxyfie le TCP et l’UDP natifs, ce qui le rend utilisable pour des services non-HTTP comme Postgres.

Code source : codeberg.org/slundi/contnap