Fleetd: открытая панель управления Linux-серверами и маршрутизаторами

Когда серверов и маршрутизаторов немного, управлять ими кажется просто: зайти по SSH, посмотреть состояние, прочитать логи упавшего сервиса, выполнить несколько команд для обновления.

Неудобство в том, что всё это находится в разных местах. У сервера один вход, у маршрутизатора другой. Получив уведомление, нужно заново найти машину, разобраться в её окружении и начать диагностику.

Мне хотелось собрать повседневные действия вместе: открыть страницу, увидеть доступные машины и предупреждения, перейти к деталям, а при необходимости выполнить команду или открыть терминал.

Так появился Fleetd — инструмент для самостоятельного размещения, управляющий Linux-серверами и маршрутизаторами. Код опубликован под лицензией MIT, первый публичный выпуск — v0.3.0. Доступна документация на английском и китайском.

В первой статье расскажу о задаче, нынешних возможностях и ключевых решениях. Подробности реализации будут в следующих частях.

От обнаружения проблемы к действию

Мониторинг сообщает о заполненном диске, но затем нужно найти растущий каталог. Упавший сервис требует чтения логов, проверки конфигурации и решения о перезапуске.

Для человека, обслуживающего небольшой парк машин, это одна последовательная задача. Хотелось сохранить её непрерывность, а не искать одну и ту же машину в нескольких инструментах.

Область	Возможности Fleetd
Мониторинг	CPU, память, нагрузка, диски и скорость сети; история за семь дней
Состояние служб	Неудачные systemd units, Docker-контейнеры, узлы WireGuard
Уведомления	Недоступность, устойчивое превышение ресурсов, нехватка места и связанные сбои; необязательная почта
Команды	Подписанные запросы к одной или нескольким машинам с учётом локальных прав
Веб-терминал	Интерактивный сеанс при полном доступе
Агенты	Одобрение новых машин и распространение подписанных обновлений

Обзор машин Fleetd с ресурсами и состоянием подключения

Фрагмент интерфейса из документации. Числа иллюстрируют расположение данных, а не результаты тестов производительности.

Метрики требуют контекста. Состояние systemd относится к системам с systemd; OpenWrt не обязан предоставлять такой же список служб. Время handshake WireGuard — диагностическая подсказка, которую нужно оценивать вместе с трафиком и настройками.

Первое назначение панели — дать точку входа в диагностику. Сложные правила мониторинга, длительную аналитику и полноценное управление конфигурацией можно оставить специализированным инструментам.

Один сервер и агент на каждой машине

Сервер обслуживает интерфейс, записи машин, метрики и историю операций; данные хранятся в PostgreSQL. Агент на управляемой Linux-машине собирает состояние, получает запросы и решает, можно ли их выполнить.

Интерфейс Vue 3 после сборки встроен в Go-бинарник сервера. Агент также написан на Go, опубликованы варианты Linux amd64 и arm64. Архитектуру нужно проверять: наличие OpenWrt само по себе не означает совместимость с готовым бинарником.

Границы понятны: сервер, база данных и отдельные агенты со своими настройками. По ним удобно проверять, подключился ли агент, отправил ли данные, получил ли запрос и почему принял или отклонил его.

Для маршрутизаторов важно направление подключения

Облачный сервер может иметь публичный адрес, а домашний маршрутизатор — находиться за NAT. Открывать ещё один входящий сервис управления означает дополнительную настройку и обслуживание.

В Fleetd агент сам подключается к серверу. Если адрес сервера доступен, отдельный входящий порт управления агентом на машине не нужен.

Так можно объединять Linux, OpenWrt и iStoreOS из разных сетей. Сам сервер всё равно должен быть доступен агентам; для штатной эксплуатации нужны HTTPS и проксирование WebSocket по документации.

Новая машина сначала ожидает одобрения. Администратор сравнивает отпечаток в установщике и панели, затем принимает или отклоняет её. Это действительно та машина, которую я собирался добавить? Знакомое имя хоста не заменяет проверку идентичности. Регистрацию, отпечатки и переподключение разберу отдельно.

Видеть машину не значит полностью ею управлять

Одним машинам нужен только мониторинг, другим — несколько фиксированных действий. Произвольные команды и терминал необходимы лишь части парка.

В Fleetd это задаётся в локальном конфигурационном файле агента:

