Требования и планирование

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

Opfield — привилегированный контур управления

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

Определите схему развёртывания

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

До установки зафиксируйте:

• постоянный HTTPS-адрес, по которому пользователи и управляемые ноды будут открывать Opfield;
• владельцев DNS, сертификатов, аутентификации, резервного копирования и обновлений;
• сети, из которых доступны веб-приложение и Relay;
• роли нод, нужные сразу, и роли, которые можно добавить позднее;
• требуемый тарифный план и права на функции;
• допустимое время восстановления и допустимую потерю данных Opfield, включая ключи шифрования.

Не начинайте с временного IP-адреса или доменного имени, которое планируете заменить после запуска. Основной URL используется в защите браузера, URI перенаправления, командах подключения нод и интеграциях, поэтому его последующая смена затронет сразу несколько частей системы.

Решение по хосту и ёмкости

Подготовьте поддерживаемый Linux-сервер с доступом root или рабочим sudo. Заранее устанавливать Docker не требуется: установщик сам добавит официальный репозиторий Docker, установит Docker Engine и модуль Compose v2 и запустит службу. Автоматическая установка поддерживает Debian, Ubuntu, Fedora, CentOS и RHEL. Если Docker уже установлен, скрипт проверит его и использует существующую установку.

Для центрального сервера Opfield используйте следующие ориентиры:

Профиль	CPU	Память	Свободное место на SSD
Минимальный	2 vCPU	4 GB RAM	32 GB
Рекомендуемый	4 vCPU	8 GB RAM	64 GB

В таблице указано свободное место после установки операционной системы. Если структурированные журналы будут храниться в локальном ClickHouse под управлением Opfield, дополнительно потребуется минимум 32 GB, а для длительного хранения рекомендуется от 128 GB. Точный объём зависит от количества событий и срока хранения. При подключении внешнего ClickHouse эти данные не занимают диск сервера Opfield.

Выделите постоянное хранилище для PostgreSQL Opfield, данных Redis (если их сохранение включено), загружаемых материалов, сертификатов, конфигурации, внутреннего реестра образов и необязательных структурированных журналов. Сборки из Git требуют дополнительного места: Opfield хранит текущие и резервные версии, незавершённые сборки и версии, которые оператор закрепил вручную. Собственные контейнеры Opfield — приложение, Relay, реестр образов, PostgreSQL и Redis — хранят не больше трёх файлов журнала по 50 МБ каждый; обновление добавляет это ограничение в существующие установки, если у службы ещё нет собственных настроек журналирования.

Также как минимум обеспечьте:

• запас процессора и памяти для приложения, PostgreSQL, Redis и Relay без постоянного использования раздела подкачки;
• постоянное хранилище с мониторингом свободного места и проверенным местом назначения резервных копий;
• корректное системное время и надёжное разрешение DNS;
• процедуру обновления ОС, которая не удаляет и не заменяет постоянные тома;
• доступ к текущему подписанному релизу Opfield и службе лицензирования.

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

Для оператора: сетевой доступ

Публичной установке обычно нужен входящий HTTP/HTTPS для интерфейса и API. Управляемые ноды подключаются через Relay; если они находятся вне локальной сети, адрес Relay должен быть доступен по 9443/tcp. Административный доступ стоит ограничить на сетевой границе. Прокси или межсетевой экран перед Relay допустимы только в том случае, если они поддерживают долгоживущие соединения и не обрывают их по короткому тайм-ауту.

Необходимый исходящий доступ зависит от включённых функций. Обычно Opfield обращается к поставщикам аутентификации, ACME- и DNS-службам, системам контроля версий, реестрам контейнеров, службам обновления и лицензирования, адресам электронной почты и вебхуков, SIEM и настроенным поставщикам AI. Для Build Worker лучше определить отдельные и более строгие правила исходящего доступа.

Некоторым ролям нод нужно больше:

• Ноды хранилища загружают исполнитель резервного копирования из GitHub Container Registry, поэтому им нужен исходящий HTTPS к ghcr.io. Управляемые движки (SeaweedFS, PostgreSQL, Redis, ClickHouse) и вспомогательный контейнер Compose на нодах Docker загружаются по дайджесту сначала из зеркала Opfield на ghcr.io, а при неудаче — из Docker Hub.
• Workload Availability в режиме аренды: каждая нода Docker политики и каждая нода Ingress её Routes должны достигать каждого Relay пула по его объявленному порту; см. Переключение на уровне данных.

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

