Роли нод и установка

Требования к ролям одинаковы для нод на ваших серверах и для ВМ, созданных через Opfield.

Роль ноды определяет, чем Opfield сможет управлять на этом сервере: Ingress, Docker, базами данных, сборками, мониторингом или Relay. Вместе с ролью устанавливается нужный набор программ и выдаются только необходимые полномочия. Выбирайте роль по назначению сервера, а не по пакетам, которые уже случайно на нём установлены.

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

Что требуется каждой роли

Используйте сгенерированную команду установщика из сценария создания ноды. Она содержит ограниченные регистрационные данные и закреплённую идентичность Opfield.

nginx: требует nginx, публичных портов Ingress там, где они нужны, валидации конфигурации и доступа к журналам.
Docker: требует поддерживаемый Docker Engine и права на настроенные операции среды выполнения. Установщик также ставит сторожевой процесс аренды gateway-lease-watchdog — отдельную службу, которая нужна переключению на уровне данных на нодах, держащих аренду Availability. На ноде, установленной до появления сторожевого процесса, его ставит сам Docker-демон, если он работает от root с systemd или OpenRC; если демон установлен с --user <non-root user>, повторно запустите установщик ноды Docker через sudo с тем же --user, потому что неинтерактивный запуск иначе переводит службу демона на root. Каждый управляемый том на образе диска занимает одно loop-устройство, а демон устанавливает шаг загрузки gateway-volume-images, который монтирует эти тома до запуска Docker.
storage: запускает Docker-демон от root и требует выделенного хранилища, loop-устройств и возможности монтирования; до регистрации установщик форматирует, монтирует, увеличивает и отключает тестовый образ и останавливается, если хост этого не позволяет. Каждая управляемая база данных, участник объектного хранилища и идущее резервное копирование занимают одно loop-устройство, поэтому гостю LXC нужно, чтобы хост передал ему /dev/loop-control и набор loop-устройств с запасом на всех них. Ноде нужен исходящий HTTPS к ghcr.io для исполнителя резервного копирования. Прежний режим databases принимается как псевдоним. См. Требования к нодам хранилища и нодам Docker.
builder: требует systemd и выделенную ёмкость BuildKit/containerd и не должен иметь сокет Docker Engine. На хосте без systemd установщик останавливается до того, как что-либо установит или скачает.
monitoring: предоставляет поддерживаемый сбор данных мониторинга.
Relay supervisor/worker: расширяет ёмкость и устойчивость Relay с явным размещением.

После установки проверяйте отчёт о возможностях, а не делайте вывод по наличию пакетов на хосте. Функции GPU, Secure Runtime, builder, хранилища и миграции зависят от сообщённых работоспособных возможностей.

Выберите роль

Ingress: завершает TLS и обслуживает публичные Domains и Routes. Ему нужны валидация конфигурации nginx, хранилище сертификатов, журналы и публичные порты там, где они требуются.
Docker: управляет обычными рабочими нагрузками приложений и ресурсами Docker. Ему нужны поддерживаемый Docker Engine и права для выбранных функций среды выполнения.
Build Worker: запускает сборки Git в изолированных службах BuildKit/containerd. Он должен быть выделен под сборки и не должен открывать профилю builder обычный сокет Docker Engine.
Storage: запускает управляемые PostgreSQL, Redis и ClickHouse, управляемое объектное хранилище SeaweedFS и задания резервного копирования баз данных с отдельной подготовкой хранилища и ограниченным профилем Docker-демона. Обычные контейнеры приложений и сборки отклоняются. Ноды, зарегистрированные с прежней ролью Databases, сохраняют идентичность, регистрацию, конфигурацию и данные; обновление демона включает возможности хранилища без повторной регистрации и переноса данных.
Monitoring: собирает поддерживаемые данные о состоянии и метрики хоста без прав на жизненный цикл рабочих нагрузок.
Relay: устанавливает supervisor Relay, объявляет доступный адрес и присоединяется к Relay Pool для Secure Link.

Стандартный поток регистрации

Откройте Nodes и выберите Add Node.
Выберите нужный Node Type и прочитайте описание.
Введите стабильное имя, понятное оператору.
Для Relay укажите адрес, к которому участвующие ноды могут обратиться по TCP 9443.
Создайте ожидающую ноду.
Скопируйте сгенерированную одноразовую команду установки. Она относится к тому Opfield, который её показал: скачивает установщик из выпуска этого Opfield, запускает его только после совпадения контрольной суммы с выпуском и закрепляет самый новый демон той же линии выпусков.
Выполните команду на нужном Linux-хосте.
Оставьте диалог результата открытым, пока демон устанавливается и регистрируется; он закроется автоматически, когда именно эта нода перейдёт в состояние online.
Откройте страницу ноды и проверьте роль, имя хоста, версию, возможности, метрики и служебные адреса.