Уровень	Разрешено
monitor	Только мониторинг, без удалённых команд
allowlist	Локально заданные действия
full	Произвольные команды и веб-терминал

Команда подписывается в браузере администратора. Агент проверяет подпись доверенным открытым ключом, затем адресата, срок действия и локальные права. Сервер пересылает запросы; обычного неподписанного запроса для исполнения недостаточно.

Так уменьшается слепое доверие инструкциям сервера, но есть важная предпосылка: браузер и исполняемый в нём frontend должны оставаться доверенными.

Сервер также раздаёт интерфейс. После компрометации он может подменить страницу при следующем посещении. Неэкспортируемый ключ не мешает вредоносному коду пытаться вызвать операцию подписи. Поэтому подписи команд не дают оснований обещать абсолютную безопасность после взлома сервера.

Цепочке доверия будет посвящена отдельная статья. При внедрении стоит оставить monitor для наблюдения, использовать allowlist для фиксированных действий и включать full только там, где необходим полноценный терминал.

У обновлений свой механизм доверия

Копировать новый агент вручную на каждую машину неудобно. Но автоматический запуск любого скачанного файла оставляет вопрос подлинности открытым.

Fleetd использует подписанные пакеты выпуска. Издатель подписывает их в своей среде, а агент проверяет настроенным открытым ключом релизов. Подпись команд и подпись программных выпусков решают разные задачи.

Обычные бинарники GitHub Releases подходят для ручной установки на соответствующей архитектуре. Подписанный пакет .release предназначен только для агентов, доверяющих его ключу.

При самостоятельном размещении следует настроить собственные ключи и процедуру выпуска по документации. Загрузка авторского пакета не делает его допустимым в любой независимой установке. Проверки версий, ошибки валидации и восстановление при обновлении разберём позднее.

Пробный запуск через Docker Compose

При установленных Docker и плагине Compose:

git clone https://github.com/weiyi0/fleetd
cd fleetd
git checkout v0.3.0
docker compose up -d
docker compose run --rm fleetd admin-add admin

Задайте пароль администратора и откройте http://localhost:8480. Интерфейс поддерживает английский и китайский языки.

Версия закреплена на v0.3.0, чтобы условия соответствовали статье. Compose собирает сервер из исходников и запускает PostgreSQL. При первом запуске скачиваются зависимости и компилируется программа, поэтому время зависит от компьютера и сети.

На этом этапе работает панель, но управляемых машин ещё нет. Docker-образ также не создаёт за вас подписанные пакеты агентов.

По краткому руководству можно собрать и вручную запустить агент для первой проверки. Для длительного использования настройте свой ключ выпуска, загрузите подписанные пакеты и подключайте машины через установочный процесс панели.

Пример Compose рассчитан на ознакомление: он содержит демонстрационные данные доступа к БД, а порт 8480 не ограничен loopback. Ограничьте сетевой доступ при локальной проверке. Перед использованием по сети выполните инструкции развёртывания: смените учётные данные, настройте HTTPS и резервное копирование базы и ключей.

Начните с легко восстанавливаемой тестовой машины: проверьте отпечаток, состояние и разрешённые операции. Когда полный путь работает, добавляйте остальные.

Почему первый публичный выпуск — v0.3.0

В существующей среде агенты уже работали на 0.2.0. Механизм обновления требует более новую целевую версию, поэтому публичный выпуск продолжил эту последовательность.

Номер отражает развитие; зрелость приходит с использованием и проверками. Пока Fleetd лучше всего подходит тем, кто обслуживает немного Linux-серверов и маршрутизаторов, хочет контролировать данные и готов разобраться с развёртыванием и правами.

Код, бинарники и документация позволяют изучить работу до внедрения. Таблица функций не превращает проект в замену всем существующим средствам эксплуатации. Сначала важно связать состояние машин, уведомления и необходимое обслуживание, сохранив ясные границы доступа.

Продолжение серии

Далее будут исходящие подключения и одобрение, браузерные подписи, локальные права, поддержка OpenWrt, уведомления и обновления. Отдельно разберу разработку проекта с помощью ИИ.

Хочется сохранять конкретные решения: что они исправили и какие ограничения создали. Реальные проблемы и результаты проверок будут добавляться по мере развития.

Начните с кода и документации. Общие вопросы можно задавать в Issues, а уязвимости сообщать через приватный канал GitHub. Надеюсь, инструмент сократит переключения при повседневном обслуживании, а записи пригодятся в похожих проектах.