ПРОДУКТ / КОНТЕЙНЕРНЫЙ ХОСТ

Приложения — в контейнерах.
Система — под контролем.

НАЙС.ОС Контейнерный хост — специализированная операционная система для запуска приложений через Docker Compose. Системный слой обновляется как согласованное развёртывание на rpm-ostree.

Коробка НАЙС.ОС Контейнерный хост для Docker Compose

01 / УСТРОЙСТВО

У каждого слоя —
своя задача.

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

Compose-файл описывает сервисы, сети и подключаемые хранилища приложения. Базовая ОС содержит системные компоненты для работы хоста и контейнерной среды.

Такой подход помогает отделить изменения приложения от изменений операционной системы. Он требует отдельного управления версиями контейнерных образов, конфигурацией и данными.

АРХИТЕКТУРА / DOCKER COMPOSE

Приложение, ОС и данные — отдельные слои.

ПРИКЛАДНОЙ СЛОЙ

Веб-сервисБаза данныхФоновые задачи

Docker ComposeОписание и запуск приложения

Docker EngineСреда выполнения контейнеров

НАЙС.ОС Контейнерный хостЯдро Linux · системный слой на rpm-ostree

Обновление системного образа не обновляет контейнеры приложения и не заменяет резервное копирование данных.

02 / RPM-OSTREE

Обновление целой версии ОС.

01
Собираем системную версию
RPM-пакеты входят в состав базового системного образа. Версия ОС представляет согласованный набор компонентов.
02
Подготавливаем новое развёртывание
rpm-ostree загружает необходимые изменения и подготавливает новую версию системного слоя. В обычном процессе работающая версия не заменяется по частям.
03
Переключаем при перезагрузке
Новая версия становится активной после перезагрузки. Время переключения планируется с учётом доступности приложений.
04
Сохраняем путь возврата
При сохранённом предыдущем развёртывании можно выполнить откат системного слоя. Совместимость конфигурации и прикладных данных проверяется отдельно.

RPM-OSTREE / ПЕРЕХОД МЕЖДУ ВЕРСИЯМИ

Новая версия готовится до переключения.

01
Работает версия A
Текущее системное развёртывание обслуживает приложения.
02
Готовится версия B
Новый системный образ разворачивается отдельно.
03
Перезагрузка
В согласованное окно хост запускается с новой версией ОС.
04
Проверка сервисов
Администратор проверяет запуск и состояние приложения.

Если новый системный слой не подошёл

Можно выбрать предыдущее развёртывание ОС. Данные приложения восстанавливаются по отдельному плану.

03 / ПРАВИЛА ОБНОВЛЕНИЯ

Еженедельно.
При критических CVE — вне плана.

Регулярно выпускаем обновлённый образ базовой ОС.

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

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

Плановый выпуск: Обновлённый системный образ каждую неделю
Критическая CVE: Внеплановый выпуск, если уязвимость затрагивает поставку и исправление подготовлено и проверено
Применение: Владелец инфраструктуры выбирает окно установки и перезагрузки
Контейнеры: Обновляются отдельно от системного образа

Почему важна скорость исправлений

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

04 / РАЗДЕЛЕНИЕ ДАННЫХ

Что меняется при обновлении.

Область	Правило эксплуатации
Системный слой /usr	Управляется как часть развёртывания ОС; обычная модель — чтение без произвольного изменения файлов
Конфигурация /etc	Сохраняется и согласуется по правилам OSTree. Изменения конфигурации нужно учитывать при проверке обновления и отката
Изменяемые данные /var	Хранятся отдельно от версии системного слоя; требуют собственных резервных копий
Контейнерные образы	Версии выбирает владелец приложения. Обновление ОС не заменяет образы сервисов
Тома и базы данных	Резервируются и восстанавливаются средствами приложения и инфраструктуры

Откат ОС не заменяет резервное копирование

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

ГРАНИЦЫ ОБНОВЛЕНИЯ

Что относится к версии ОС, а что — нет.

01/usrСистемный слой

Версионируется вместе с развёртыванием ОС.

Образ ОС

02/etcКонфигурация

Сохраняется и согласуется по правилам OSTree.