Действие Add relay node в настройках Relay открывает тот же сценарий с заранее выбранным и заблокированным типом Relay. Участник Relay отображается как готовая ёмкость пула только после успешной регистрации и передачи состояния.

Подготовка хоста

Используйте выделенный хост или виртуальную машину, если роль образует сильную границу доверия. До запуска установщика проверьте DNS, системное время, исходящую доступность Relay, требования к пакетам и среде выполнения, постоянное хранилище и наличие systemd или OpenRC. Не используйте команду установщика для другой ожидающей записи ноды.

Для нод хранилища установщик выполняет предварительную проверку хранилища. Build Workers требуют выделенных вычислительных ресурсов и хранилища. Нодам Relay нужен доступный объявленный адрес; если Relay Pool должен обеспечивать устойчивость, размещайте ноды в разных доменах отказа.

Что проверяет установщик

Подключение. Запуск установщика и каждый повторный запуск на зарегистрированной ноде успешны, только если запущенный демон работает под systemd или OpenRC и Opfield принял его сессию. Иначе установщик завершается с ошибкой, называет журнал демона и выводит его последние строки; сессию он ждёт до 90 секунд. Об уже использованном или просроченном токене установщик сообщает как об отказе Opfield. На хостах без systemd и OpenRC демон запускается отдельным процессом запуска, который не переживает перезагрузку.
Повторный запуск команды установки. Повторный запуск собственной команды установки ноды с уже использованным токеном сохраняет регистрацию и выполняется как повторный запуск без токена. Другой токен на зарегистрированном хосте не используется: установщики Docker и monitoring завершаются с ошибкой и ничего не меняют (на ноде, зарегистрированной до 2.11.1, они предупреждают и продолжают обновление), а установщик nginx регистрирует ноду с новым токеном, но сохраняет прежнюю регистрацию, если Opfield его отклонил. Чтобы зарегистрировать хост как другую ноду, остановите демон, перенесите в сторону его каталог certs и state.json и выполните новую команду.
Ответы. Без -y установщик задаёт вопросы в терминале и останавливается, если не может прочитать ответ, например без терминала или когда его вывод передаётся через tee; отсутствие ответа никогда не считается согласием. Отказ на вопрос Proceed with installation? или остановка после сводки завершаются ошибкой.
Secure Runtime. Новая установка ноды Docker настраивает Secure Runtime, если хост его поддерживает. На хосте без поддержки или при сбое настройки установщик предупреждает с указанием причины и продолжает, а нода сообщает ту же причину в своих возможностях. С --secure-runtime установка в этом случае завершается ошибкой; этот флаг также ставит Secure Runtime в существующую установку. В существующий /etc/docker/daemon.json настройка добавляет только runtimes.runsc, предварительно один раз сохранив исходный файл как daemon.json.gateway-backup; остальные ключи остаются как были.
Версия демона. Без --version установщик ставит последний стабильный релиз демона, но повторный запуск никогда не ставит демон старше уже установленного, например на ноде с более новым предварительным релизом. В этом случае он выводит установленную версию и релиз, на который указывает latest, и оставляет установленную версию. Чтобы поставить более старый релиз, укажите его в --version (для установщиков демонов — GATEWAY_NODE_DAEMON_VERSION). Это относится к установщикам Docker, Build Worker, хранилища, nginx, monitoring и Relay.
Резервные копии. Когда установщики monitoring, nginx и Docker заменяют файл, например бинарный файл демона или конфигурацию nginx, они хранят только самую новую резервную копию этого файла (<file>.backup.<timestamp>).

Запуск демона без root

Демоны monitoring, Docker (профиль docker), nginx и Relay могут работать от существующего пользователя без root: передайте --user <user> установщику monitoring, Docker или nginx либо задайте GATEWAY_RELAY_RUN_USER (и при необходимости GATEWAY_RELAY_RUN_GROUP) для установщика Relay. Сам установщик по-прежнему запускается через sudo и останавливается до изменений на хосте, если такого пользователя нет. Ноды хранилища и Build Workers работают только от root.

