Як розгорнути Beszel на власній інфраструктурі у 2026 році: агенти, приватна мережа та резервні копії

Найкоротша демонстрація Beszel доводить лише те, що процес слухає порт 8090. Для production потрібні вагоміші докази. Система має пройти цей сценарій навіть після заміни контейнера: зареєструвати agent, показати графіки CPU, пам’яті та диска, активувати alert за пороговим значенням і повторно під’єднати agent після перезапуску hub.

Beszel розгортають із чіткою метою: забезпечити легкий моніторинг сервера в невеликому контейнері. Найпоширеніша проблема під час розгортання полягає в тому, що hub не може дістатися порту 45876 на agent або його SSH key було змінено. Тому роботі з public URL і збереженням стану потрібно приділити стільки ж уваги, як і запуску image.

Визначте межі runtime Beszel

Стан процесу та стан продукту — різні речі для Beszel. Порт 8090 може відповідати, тоді як користувацький сценарій усе ще не працює. Мережева вимога Beszel — Beszel agent на кожній машині, яку потрібно моніторити. Залишайте private endpoints у внутрішньому DNS, дозволяйте лише необхідні outbound-з’єднання та надавайте Beszel service credential з обмеженими правами.

Виконуйте цю перевірку готовності після суттєвих змін конфігурації: зареєструйте agent, перегляньте графіки CPU, пам’яті та диска, активуйте alert за пороговим значенням і повторно під’єднайте agent після перезапуску hub. Не додавайте дорогі зовнішні перевірки до liveness probes, щоб збій провайдера не спричинив restart loop. Під час оцінювання capacity відстежуйте кількість agent, retention metrics, сховище hub і мережеву доступність кожного agent через його виділений порт — це точніше відображає реальне навантаження Beszel, ніж запити до сторінок.

Зробіть public origin однозначним

Browser, API client і Beszel мають використовувати один і той самий origin. Для цього проксíюйте hub через HTTPS, а порти agent залишайте приватними. Зберігайте оригінальні host і protocol, водночас не допускаючи доступу до порту 8090 як до альтернативної public address.

Посібник із діагностики недоступності сайту допомагає відрізнити недоступний route від application, яка відповідає. У цьому випадку це важливо: hub не може дістатися порту 45876 на agent або його SSH key було змінено. Лише першу проблему можна виправити змінами в ingress; друга потребує перевірки logs, state або workload Beszel.

Запустіть перший instance, наближений до production

Перший container має бути простим для видалення та повторного створення. Зберігайте дані не у writable layer, прив’язуйте порт 8090 лише там, звідки до нього може дістатися proxy, і передавайте configuration під час запуску.

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

Після початкового тесту зафіксуйте версію image. Читайте найпершу помилку запуску, а не фінальне повідомлення про restart, перевіряйте кожен mount через docker inspect і переглядайте logs, поки реєструєте agent, спостерігаєте графіки CPU, пам’яті та диска, активуєте alert за пороговим значенням і повторно під’єднуєте agent після перезапуску hub. Ця послідовність допомагає відрізнити некоректну команду запуску image від проблеми із залежністю або permissions.

Logs, які допомагають знайти наступну проблему

Green container необхідний, але недостатній. Service-level indicator — успішне виконання сценарію «зареєструвати agent, переглянути графіки CPU, пам’яті та диска, активувати alert за пороговим значенням і повторно під’єднати agent після перезапуску hub», а ймовірні сигнали навантаження — кількість agent, retention metrics, сховище hub і мережева доступність кожного agent через його виділений порт.

Change control має значення, оскільки версії hub і agent потрібно тестувати разом: зміни протоколу можуть виглядати як непомітні прогалини в моніторингу. Зберігайте попередній image, тестуйте міграції на копії state та документуйте, чи підтримується rollback після зміни schema. Якщо hub не може дістатися порту 45876 на agent або його SSH key було змінено, діагностуйте першу межу, яка відрізняється від робочого середовища.

Production acceptance run для Beszel

До підключення реальних користувачів підготуйте release worksheet для Beszel. У ньому потрібно вказати зафіксовану версію image, порт 8090, canonical origin, persistent paths і відповідального за Beszel agent на кожній машині, яку потрібно моніторити. Додайте очікуваний результат цього сценарію: зареєструвати agent, переглянути графіки CPU, пам’яті та диска, активувати alert за пороговим значенням і повторно під’єднати agent після перезапуску hub.

