Dans le premier article sur WP Control, j’expliquais l’idée de base : un panneau de contrôle DevOps self-hosted pour gérer mes sites WordPress depuis mon téléphone, sans ouvrir un terminal. Trois tâches opérationnelles au départ. La promesse : le champ des possibles est large.
Eh bien, il s’est élargi. Cette v2 apporte deux nouvelles tâches : l’arrêt automatique des conteneurs staging et un nettoyage Docker complet, tout ça depuis son téléphone.
Le problème
Un matin, mon serveur commence à ralentir. Je regarde l’espace disque disponible. 100 Go mangés par Docker – images non utilisées, containers arrêtés, volumes orphelins, cache de build accumulé depuis des semaines. Le genre de nettoyage qu’on reporte toujours « à plus tard » et qui finit par se rappeler à vous au pire moment.
Et en passant, les environnements staging de tous mes projets tournent en permanence – y compris la nuit, le week-end, quand personne ne les utilise. Pas catastrophique, mais inutile.
J’aurais pu SSH sur le serveur, taper deux commandes, régler l’affaire en cinq minutes. Mais c’est exactement ce que WP Control est censé éviter. Alors j’ai ajouté deux nouvelles tâches.
Tâche 1 – Arrêt des conteneurs staging
Le principe : stopper automatiquement tous les conteneurs dont le nom contient _staging, d’un seul coup, sans toucher aux conteneurs de production.
Deux approches selon l’environnement : via l’API Docker exposée par le socket-proxy (pas de socket Docker brut, jamais), ou via SSH si le contexte l’exige. Dans les deux cas, la logique est la même – lister les conteneurs en cours d’exécution, filtrer sur le pattern _staging, stopper.
Le résultat : tous mes staging s’éteignent en quelques secondes depuis l’interface Semaphore, depuis mon téléphone, sans risque de toucher quoi que ce soit en production.
Ce qui compte dans ce filtre, c’est la précision. Le pattern _staging correspond exactement à la convention de nommage DDEV – chaque conteneur staging porte ce suffixe dans son nom. Pas de risque de toucher à un conteneur de prod, pas de regex complexe à maintenir. Une convention bien choisie, et le filtre tient en quelques lignes.
Tâche 2 – Nettoyage Docker
L’équivalent d’un docker system prune -a – mais déclenché depuis une interface web, avec TOTP, depuis n’importe où.
Concrètement, ça supprime :
- Les containers arrêtés
- Les images non utilisées par un container en cours d’exécution
- Les volumes orphelins
- Les réseaux inutilisés
- Le cache de build BuildKit
C’est une tâche destructive – elle est donc exécutée avec une confirmation explicite dans Semaphore avant de lancer. Pas question de la déclencher par erreur.
Sur mon serveur, le cache BuildKit représente à lui seul 40 à 60 Go après quelques semaines de builds actifs. Les images non utilisées s’accumulent à chaque déploiement si on ne nettoie pas régulièrement. La tâche docker system prune -a est radicale – c’est exactement pour ça que la confirmation dans Semaphore n’est pas optionnelle.
Le résultat concret
100 Go récupérés. Depuis mon téléphone. En quelques secondes.
C’est le genre de chiffre qui fait relativiser le temps passé à mettre en place l’outil. Une seule utilisation de la tâche « nettoyage Docker » a récupéré plus d’espace que tout ce que j’aurais pu faire manuellement en une demi-heure de nettoyage à la main.
WP Control, l’état actuel
Le panneau compte maintenant cinq tâches opérationnelles :
- Vider le cache WP Rocket et Redis d’un site
- Redémarrer un conteneur Docker
- Régénérer les permaliens WordPress
- Arrêter tous les conteneurs staging
- Nettoyage Docker complet
L’architecture tient toujours : Semaphore UI + GitLab + scripts bash, socket-proxy Docker filtré, double authentification TOTP, zéro dépendance à un service tiers payant.
Et le champ des possibles continue de s’élargir. Déploiements à la demande, rapports de santé serveur, sauvegardes déclenchées manuellement – autant de tâches candidates pour la prochaine itération.
Ce que ça change dans le quotidien
Avant ces deux tâches, je me retrouvais à ignorer le problème jusqu’à ce qu’il devienne urgent. L’espace disque filait, les stagings tournaient inutilement, et ouvrir un terminal depuis mon téléphone reste inconfortable.
Maintenant, l’arrêt des stagings et le nettoyage Docker font partie de ma routine hebdomadaire – deux clics dans Semaphore, depuis n’importe où. Le ROI du temps passé à construire WP Control se mesure à chaque fois que je n’ouvre pas de session SSH.
👉 Et vous, quelle tâche d’administration vous ferait gagner le plus de temps si vous pouviez la déclencher depuis votre téléphone ?