Comment auto-héberger Beszel en 2026 : agents, réseau privé et sauvegardes

La démonstration la plus simple de Beszel prouve qu’un processus écoute sur le port 8090. La production exige des preuves plus solides. Elle doit réussir ce scénario même après le remplacement du container : inscrire un agent, observer les graphiques du CPU, de la mémoire et du disque, déclencher une alerte de seuil, puis reconnecter l’agent après le redémarrage du hub.

Beszel est déployé dans un objectif précis : assurer la supervision légère d’un serveur dans un petit container. Le piège de déploiement le plus courant survient lorsque le hub ne peut pas atteindre le port 45876 d’un agent ou que sa clé SSH a changé. La gestion de l’URL publique et la persistance de l’état doivent donc recevoir la même attention que le démarrage de l’image.

Délimiter l’environnement d’exécution de Beszel

La santé du processus et celle du produit sont deux choses distinctes pour Beszel. Le port 8090 peut répondre alors que la transaction côté utilisateur échoue toujours. Le contrat réseau de Beszel repose sur un agent Beszel installé sur chaque machine supervisée. Gardez les endpoints privés dans le DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à Beszel un credential de service limité.

Utilisez cet exercice de readiness après toute modification significative de la configuration : inscrivez un agent, observez les graphiques du CPU, de la mémoire et du disque, déclenchez une alerte de seuil, puis reconnectez l’agent après le redémarrage du hub. Évitez les vérifications externes coûteuses dans les probes de liveness afin qu’une panne d’un provider ne provoque pas une boucle de redémarrage. Le travail de capacity planning doit suivre le nombre d’agents, la rétention des métriques, le stockage du hub et la reachability réseau de chaque agent sur son port dédié. Ces indicateurs reflètent mieux la pression réelle sur Beszel que les requêtes de page.

Rendre l’origine publique non ambiguë

Le navigateur, le client API et Beszel doivent utiliser une seule et même origine. Pour y parvenir, faites passer le hub par HTTPS et gardez les ports des agents privés. Conservez l’hôte et le protocole d’origine tout en laissant le port 8090 inaccessible comme adresse publique concurrente.

Le guide de dépannage d’un site inaccessible aide à distinguer une route injoignable d’une application qui répond. Cette distinction est importante ici : le hub ne peut pas atteindre le port 45876 d’un agent ou sa clé SSH a changé. Seul le premier problème se résout par des modifications de l’ingress ; le second nécessite d’inspecter les logs, l’état ou le workload de Beszel.

Exécuter une première instance proche de la production

Le premier container doit pouvoir être supprimé et recréé facilement. Conservez les données en dehors de la couche inscriptible, exposez le port 8090 uniquement là où le proxy peut l’atteindre et transmettez la configuration au runtime.

docker run -d \
  --name beszel \
  --restart unless-stopped \
  -p 127.0.0.1:8090:8090 \
  -v beszel-data:/beszel_data \
  henrygd/beszel:latest

Épinglez l’image après le test initial. Lisez la toute première erreur de démarrage plutôt que le dernier message de redémarrage, vérifiez chaque mount avec docker inspect et suivez les logs pendant que vous inscrivez un agent, observez les graphiques du CPU, de la mémoire et du disque, déclenchez une alerte de seuil, puis reconnectez l’agent après le redémarrage du hub. Cette séquence permet de distinguer une mauvaise commande d’image d’un problème de dépendance ou de permissions.

Des logs qui répondent à la question suivante

Un container en état green est nécessaire, mais pas suffisant. Le service-level indicator est la réussite complète de l’opération « inscrire un agent, observer les graphiques du CPU, de la mémoire et du disque, déclencher une alerte de seuil, puis reconnecter l’agent après le redémarrage du hub ». Les principaux signaux de pression sont le nombre d’agents, la rétention des métriques, le stockage du hub et la reachability réseau de chaque agent sur son port dédié.

La change control est importante, car les versions du hub et des agents doivent être testées ensemble : les changements de protocole peuvent ressembler à des interruptions silencieuses de la supervision. Conservez l’ancienne image, testez les migrations sur une copie de l’état et documentez la prise en charge éventuelle du rollback après l’évolution du schéma. Si le hub ne peut pas atteindre le port 45876 d’un agent ou que sa clé SSH a changé, diagnostiquez la première frontière qui diffère de l’environnement fonctionnel.

Procédure d’acceptation de Beszel en production

Avant l’arrivée des utilisateurs réels, préparez une release worksheet pour Beszel. Elle doit mentionner l’image épinglée, le port 8090, l’origine canonique, les chemins persistants et le responsable d’un agent Beszel sur chaque machine supervisée. Ajoutez le résultat attendu de cette transaction : inscrire un agent, observer les graphiques du CPU, de la mémoire et du disque, déclencher une alerte de seuil, puis reconnecter l’agent après le redémarrage du hub.