Смена пользователя. Повторно запустите установщик ноды с другим --user или без --user, чтобы вернуться к root. Нода сохраняет регистрацию и идентичность хоста; зарегистрированному Relay для такого запуска --token не нужен. На нодах Docker и nginx установщик готовит всё, пока демон продолжает работать, и останавливает его непосредственно перед запуском нового процесса; демон мониторинга и supervisor Relay останавливаются в начале. Демон останавливается до того, как у его файлов сменится владелец. Смена пользователя один раз перезапускает демон: соединения через его привязки баз данных, привязки хранилища и связи контейнеров один раз обрываются примерно на 1,5 секунды, и клиенты переподключаются, как при любом перезапуске демона. Трафик Routes через Secure Links только ждёт, потому что под systemd демон ноды Docker или nginx передаёт свои сокеты связей systemd, который сохраняет их на время смены. На ноде Docker, где привязки хранилища ещё используют отдельные контейнеры-коннекторы из версий до 2.11.1, смена пользователя также пересоздаёт эти контейнеры. Прежний пользователь остаётся в группах, в которые его добавил установщик, например docker; удалите его оттуда командой gpasswd -d <user> docker.
Docker. Установщик добавляет пользователя в группу docker, что равносильно root на хосте. Без root недоступны тома на образе диска, перенос данных томов между нодами, размеры журналов контейнеров и установка Secure Runtime из Opfield; чтобы установить Secure Runtime, повторно запустите установщик с тем же --user и --secure-runtime (команду показывает страница ноды). Сторожевой процесс аренды по-прежнему работает как служба от root.
nginx. Сам nginx уже должен работать от того же пользователя с CAP_NET_BIND_SERVICE, а пользователю должны принадлежать /etc/nginx, /var/log/nginx и временные каталоги nginx; используйте --nginx-mode integrate. Проще всего запускать nginx от его пользователя из дистрибутива (www-data или nginx) и устанавливать демон от этого же пользователя. Под OpenRC задайте command_user="<user>:<group>" и capabilities="^cap_net_bind_service" в /etc/conf.d/nginx и pid /run/nginx/nginx.pid; в nginx.conf. Если nginx работает не от этого пользователя, установщик останавливается до любых изменений и перечисляет, что нужно подготовить. Чтобы вернуться к root, сначала снова запустите nginx от root.
Relay. Порт Relay ниже 1024 требует systemd или OpenRC; установщик выдаёт право на привязку к нему.
Консоль хоста. console.user в конфигурации демона запускает сеансы консоли от другого пользователя только у демона, работающего от root. Демон, работающий от своего пользователя, отказывает в сеансах консоли, пока console.user указывает другого пользователя (409 NODE_CONSOLE_USER_UNAVAILABLE), а страница ноды называет решение: удалить console.user или запустить демон от root.

Alpine, OpenRC и гости LXC

Установщики поддерживают OpenRC наравне с systemd, в том числе для демонов, работающих от своего пользователя. Ноде Docker нужно, чтобы Docker мог выдавать контейнерам контроллеры cgroup memory, pids и cpu: коннектор защищённых связей и управляемые нагрузки работают с ограничениями. Установщик проверяет это и отказывается регистрировать ноду, если контроллера нет; настройку cgroup хоста он не меняет.

На госте LXC с Alpine и OpenRC корневая cgroup часто не передаёт контроллеры дальше, потому что в ней находятся все процессы. Пусть служба OpenRC cgroups перенесёт процессы до включения контроллеров: выполните rc-update add cgroups boot, поместите следующее в /etc/conf.d/cgroups и перезагрузите гостя.

# Move every process out of the root cgroup so that the cgroups service can pass the controllers down.
start_pre() {
  [ -w /sys/fs/cgroup/cgroup.subtree_control ] || return 0
  mkdir -p /sys/fs/cgroup/init
  for pid in $(cat /sys/fs/cgroup/cgroup.procs); do
    echo "$pid" > /sys/fs/cgroup/init/cgroup.procs 2>/dev/null
  done
  return 0
}

Затем проверьте командой cat /sys/fs/cgroup/cgroup.subtree_control /sys/fs/cgroup/docker/cgroup.controllers: оба файла должны содержать memory, pids и cpu. Менять конфигурацию контейнера LXC на гипервизоре для этого не нужно.

Проверка и очистка

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

Ошибки установки

После неудачного запуска установщик nginx-ноды можно выполнить на том же хосте ещё раз; повторный запуск сохраняет режим Nginx существующей установки. Если команда не может скачать или запустить демон, проверьте исходящий HTTPS, DNS, системное время, состояние менеджера пакетов, архитектуру и свободное место. Если демон запустился, но регистрация не завершается, проверьте доступность Relay, не был ли одноразовый токен уже использован и относится ли команда к ожидающей ноде из открытого диалога. Не создавайте несколько ожидающих записей и не подменяйте их команды.

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

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

Безопасность после установки

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

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