Використовуйте worksheet після звичайної заміни та після чистого restore. Recovery можна вважати успішним лише тоді, коли повернулися systems, history та alerts, а кожен відновлений agent знову надсилає актуальні metrics. Також зберіть короткий resource trace, що охоплює кількість agent, retention metrics, сховище hub і мережеву доступність кожного agent через його виділений порт; тримайте його поруч із release, щоб у майбутньому порівнювати зміни capacity за тим самим workload.

Додайте одну контрольовану відмову: тимчасово забороніть тестовій identity доступ до Beszel agent на кожній машині, яку потрібно моніторити. Переконайтеся, що Beszel повідомляє про проблему на правильній межі, відновіть коректний стан і повторіть сценарій. Це перевіряє visibility помилок, а не лише успішний результат, і не дає інтерфейсу, який виглядає справним, приховати зламаний worker, callback або database connection.

Спроєктуйте restore Beszel до запуску

Складіть inventory усіх durable artifacts: даних hub, users, systems і alert configuration. Підмонтуйте /beszel_data до bootstrap, запишіть нешкідливі тестові дані та замініть container, щоб довести, що цей path справді persistent. Додайте configuration, яка змінює спосіб інтерпретації збережених даних, а не лише найбільшу директорію.

Налаштуйте retention, копіюйте backups за межі host і виконайте clean-room restore. Перевірку Beszel можна вважати завершеною, коли systems, history та alerts повернулися, а кожен відновлений agent знову надсилає актуальні metrics. Якщо snapshots є частиною плану, скористайтеся рекомендаціями щодо PITR і snapshots, щоб задокументувати, що саме можна відновити кожним механізмом.

Закрийте тимчасовий доступ для налаштування

Моделюйте загрози з огляду на дію, яку виконує Beszel, а не лише на його login form. У цьому випадку найнебезпечніша помилка — опублікувати listeners agent в internet без network controls. Реалізуйте таку межу: залишайте listeners agent у private networks і захищайте hub account та enrollment keys.

У цій базовій конфігурації Beszel не потребує обов’язкового bootstrap secret; натомість захистіть фактичний administrator account або upstream authentication. Не вирішуйте permission error запуском container від root або широким mount host. Resource limits також належать до security design, якщо користувачі можуть створювати навантаження через кількість agent, retention metrics, сховище hub і мережеву доступність кожного agent через його виділений порт.

Перенесіть повторювану infrastructure work у Dockup

Для Beszel Dockup найкорисніший на межі між image і durable service. Він зберігає route до 8090, TLS, secret values і storage під час заміни контейнерів — незалежно від того, чи належить compute Dockup, чи вашому підключеному серверу.

Завершіть налаштування з урахуванням специфіки application: проксíюйте hub через HTTPS і залишайте порти agent приватними; під’єднайте та протестуйте Beszel agent на кожній машині, яку потрібно моніторити; виконайте таку перевірку: зареєструйте agent, перегляньте графіки CPU, пам’яті та диска, активуйте alert за пороговим значенням і повторно під’єднайте agent після перезапуску hub. Збережіть результат як deployment check, щоб наступне оновлення image оцінювалося за поведінкою, а не за статусом container.

Поширені запитання

Що потрібно Beszel для production deployment?

Проксíюйте container Beszel на порту 8090 через один HTTPS origin. Підтримувана мережева вимога — Beszel agent на кожній машині, яку потрібно моніторити. Не вважайте Beszel готовим, доки не зможете зареєструвати agent, переглянути графіки CPU, пам’яті та диска, активувати alert за пороговим значенням і повторно під’єднати agent після перезапуску hub.

Які дані Beszel потрібно включити до backup?

Зберігайте /beszel_data і включайте дані hub, users, systems та alert configuration до одного recovery manifest. Чистий restore Beszel можна вважати успішним лише тоді, коли systems, history та alerts повернулися, а кожен відновлений agent знову надсилає актуальні metrics.

Чи потрібен Beszel HTTPS за reverse proxy?

Використовуйте HTTPS для public origin Beszel, а порт 8090 залишайте у внутрішньому route. Правильно застосуйте налаштування Beszel: проксíюйте hub через HTTPS і залишайте порти agent приватними. Для Beszel HTTPS захищає credentials або user content під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Beszel?

Відновіть актуальний state Beszel в isolated deployment, застосуйте candidate version і повторіть acceptance transaction. Зверніть особливу увагу на те, що версії hub і agent потрібно тестувати разом: зміни протоколу можуть виглядати як непомітні прогалини в моніторингу. Зберігайте попередній image Beszel, доки не буде зрозуміло межі міграції даних і rollback.