Роли нод и границы доверия

Выбирайте только нужные роли:

• Нода Ingress: маршруты, TLS, Pages, журналы доступа и ошибок и метрики трафика;
• Нода Docker: контейнеры, развёртывания, Compose Project, файлы, журналы и фактическое состояние служб;
• Нода хранилища: управляемые экземпляры PostgreSQL, Redis или ClickHouse, управляемое объектное хранилище, их постоянное хранилище и задания резервного копирования баз данных;
• Build Worker: изолированное выполнение BuildKit/containerd без передачи сокета Docker Engine;
• Нода Monitoring: специализированный сбор метрик поддерживаемых систем;
• Relay: дополнительная пропускная способность и отказоустойчивость прямых защищённых соединений Secure Link.

Требования к нодам хранилища и нодам Docker

Нода хранилища запускает Docker-демон от root и держит каждую управляемую базу данных, кластер объектного хранилища и рабочую область резервного копирования в ext4-образе фиксированного размера на loop-устройстве, поэтому занимаемое ими место ограничено. Установщик проверяет это до регистрации: форматирует, монтирует, увеличивает и отключает тестовый образ и останавливается, если хост этого не позволяет. Каждая управляемая база данных, участник объектного хранилища и идущее резервное копирование занимают одно loop-устройство, пока существуют. Виртуальные машины и физические серверы создают loop-устройства по мере надобности. Гость LXC подходит, только если хост передаёт ему /dev/loop-control и набор loop-устройств и разрешает блочные loop-устройства и монтирование; рассчитывайте этот набор на все управляемые экземпляры и одновременные резервные копирования, которые будет держать нода. Когда свободных устройств не остаётся, создание экземпляра завершается ошибкой node has no free loop device; устройства удалённых экземпляров демон освобождает сам.

На ноде Docker управляемый том на образе диска тоже занимает одно loop-устройство. Для переключения на уровне данных на каждой ноде Docker, которая может держать аренду Availability, работает сторожевой процесс аренды — служба root под systemd или OpenRC; его ставит установщик ноды Docker.

Ноде Docker также нужно, чтобы Docker мог выдавать контейнерам контроллеры cgroup memory, pids и cpu; иначе установщик отказывается регистрировать ноду. Гостю LXC с Alpine и OpenRC обычно сначала нужна настройка cgroup; см. Alpine, OpenRC и гости LXC. Build Worker требует systemd. Демоны monitoring, Docker, nginx и Relay могут работать без root; см. Запуск демона без root.

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

Нода Docker обычно управляет локальным Docker Engine. Тот, кто контролирует этот путь, может запускать привилегированные Containers, подключать каталоги хоста и влиять на другие рабочие нагрузки в том же движке. Считайте ноду Docker границей доверия уровня root на соответствующем хосте. Используйте отдельный сервер или осознанно принятую общую границу рабочих нагрузок; права на ресурсы не изолируют систему от скомпрометированного администратора хоста.

DNS и сертификаты

Решите, будет ли Opfield управлять DNS через Cloudflare или записи останутся под внешним управлением. Для выпуска сертификата через HTTP-01 назначенной ноде Ingress нужен публичный порт 80. Для DNS-01 настройте интеграцию с минимальными правами на создание проверочных записей. Если сертификаты загружаются вручную, заранее назначьте ответственного за продление и контроль срока действия.

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

Проверка готовности

До запуска установщика подтвердите всё перечисленное:

1. Основное доменное имя указывает на нужный адрес.
2. Определено, где завершается TLS и кто отвечает за передаваемые прокси-заголовки.
3. Подготовлены постоянное хранилище и внешнее место для резервных копий.
4. Межсетевой экран пропускает веб-трафик, соединения Relay и необходимые исходящие запросы.
5. Назначены первый администратор и второй ответственный с доступом для восстановления.
6. Роли нод и изоляция хостов выбраны осознанно.
7. Зафиксированы сроки хранения данных, требования к аудиту, уведомлениям и SIEM.
8. Доступны необходимые права тарифного плана.

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

Перед изменением межсетевого экрана см. раздел Порты и сеть.