Один Go-агент для Linux и OpenWrt: решения по развёртыванию Fleetd

Установка агента на сервер и домашний маршрутизатор сначала выглядит одинаково: скопировать программу, записать настройки, запустить. При постоянной эксплуатации появляются другие вопросы. Кто запустит процесс после перезагрузки? Что делать, если сеть ещё не готова? Где искать журнал? Сохранятся ли идентичность устройства и записи принятых команд?

Fleetd управляет серверами Linux и маршрутизаторами OpenWrt или iStoreOS. После подключения устройств и подписи команд в браузере рассмотрим превращение агента в устойчивый и диагностируемый системный сервис. Речь о v0.3.0: установщик поддерживает amd64 и arm64, systemd либо procd OpenWrt, но не любое устройство с ядром Linux.

Общий код, отдельные бинарные файлы

OpenWrt тоже использует Linux. Соединения, аутентификацию, авторизацию команд и базовые метрики ядра можно реализовать одинаково. Поэтому Fleetd не разделяет агент на серверную и маршрутизаторную версии: один исходный код собирается для Linux под amd64 и arm64.

Один агент означает общий код и протокол. Исполняемый файл amd64 нельзя просто перенести на arm64.

Архитектура устройства	Выбор установщика
`x86_64`, `amd64`	`amd64`
`aarch64`, `arm64`	`arm64`
Прочие	Установка прекращается

OpenWrt работает и на MIPS, и на 32-битном ARM, которые этот путь установки не покрывает. Возможность кросс-компиляции Go не означает поддержку архитектуры проектом. Нужны проверки зависимостей, артефактов, определения платформы, обновлений и поведения на реальном оборудовании.

uname -m полезен для первой проверки, но ядро, пользовательское окружение и доступные системные функции тоже имеют значение.

Один файл упрощает подготовку окружения

Агент собирается с CGO_ENABLED=0, уменьшая зависимость от динамически связываемого C-окружения целевой системы. Для запуска на каждой машине не нужны компилятор Go, Node.js или Python. Это удобно на маршрутизаторах с ограниченным хранилищем и небольшим набором пакетов.

Однако требования не исчезают. Нужны сеть, рабочая проверка сертификатов HTTPS, доступное для записи место конфигурации и необходимые функции ядра. Некоторые сборщики вызывают внешние программы: docker для контейнеров и wg для WireGuard.

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

Сначала окружение, затем системная служба

Установщик выполняет следующие шаги:

Проверяет root и архитектуру процессора.
Определяет systemd либо окружение procd OpenWrt.
Загружает подходящий агент с вашего сервера Fleetd.
Запускает version, проверяя хотя бы возможность старта.
Создаёт или сохраняет конфигурацию, размещает программу, регистрирует и запускает службу.
Показывает отпечаток для сверки и одобрения в панели.

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

Для загрузки используется curl, при его отсутствии — wget. В минимальной системе нужно проверить поддержку требуемых HTTPS-запросов. Универсальной команды установки пакетов здесь нет: версии OpenWrt и состав прошивок различаются.

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

systemd и procd управляют одним процессом

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

Элемент	systemd	OpenWrt / procd
Программа	`/usr/local/bin/fleetd-agent`	`/usr/bin/fleetd-agent`
Конфигурация	`/etc/fleetd/agent.yaml`	`/etc/fleetd/agent.yaml`
Описание службы	`/etc/systemd/system/fleetd-agent.service`	`/etc/init.d/fleetd-agent`
Состояние новой установки	`/var/lib/fleetd`	`/etc/fleetd`
Журнал	systemd journal	Системный журнал OpenWrt

Юнит systemd указывает агент в ExecStart, включает Restart=always с задержкой пять секунд и порядок относительно network-online.target.

Для OpenWrt создаётся init-файл с USE_PROCD=1, порядком старта, командой и параметрами respawn. Стандартный вывод и ошибки направляются в системный журнал. В обеих ветках запускается одна точка входа и читается одинаковый формат YAML. Различия дистрибутивов остаются в установке и интеграции службы.

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

Порядок загрузки тоже не гарантирует доступность удалённой стороны. Сетевая цель systemd или поздний старт OpenWrt не доказывают готовность DNS, внешнего канала и сервера. Обработка ошибок соединения необходима в любом случае.

В OpenWrt важно место хранения состояния

