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.
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.
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.
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.
👉 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 ?