Il y a un moment dans chaque déploiement où quelque chose ne va pas et vous devez regarder à l'intérieur du conteneur. Vérifier un fichier de log. Valider un chemin de configuration. Voir si un volume s'est vraiment monté. Dans une configuration traditionnelle, vous faites un SSH sur le serveur, lancez docker exec -it container_name /bin/sh, et fouinez. Dans un PaaS, cette porte de sortie devrait être à un clic.
Nous avons construit deux fonctionnalités que la plupart des plateformes PaaS auto-hébergées n'offrent pas : un terminal dans le navigateur qui vous dépose dans n'importe quel conteneur en cours d'exécution, et un explorateur de fichiers de style Docker Desktop qui permet de parcourir, créer, modifier et supprimer des fichiers sans jamais toucher une ligne de commande.
Terminal web : architecture
Le terminal web a trois couches : Frontend (xterm.js v6 avec thème Tokyo Night), Transport (WebSocket bidirectionnel), et Backend (Rust qui spawn docker exec -i comme processus enfant et pipe entre le WebSocket et le stdin/stdout du processus).
Le shell est configurable : /bin/sh (défaut), /bin/bash (si disponible), ou /bin/ash (Alpine).
Explorateur de fichiers : architecture
L'explorateur de fichiers est plus complexe car il implique plusieurs opérations : parcourir, créer, modifier et supprimer. Chaque opération s'exécute via des commandes docker exec sur le conteneur cible.
Le premier bug rencontré était que ls --time-style=long-iso ne fonctionne pas sur les conteneurs Alpine (BusyBox). Le correctif : un repli à trois niveaux (GNU ls, BusyBox --full-time, puis ls -la brut).
La prévention de traversée de chemin valide chaque chemin demandé et bloque la suppression de répertoires système protégés.
La mise en page à deux panneaux
Le panneau gauche (280 px) est un arbre de répertoires récursif avec un sélecteur de conteneur en haut. Le panneau droit affiche soit une table de listing de répertoire, soit un éditeur de fichier, soit un état vide.
Pourquoi c'est important
Le terminal web et l'explorateur de fichiers éliminent la raison la plus courante pour laquelle un développeur fait un SSH sur un serveur après avoir déployé une application : « j'ai besoin de regarder à l'intérieur du conteneur. »
Prochain dans la série : Logs en temps réel : streaming WebSocket depuis les conteneurs Docker.