Контроль настроек

03/varИзменяемые данные

Живут отдельно от версии системного слоя.

Резервные копии

Откат ОС не возвращает прежнее состояние базы данных или контейнерного тома. Перед изменением приложения нужен проверенный бэкап.

05 / ПРИМЕНЕНИЕ

Когда эта редакция подходит.

Приложение уже описано в Compose

Редакция подходит для серверов, где прикладной стек поставляется в контейнерах: веб-сервисов, внутренних систем и отдельных прикладных комплексов. Доступность ресурсов и совместимость проверяются для конкретного приложения.

Нужна одинаковая базовая ОС

Фиксация версии системного развёртывания упрощает сопоставление состояния нескольких хостов и разбор изменений между выпусками.

Что нужно учитывать

Перезагрузки требуют окна обслуживания.
Docker Compose сам по себе не обеспечивает отказоустойчивость нескольких узлов.
Контейнеры используют ядро хоста; совместимость нужно проверять.
Приложения и их данные сопровождаются отдельно.
Установка произвольного прикладного стека непосредственно в ОС выходит за основную модель редакции.

06 / ПОЛУЧЕНИЕ

Образ под вашу среду.

Уточните доступную поставку и способ подключения к репозиторию обновлений.

В запросе укажите гипервизор или облачную платформу, архитектуру, ресурсы хоста, состав Compose-приложения и ограничения доступа к сети.

Запросить поставку ↗Документация ↗

07 / СПЕЦИАЛИЗАЦИЯ

Зачем отдельная ОС для Docker Compose.

Предсказуемая роль сервера

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

В Контейнерном хосте выбран другой эксплуатационный подход. Базовая система обслуживает контейнерную среду, а приложение поставляется отдельно. Зафиксированная роль помогает обсуждать изменения и повторять конфигурацию. Это не технический запрет возможностей Linux, а назначение редакции и основа её сопровождения.

Граница между ОС и приложением

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

При выпуске новой версии проверяют обе стороны границы. Для ОС важны загрузка, сеть, диски и работа контейнерной среды. Для приложения — доступность сервисов, сохранность данных и интеграции. Такой список проверок проще поддерживать, когда прикладные службы не устанавливаются произвольно в базовую ОС.

08 / ПОЛИТИКА ИСПРАВЛЕНИЙ

Актуальные компоненты и проверяемая поставка.

Почему выпускается новый образ

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

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

Как относиться к патчам и бэкпортам

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

Практический критерий — устранена ли затрагивающая поставку проблема и проверено ли обновление. Сравнение только основных номеров версий этого не показывает. Аналогично результаты сканирования нужно интерпретировать с учётом состава, ревизий и реальных условий эксплуатации.

Как подготовить окно обслуживания

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

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

Как уменьшить простой

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

09 / ДАННЫЕ ПРИЛОЖЕНИЙ

Что важно для базы данных, файлов и секретов.

Версии контейнерных образов

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

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

Тома, резервные копии и восстановление

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

Для базы данных резервное копирование должно учитывать согласованность данных. Метод выбирается по используемой СУБД и требованиям к восстановлению. Проверяйте восстановление на отдельном стенде: наличие архивного файла ещё не подтверждает, что приложение удастся вернуть в работу.

Конфигурация и секреты

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

Наблюдение за состоянием

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

10 / ВНЕДРЕНИЕ

Какие сведения подготовить для пилота.

Сведения	Что указать
Среда	Облачная платформа или гипервизор, архитектура, CPU, память, диски и режим загрузки
Приложение	Список сервисов, версии образов, требования разработчика и внешние интеграции
Данные	Тип и объём хранилищ, допустимая потеря данных, способ резервирования и восстановления
Доступность	Допустимое окно обслуживания, требования к перезагрузкам и резервированию
Сеть	Открываемые порты, DNS, прокси, доступ к репозиториям и доверенные сертификаты
Приёмка	Какие операции, нагрузка и сценарии отказа должны быть проверены

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

ВОПРОСЫ ПО ТЕМЕ

Ответы перед выбором системы.

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

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

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

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

Все вопросы о НАЙС.ОС ↗