Proxmox sans vivre dans le terminal
Proxmox se gère confortablement depuis l'interface web, jusqu'au jour où cela ne suffit plus : un agencement de stockage, un changement réseau, un invité bloqué, et la réponse devient une session SSH et une commande trouvée sur un forum. Atlas met aussi ces jours-là à l'écran, en flux guidés au risque écrit noir sur blanc, pendant que Proxmox reste Proxmox en dessous.
Pourquoi le terminal rattrape toujours
L'interface web de base couvre le quotidien moyen, mais les bords vivent dans le shell : zpool et LVM pour le stockage, le fichier interfaces pour le réseau, qm et pct pour l'invité qui ne répond plus. Les bords sont exactement là où les erreurs coûtent le plus.
Les commandes copiées des forums tournent avec les pleins pouvoirs. Un drapeau qui voulait dire autre chose, un nom de périphérique venu d'un autre montage, et il n'y a aucune étape de confirmation devant un shell root.
Et le savoir CLI se concentre chez une seule personne. Quand l'unique admin qui connaît les incantations est absent, l'hôte attend ; transmettre une pile d'historique shell, ce n'est pas transmettre un système.
Comment le travail de bord se fait aujourd'hui
Le schéma se répète sur la plupart des hôtes :
Se connecter en SSH et chercher la bonne commande pour la tâche.
Vérifier les drapeaux contre la doc, car la moitié des réponses de forum visent d'anciennes versions.
Exécuter dans un shell root et scruter la sortie texte à la recherche d'ennuis.
Basculer vers l'interface web pour vérifier que le résultat a vraiment pris.
Recommencer avec une autre famille d'outils pour la tâche suivante : zfs, ip, qm, vzdump.
Garder le savoir dans sa tête, car rien de tout cela n'est écrit nulle part.
Comment Atlas remplace les jours de shell
Les bords risqués deviennent des écrans guidés ; le terminal devient un choix au lieu d'une obligation.
Des flux guidés pour le travail risqué
Agencements de stockage, changements réseau, mises à jour et restaurations tournent en flux pas à pas avec des contrôles intégrés. Le drapeau dangereux n'est tout simplement jamais tapé.
Tout sur un seul écran
VM, conteneurs, stockage, réseau, mises à jour et sauvegardes vivent dans une seule interface, dessinée en topologie plutôt qu'en arbre de menus.
L'impact et la confirmation d'abord
Les flux critiques montrent les ressources affectées et demandent confirmation avant toute application ; un mauvais clic ne devient pas un mauvais hôte.
Des consoles sans SSH
Les consoles d'invités s'ouvrent depuis le navigateur ; atteindre une VM cassée n'exige ni terminal ni fichier de clé.
Proxmox reste Proxmox
Atlas gère le Proxmox standard en dessous ; rien n'est forké. L'interface PVE et le shell continuent de fonctionner, ils cessent juste d'être obligatoires.
Dans le navigateur, depuis n'importe où
Le cockpit tourne dans un navigateur sur l'hôte ; surveiller l'infrastructure ne dépend plus de la machine qui porte les clés SSH.
Questions fréquentes
- Est-ce que cela remplace l'apprentissage de Proxmox ?
- Non. Atlas fait du chemin sûr le chemin facile ; ce qu'il supprime, c'est l'obligation de mémoriser des incantations pour le travail risqué, pas la valeur de comprendre le système.
- Puis-je encore utiliser la CLI ?
- Oui. Le shell et l'interface PVE fonctionnent exactement comme avant. Atlas reprend les jours qu'on préférerait ne pas y passer.
- Et les opérations que l'interface web n'a jamais couvertes ?
- C'est le cœur de cette page : agencements de stockage, modifications réseau, restaurations et réparations tournent en flux guidés au lieu de sessions shell.
- Peut-on confier cela sans risque à un admin junior ?
- Plus sûr qu'un shell root. Les flux montrent l'impact et demandent confirmation, les permissions reflètent les rôles Proxmox, et les actions critiques atterrissent dans le journal d'audit.
- Faut-il un agent dans chaque invité ?
- Non. Atlas tourne sur l'hôte. Les agents d'invités restent optionnels, comme dans Proxmox nu.
- Le trafic de gestion quitte-t-il mon réseau ?
- Non. Le cockpit tourne localement sur l'hôte et y parle à Proxmox. Rien ne transite par le cloud de qui que ce soit.
- Peut-on gérer Proxmox sans SSH ?
- Oui. Proxmox peut être géré sans ouvrir SSH ; tout le travail quotidien passe par l'interface visuelle. C'est de là que vient une gestion de Proxmox plus simple : au lieu de mémoriser une commande, l'effet est visible avant confirmation. Le shell reste exactement où il était et chacun peut s'en servir quand il le souhaite, car il s'agit d'une voie ajoutée et non d'une voie fermée.
Fiches liées
- Console, shell et SSH : trois portes distinctes vers la même machine Quand vous ne pouvez plus joindre une machine, la première question est de savoir quelle porte vous utilisiez. Il y en a trois, et chacune dépend de choses différentes.
- La console refuse de s'ouvrir : l'interface marche, alors pourquoi cette seule chose échoue Une console qui ne se connecte jamais alors que le reste de l'interface va très bien désigne un petit ensemble de causes, et la plus fréquente est un proxy inverse qui relaie correctement les requêtes ordinaires et refuse en silence la connexion dont la console a réellement besoin.
- Faire entrer un fichier dans une machine virtuelle, quand Proxmox n'a pas de gestionnaire de fichiers Il n'existe pas de bouton d'envoi pointant vers l'intérieur d'un invité, et cette absence est délibérée et non un oubli. Il y a quatre vrais chemins d'entrée, chacun avec son coût, et un raccourci populaire qui corrompt les systèmes de fichiers en silence.
- L'agent invité est activé et indique quand même qu'il ne tourne pas Activer l'agent et installer l'agent sont deux choses distinctes, et faire les deux peut encore le laisser éteint. Ce qui justifie d'y consacrer du temps n'est pas l'adresse IP manquante, mais la sauvegarde qui continue de réussir en perdant discrètement de sa fiabilité.