Как самостоятельно разместить Beszel в 2026 году: агенты, приватная сеть и резервные копии

Самая короткая демонстрация Beszel доказывает лишь то, что процесс слушает порт 8090. Для production нужны более весомые подтверждения. Система должна проходить этот сценарий даже после замены контейнера: подключить агент, отобразить графики CPU, памяти и диска, вызвать alert по пороговому значению и повторно подключить агент после перезапуска hub.

Beszel разворачивают для конкретной задачи: лёгкого мониторинга серверов в небольшом контейнере. Самая распространённая проблема при развёртывании — hub не может подключиться к порту 45876 на агенте или у агента изменился SSH-ключ. Поэтому обработке публичного URL и долговременному хранению состояния нужно уделить столько же внимания, сколько и запуску image.

Определите границы среды выполнения Beszel

Состояние процесса и состояние продукта — разные вещи для Beszel. Порт 8090 может отвечать, даже если пользовательский сценарий по-прежнему не работает. Сетевой контракт Beszel предполагает наличие агента Beszel на каждой отслеживаемой машине. Оставляйте приватные endpoint во внутреннем DNS, разрешайте только необходимые исходящие подключения и выдавайте Beszel service credential с ограниченными правами.

Используйте это упражнение для проверки готовности после существенных изменений конфигурации: подключите агент, отобразите графики CPU, памяти и диска, вызовите alert по пороговому значению и повторно подключите агент после перезапуска hub. Не включайте дорогостоящие внешние проверки в liveness probe, чтобы сбой у провайдера не вызвал цикл перезапусков. При планировании capacity учитывайте количество агентов, retention метрик, хранилище hub и доступность сети до каждого агента через выделенный порт — это точнее отражает реальную нагрузку Beszel, чем запросы к страницам.

Сделайте публичный origin однозначным

Браузер, API-клиент и Beszel должны использовать один и тот же origin. Чтобы обеспечить это, направьте hub через HTTPS, а порты агентов оставьте приватными. Сохраняйте исходные host и protocol, но не оставляйте порт 8090 доступным извне как конкурирующий публичный адрес.

Руководство по диагностике недоступности сайта помогает отличить недоступный маршрут от приложения, которое отвечает. В данном случае это различие особенно важно: hub не может подключиться к порту 45876 на агенте или у агента изменился SSH-ключ. Изменения ingress исправят только первую проблему; для второй потребуется изучить логи Beszel, состояние или workload.

Запустите первый экземпляр, близкий к production

Первый контейнер должен легко удаляться и создаваться заново. Храните данные не в writable layer, привязывайте порт 8090 только там, откуда до него может достучаться proxy, и передавайте конфигурацию во время запуска.

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

После первичного тестирования зафиксируйте image. Читайте самую раннюю ошибку запуска, а не последнее сообщение о перезапуске, проверяйте каждый mount с помощью docker inspect и следите за логами, пока подключаете агент, просматриваете графики CPU, памяти и диска, вызываете alert по пороговому значению и повторно подключаете агент после перезапуска hub. Эта последовательность помогает отличить некорректную команду запуска image от проблемы с зависимостью или правами доступа.

Логи, которые помогают ответить на следующий вопрос

Работающий контейнер необходим, но этого недостаточно. Service-level indicator — успешное выполнение сценария «подключить агент, отобразить графики CPU, памяти и диска, вызвать alert по пороговому значению и повторно подключить агент после перезапуска hub». Вероятные сигналы нагрузки — количество агентов, retention метрик, хранилище hub и доступность сети до каждого агента через выделенный порт.

Контроль изменений важен, поскольку версии hub и агента следует тестировать вместе: изменения протокола могут выглядеть как незаметные пробелы в мониторинге. Сохраняйте предыдущий image, тестируйте миграции на копии состояния и документируйте, поддерживается ли rollback после изменения schema. Если hub не может подключиться к порту 45876 на агенте или у агента изменился SSH-ключ, диагностируйте первую границу, которая отличается от рабочего окружения.

Приёмочное испытание Beszel для production

До подключения реальных пользователей подготовьте release worksheet для Beszel. В нём должны быть указаны зафиксированный image, порт 8090, canonical origin, постоянные пути и ответственный за агент Beszel на каждой отслеживаемой машине. Добавьте ожидаемый результат этого сценария: подключить агент, отобразить графики CPU, памяти и диска, вызвать alert по пороговому значению и повторно подключить агент после перезапуска hub.

