Как да хоствате Beszel самостоятелно през 2026 г.: агенти, частна мрежа и backup
Практическо ръководство за self-hosting на Beszel с Docker, портове, persistent data, TLS, сигурност, backup-и и проблемите, които възпрепятстват използването в production. Стъпка по стъпка.
Най-кратката демонстрация на Beszel доказва, че един процес слуша на порт 8090. Production изисква по-солидни доказателства. Тя трябва да премине този сценарий дори след като контейнерът бъде заменен: регистрирайте агент, наблюдавайте графиките за CPU, памет и disk, задействайте alert при достигане на праг и свържете отново агента след рестарт на hub-а.
Beszel се внедрява с ясна цел: лек мониторинг на сървъри в малък контейнер. Най-честият проблем при deployment е, че hub-ът не може да достигне порт 45876 на даден агент или SSH ключът му се е променил. Затова обработката на публичния URL и durable state трябва да получат същото внимание като стартирането на image-а.
Очертайте runtime границата на Beszel
Здравето на процеса и здравето на продукта са различни неща при Beszel. Порт 8090 може да отговаря, докато транзакцията, видима за потребителя, все още е неуспешна. Мрежовият договор за Beszel изисква Beszel agent на всяка наблюдавана машина. Дръжте private endpoint-ите във вътрешен DNS, разрешете само необходимите outbound заявки и задайте на Beszel service credential с ограничен обхват.
Използвайте това упражнение за readiness след значими промени в конфигурацията: регистрирайте агент, наблюдавайте графиките за CPU, памет и disk, задействайте alert при достигане на праг и свържете отново агента след рестарт на hub-а. Не включвайте скъпи външни проверки в liveness probes, за да не предизвика outage на доставчик restart loop. При работа по capacity следете броя агенти, retention-а на metrics, storage-а на hub-а и network reachability до всеки агент през неговия dedicated port — това е по-близо до реалното натоварване на Beszel от заявките към страниците.
Направете публичния origin еднозначен
Браузърът, API client-ът и Beszel трябва да използват един и същ origin. За да постигнете това, насочете hub-а през HTTPS и дръжте портовете на агентите private. Запазете оригиналните host и protocol, като същевременно направите порт 8090 недостъпен като конкуриращ публичен адрес.
Ръководството за troubleshooting при недостъпен сайт помага да разграничите недостъпен route от приложение, което отговаря. Това разграничение е важно тук: hub-ът не може да достигне порт 45876 на даден агент или SSH ключът му се е променил. Само първият проблем се отстранява с промени в ingress-а; вторият изисква проверка на Beszel logs, state или workload-а.
Стартирайте първата instance, близка до production
Първият контейнер трябва да може лесно да бъде изтрит и създаден отново. Дръжте данните извън writable layer-а, bind-нете порт 8090 само там, откъдето proxy-то може да го достигне, и подавайте конфигурацията по време на runtime.
docker run -d \
--name beszel \
--restart unless-stopped \
-p 127.0.0.1:8090:8090 \
-v beszel-data:/beszel_data \
henrygd/beszel:latest
Фиксирайте image-а след първоначалния тест. Прочетете най-ранната startup грешка, а не последното съобщение за restart, проверете всеки mount с docker inspect и следете logs, докато регистрирате агент, наблюдавате графиките за CPU, памет и disk, задействате alert при достигане на праг и свържете отново агента след рестарт на hub-а. Тази последователност разграничава неправилна команда за image-а от проблем със зависимост или permissions.
Logs, които отговарят на следващия въпрос
Зелен контейнер е необходим, но не е достатъчен. Service-level indicator-ът е успешното изпълнение на „регистрирайте агент, наблюдавайте графиките за CPU, памет и disk, задействайте alert при достигане на праг и свържете отново агента след рестарт на hub-а“, докато вероятните сигнали за натоварване са броят агенти, retention-ът на metrics, storage-ът на hub-а и network reachability до всеки агент през неговия dedicated port.
Change control-ът има значение, защото версиите на hub-а и агентите трябва да се тестват заедно, тъй като промените в протокола могат да изглеждат като незабележими пропуски в мониторинга. Запазете стария image, тествайте migrations върху копирано state и документирайте дали rollback се поддържа след промяна на schema-та. Ако hub-ът не може да достигне порт 45876 на даден агент или SSH ключът му се е променил, диагностицирайте първата граница, която се различава от работещата среда.
Production acceptance тест за Beszel
Преди да се появят реални потребители, създайте release worksheet за Beszel. В него трябва да са посочени pinned image-ът, порт 8090, canonical origin-ът, persistent path-овете и отговорникът за Beszel agent на всяка наблюдавана машина. Добавете очаквания резултат от тази транзакция: регистрирайте агент, наблюдавайте графиките за CPU, памет и disk, задействайте alert при достигане на праг и свържете отново агента след рестарт на hub-а.
Използвайте worksheet-а след стандартна замяна и след чисто възстановяване. Recovery се приема само ако системите, history-ята и alert-ите се върнат и всеки възстановен агент продължи да изпраща актуални metrics. Съберете и кратък resource trace, който обхваща броя агенти, retention-а на metrics, storage-а на hub-а и network reachability до всеки агент през неговия dedicated port; съхранявайте го до release-а, за да могат бъдещите промени в capacity да се сравняват със същия workload.
Включете един контролиран failure: временно забранете на test identity достъпа до Beszel agent на всяка наблюдавана машина. Потвърдете, че Beszel отчита проблема на правилната граница, възстановете валидното състояние и изпълнете транзакцията отново. Така проверявате видимостта на грешките, а не само успеха, и предотвратявате интерфейс, който изглежда здрав, да прикрива повреден worker, callback или database connection.
Проектирайте restore-а на Beszel преди старта
Направете inventory на всеки durable artifact: hub data, users, systems и alert configuration. Mount-нете /beszel_data преди bootstrap, запишете безопасни примерни данни и заменете контейнера, за да докажете, че този path наистина е persistent. Включете и конфигурация, която променя начина на интерпретиране на съхранените данни, а не само най-голямата директория.
Задайте retention, копирайте backup-ите извън host-а и изпълнете clean-room restore. Упражнението за Beszel е завършено, когато системите, history-ята и alert-ите се върнат и всеки възстановен агент продължи да изпраща актуални metrics. Ако snapshots са част от плана, използвайте насоките за PITR спрямо snapshot, за да документирате какво може да бъде възстановено чрез всеки механизъм.
Затворете временния setup достъп
Направете threat model на действието, което Beszel извършва, а не само на login формата му. Тук високорисковата грешка е публикуването на listener-ите на агентите в интернет без network controls. Реализирайте тази граница: дръжте listener-ите на агентите в private networks и защитете hub акаунта и enrollment keys.
В този baseline Beszel няма задължителен bootstrap secret; защитете действителния му administrator account или upstream authentication. Не решавайте проблем с permissions, като стартирате контейнера като root или mount-вате host-а без ограничения. Resource limits също са част от security design-а, когато потребители могат да предизвикат натоварване чрез броя агенти, retention-а на metrics, storage-а на hub-а и network reachability до всеки агент през неговия dedicated port.
Преместете повторяемата инфраструктурна работа в Dockup
За Beszel Dockup е най-полезен на границата между image и durable service. Той запазва route-а към 8090, TLS, secret values и storage-а при замяна на контейнерите, независимо дали compute ресурсите принадлежат на Dockup или на свързания ви сървър.
Завършете с познания за приложението: насочете hub-а през HTTPS и дръжте портовете на агентите private; свържете и тествайте Beszel agent на всяка наблюдавана машина; и изпълнете тази проверка: регистрирайте агент, наблюдавайте графиките за CPU, памет и disk, задействайте alert при достигане на праг и свържете отново агента след рестарт на hub-а. Запазете резултата като deployment check, за да се оценява следващият image update по поведението, а не по статуса на контейнера.
Често задавани въпроси
Какво е необходимо на Beszel за production deployment?
Насочете Beszel container-а на порт 8090 през един HTTPS origin. Поддържащото мрежово изискване е Beszel agent на всяка наблюдавана машина. Не приемайте Beszel за готов, докато не можете да регистрирате агент, да наблюдавате графиките за CPU, памет и disk, да задействате alert при достигане на праг и да свържете отново агента след рестарт на hub-а.
Кои данни на Beszel трябва да бъдат включени в backup?
Направете /beszel_data persistent и включете hub data, users, systems и alert configuration в един и същ recovery manifest. Чистият Beszel restore е успешен само когато системите, history-ята и alert-ите се върнат и всеки възстановен агент продължи да изпраща актуални metrics.
Изисква ли Beszel HTTPS зад reverse proxy?
Използвайте HTTPS за публичния Beszel origin и оставете порт 8090 във вътрешния route. Приложете настройката на Beszel правилно: насочете hub-а през HTTPS и дръжте портовете на агентите private. При Beszel HTTPS защитава credentials или потребителско съдържание при пренос и запазва последователното поведение на client-ите, зависещо от origin-а.
Как трябва да се тества upgrade на Beszel?
Възстановете актуалния Beszel state в изолирана deployment среда, приложете кандидат-версията и повторете acceptance транзакцията. Обърнете специално внимание, защото версиите на hub-а и агентите трябва да се тестват заедно, тъй като промените в протокола могат да изглеждат като незабележими пропуски в мониторинга. Запазете предишния Beszel image, докато не изясните границите на data migration и rollback-а.