Это прямо влияет на защиту от повторов из прошлой статьи. На обычном сервере подходит /var/lib/fleetd. В распространённых конфигурациях OpenWrt /var опирается на временное хранилище в RAM. Перезапуск процесса и перезагрузка устройства по-разному влияют на эти файлы.

Поэтому установщик OpenWrt задаёт state_dir: /etc/fleetd. У трёх файлов разные задачи:

Файл	Назначение
`agent.yaml`	Соединение, доверенные ключи, права и каталог состояния
`agent.key`	Собственный ключ идентичности агента
`seen.json`	ID принятых запросов для защиты от повторов

Первые два по умолчанию находятся в /etc/fleetd. seen.json следует за state_dir: новая установка systemd использует /var/lib/fleetd, OpenWrt — /etc/fleetd.

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

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

Сохранение на flash имеет стоимость записи. Текущий агент обновляет записи при принятии новых авторизованных запросов, а не при каждом десятисекундном отчёте метрик. Для высокочастотного выполнения задач придётся заново оценить частоту сохранения и свойства flash. Измеренных гарантий ресурса или производительности здесь нет.

Сохранение настроек не равно автоматическому восстановлению

В OpenWrt установщик добавляет /etc/fleetd/ в /etc/sysupgrade.conf. Это помогает сохранить настройки и идентичность при обновлениях, поддерживающих и использующих сохранение конфигурации. Но не гарантирует сохранность /usr/bin/fleetd-agent и /etc/init.d/fleetd-agent.

После прошивки настройки могут остаться, а программу или init-файл понадобится установить снова. Сброс к заводским параметрам и обновление без сохранения настроек этим механизмом не покрываются.

При проверке восстановления выясните:

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

Это рекомендуемые проверки, а не отчёт о проведённой для статьи перепрошивке.

Повторная установка сохраняет существующий agent.yaml, меняет программу и перезаписывает определение службы. Это удобно для восстановления, но новые --permission, --server и --signer не заменяют сохранённые настройки автоматически. Старый неправильный путь состояния тоже не исправится сам: нужно проверить файл и перезапустить агент после изменения.

Общий агент не означает одинаковую полноту мониторинга

Базовые показатели берутся главным образом из /proc: CPU, память, нагрузка, uptime и накопленный сетевой трафик. Для загрузки CPU и скорости сети нужны две выборки. Первая после запуска не представляет полный интервал измерения. При пересоздании интерфейса и уменьшении счётчиков расчёт скорости для этой выборки пропускается.

Расширенный сбор зависит от окружения:

Показатель	Текущая зависимость
Службы в состоянии failed	`systemctl list-units --state=failed`
Контейнеры	`docker ps -a`
Пиры WireGuard	`wg show all dump`

Запуск под procd не означает реализацию контроля здоровья служб procd. Поиск отказавших служб пока использует systemd. Если внешняя программа отсутствует или завершается с ошибкой, соответствующий сборщик не возвращает данные, а базовый мониторинг может продолжаться. Это позволяет не требовать Docker на каждом маршрутизаторе, но отсутствие сведений об отказе не доказывает исправность всех служб.

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

Базовые отчёты запланированы каждые десять секунд, диски, службы, контейнеры и WireGuard — каждые шесть раундов. Это расписание, не строгая гарантия реального времени: внешние команды, сеть и нагрузка влияют на фактические интервалы.

Проверять всю рабочую цепочку

Для постоянного агента важны старт, надзор за процессом, переподключение и сохранение идентичности после перезагрузки. На systemd начните со статуса и последних записей:

systemctl status fleetd-agent
journalctl -u fleetd-agent -n 50 --no-pager

На OpenWrt:

logread -e fleetd

Это диагностика, а не перезагрузка устройства. Для применения настроек используйте systemctl restart fleetd-agent либо /etc/init.d/fleetd-agent restart на OpenWrt.

Затем проверьте одобрение и обновляющееся время отчётов в панели, дождитесь следующих выборок CPU и сети. Наблюдаемое устройство может оставаться в monitor: ради проверки не нужны root-команды.

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

CI содержит тесты и сборки amd64/arm64, но успешная кросс-компиляция не проверяет каждый образ OpenWrt на реальном устройстве. Статья также не содержит измерений RAM, CPU или минимальной flash: проверяйте свободное место и наблюдайте свою нагрузку.

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