Utilisez cette worksheet après un remplacement normal et après une restauration propre. La récupération n’est validée que si les systèmes, l’historique et les alertes sont restaurés et que chaque agent restauré recommence à envoyer des métriques actuelles. Collectez également une courte trace de ressources couvrant le nombre d’agents, la rétention des métriques, le stockage du hub et la reachability réseau de chaque agent sur son port dédié ; conservez-la avec la release afin que les futures évolutions de capacité soient comparées avec le même workload.

Incluez un échec contrôlé : refusez temporairement à l’identité de test l’accès à un agent Beszel sur chaque machine supervisée. Vérifiez que Beszel signale le problème à la bonne frontière, rétablissez la condition valide et rejouez la transaction. Cela vérifie la visibilité des erreurs, et pas seulement le succès, tout en évitant qu’une interface apparemment saine ne masque un worker, un callback ou une connexion à la base de données défaillant.

Concevoir la restauration de Beszel avant le lancement

Inventoriez chaque artefact durable : les données du hub, les utilisateurs, les systèmes et la configuration des alertes. Montez /beszel_data avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le container pour prouver que ce chemin est réellement persistant. Incluez les paramètres qui modifient l’interprétation des données stockées, et pas uniquement le répertoire le plus volumineux.

Définissez la rétention, copiez les sauvegardes hors de l’hôte et exécutez une restauration en clean room. L’exercice Beszel est terminé lorsque les systèmes, l’historique et les alertes sont restaurés et que chaque agent restauré recommence à envoyer des métriques actuelles. Si les snapshots font partie du plan, utilisez le guide PITR versus snapshot pour documenter ce que chaque mécanisme permet de récupérer.

Fermer les accès temporaires de configuration

Modélisez la menace liée à l’action effectuée par Beszel, et pas seulement à son formulaire de connexion. Ici, l’erreur la plus risquée consiste à publier les listeners des agents sur Internet sans contrôles réseau. Implémentez cette limite : gardez les listeners des agents sur des réseaux privés et protégez le compte du hub ainsi que les clés d’inscription.

Beszel n’impose aucun secret de bootstrap dans cette configuration de référence ; protégez plutôt son compte administrateur réel ou le système d’authentification upstream. Ne résolvez pas une erreur de permission en exécutant le container en tant que root ou en montant largement l’hôte. Les resource limits font également partie de la conception de sécurité lorsque le nombre d’agents, la rétention des métriques, le stockage du hub et la reachability réseau de chaque agent sur son port dédié peuvent être déclenchés par les utilisateurs.

Déplacer le travail d’infrastructure reproductible vers Dockup

Pour Beszel, Dockup est particulièrement utile à la frontière entre une image et un service durable. Il conserve la route vers 8090, le TLS, les valeurs des secrets et le stockage lors des remplacements de containers, que le compute appartienne à Dockup ou à votre serveur connecté.

Terminez par les vérifications propres à l’application : faites passer le hub par HTTPS et gardez les ports des agents privés ; connectez et testez un agent Beszel sur chaque machine supervisée ; puis exécutez cette vérification : inscrivez un agent, observez les graphiques du CPU, de la mémoire et du disque, déclenchez une alerte de seuil, puis reconnectez l’agent après le redémarrage du hub. Conservez le résultat comme deployment check afin que la prochaine mise à jour de l’image soit évaluée sur son comportement plutôt que sur l’état du container.

Questions fréquentes

De quoi Beszel a-t-il besoin pour un déploiement en production ?

Faites passer le container Beszel sur le port 8090 via une seule origine HTTPS. La condition réseau associée est la présence d’un agent Beszel sur chaque machine supervisée. Ne considérez pas Beszel comme prêt tant que vous ne pouvez pas inscrire un agent, observer les graphiques du CPU, de la mémoire et du disque, déclencher une alerte de seuil, puis reconnecter l’agent après le redémarrage du hub.

Quelles données Beszel doivent faire partie d’une sauvegarde ?

Rendez /beszel_data persistant et incluez les données du hub, les utilisateurs, les systèmes et la configuration des alertes dans le même recovery manifest. Une restauration propre de Beszel n’est validée que si les systèmes, l’historique et les alertes sont restaurés et que chaque agent restauré recommence à envoyer des métriques actuelles.

Beszel nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Beszel et gardez le port 8090 sur la route interne. Appliquez correctement le paramètre Beszel : faites passer le hub par HTTPS et gardez les ports des agents privés. Pour Beszel, HTTPS protège les credentials ou le contenu utilisateur pendant leur transit et garantit un comportement cohérent du client vis-à-vis de l’origine.

Comment tester une mise à jour de Beszel ?

Restaurez l’état actuel de Beszel dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les versions du hub et des agents doivent être testées ensemble : les changements de protocole peuvent ressembler à des interruptions silencieuses de la supervision. Conservez l’image Beszel précédente jusqu’à ce que les limites de la migration des données et du rollback soient clairement établies.