Используйте worksheet после обычной замены и после чистого восстановления. Восстановление считается успешным только тогда, когда возвращаются системы, история и alerts, а каждый восстановленный агент снова начинает отправлять актуальные метрики. Также соберите короткий ресурсный trace, охватывающий количество агентов, retention метрик, хранилище hub и доступность сети до каждого агента через выделенный порт; храните его рядом с release, чтобы будущие изменения capacity сравнивались при той же нагрузке.

Добавьте один контролируемый сбой: временно запретите тестовой identity доступ к агенту Beszel на каждой отслеживаемой машине. Убедитесь, что Beszel сообщает о проблеме на правильной границе, восстановите корректное состояние и повторите сценарий. Это проверяет не только успешную работу, но и видимость ошибок, не позволяя интерфейсу, который выглядит исправным, скрывать сломанный worker, callback или подключение к database.

Спроектируйте восстановление Beszel до запуска

Составьте перечень всех постоянных артефактов: данные hub, пользователей, систем и конфигурацию alerts. Подключите /beszel_data до bootstrap, запишите безвредные тестовые данные и замените контейнер, чтобы доказать фактическую постоянность этого пути. Включите конфигурацию, которая меняет интерпретацию сохранённых данных, а не только самый большой каталог.

Настройте retention, копируйте резервные данные за пределы хоста и выполните восстановление в чистом окружении. Проверка Beszel считается завершённой, когда возвращаются системы, история и alerts, а каждый восстановленный агент снова начинает отправлять актуальные метрики. Если в плане есть snapshots, используйте рекомендации по сравнению PITR и snapshot, чтобы документировать, какие данные можно восстановить каждым механизмом.

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

Оценивайте угрозы, связанные с действиями Beszel, а не только с его login form. В данном случае самая опасная ошибка — опубликовать listeners агентов в интернете без сетевых ограничений. Установите следующую границу: оставляйте listeners агентов в приватных сетях и защищайте account hub и ключи enrollment.

В этой базовой конфигурации Beszel не требует обязательного bootstrap secret; вместо этого защитите фактический administrator account или upstream authentication. Не устраняйте ошибку прав, запуская контейнер от root или монтируя хост целиком. Resource limits также относятся к security design, поскольку пользователи могут влиять на количество агентов, retention метрик, хранилище hub и доступность сети до каждого агента через выделенный порт.

Перенесите повторяющиеся инфраструктурные задачи в Dockup

Для Beszel Dockup особенно полезен на границе между image и постоянным сервисом. Он сохраняет маршрут к 8090, TLS, значения secret и хранилище при замене контейнеров независимо от того, принадлежат ли вычислительные ресурсы Dockup или подключённому серверу.

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

Часто задаваемые вопросы

Что требуется Beszel для развёртывания в production?

Направьте контейнер Beszel на порту 8090 через один origin HTTPS. Дополнительное сетевое требование — наличие агента Beszel на каждой отслеживаемой машине. Не объявляйте Beszel готовым, пока не сможете подключить агент, отобразить графики CPU, памяти и диска, вызвать alert по пороговому значению и повторно подключить агент после перезапуска hub.

Какие данные Beszel нужно включать в резервную копию?

Сохраняйте /beszel_data и включайте данные hub, пользователей, систем и конфигурацию alerts в один recovery manifest. Чистое восстановление Beszel считается успешным только тогда, когда возвращаются системы, история и alerts, а каждый восстановленный агент снова начинает отправлять актуальные метрики.

Нужен ли Beszel HTTPS за reverse proxy?

Используйте HTTPS для публичного origin Beszel, а порт 8090 оставьте во внутреннем маршруте. Корректно применяйте настройку Beszel: направляйте hub через HTTPS и оставляйте порты агентов приватными. Для Beszel HTTPS защищает credentials и пользовательский контент при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.

Как тестировать обновление Beszel?

Восстановите текущее состояние Beszel в изолированном deployment, примените candidate version и повторите приёмочный сценарий. Обратите особое внимание на то, что версии hub и агента следует тестировать вместе: изменения протокола могут выглядеть как незаметные пробелы в мониторинге. Храните предыдущий image Beszel, пока не будут понятны границы миграции данных и rollback.