Средний

5 мин

6.5K

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

Ранее Test IT позволяла клиентам использовать готовые сборки под Ubuntu или CentOS с запуском в контейнерах. Однако рынок идет вперед и клиентам требуется нативный дистрибутив под RedOS 8.02 с официальным подтверждением совместимости и внесением в реестр отечественного ПО.

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

• Разработали работающую сборка на RedOS 8.02

• Автоматизировали процесс непрерывной интеграции и доставки (CI/CD)

• Успешно провели более 1700 автоматических тестов

• Выполнили исчерпывающее нагрузочное тестирование

Как итог, получили официальный сертификат совместимости от вендора RedOS.

Зачем компаниям нужна поддержка RedOS

RedOS — российский дистрибутив операционной системы на базе Red Hat Enterprise Linux. Он включен в единый Реестр отечественного программного обеспечения, что делает его приоритетным выбором для организаций, работающих по требованиям импортозамещения.

Ключевые причины запросов на RedOS:

• Соответствие нормативным требованиям — при закупках и аудитах проверяется наличие сертифицированной совместимости

• Требования информационной безопасности — RedOS включен в перечень доверенных ОС для критически важных систем

• Долгосрочная поддержка — гарантия обновлений и технической поддержки на государственном уровне

Наши клиенты используют две модели поставки платформы для управления тестированием:

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

• Локальное развертывание — для организаций с требованиями по хранению данных на собственных серверах

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

Этапы реализации проекта

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

Этап 1. Подготовка сборки для RedOS

Первыми шагами стали тестовые сборки наших и внешних компонентов на базовом образе Redos 8.0.2. 

Несмотря на то, что система управления тестированием построена на кроссплатформенных технологиях, возникло несколько затруднений, а именно:

• Появление новых уязвимостей

• Конфликты ряда библиотек

• Выполненные работы:

• Все внутренние компоненты пересобраны с alpine на redos

• Все внешние компоненты пересобраны с alpine на redos

• Исправлены все появившиеся уязвимости

Этап 2. Автоматизация процесса сборки и развертывания

Ранее создание сборки для новой операционной системы требовало ручной работы DevOps-специалиста в течение 1-2 дней. Для промышленного использования такой подход неприемлем — необходима воспроизводимость и предсказуемость процесса.

Реализованное решение:

• CI/CD

• Сборка компонентов

• Push в локальный registry

• Проверка кода SonarQube

• Проверка на наличие уязвимостей Trivy

• Деплой в контур тестирования

• Тестирование

• Создание пакетов поставки для установки в k8s и docker

Результат: настройка автоматизации заняла 15 рабочих дней (совместная работа DevOps и QA). После завершения процесс стал полностью повторяемым.

Этап 3. Функциональное тестирование: автоматизация проверки качества

Существующая библиотека автоматических тестов включает более 1700 сценариев (JUnit + Selenide для пользовательского интерфейса, REST Assured для API).

Процесс тестирования:

1. Автоматические тесты — запуск полного набора на сборке под RedOS через систему непрерывной интеграции

2. Выявление проблем — часть тестов не прошла из-за различий в путях к файлам и правах доступа

3. Устранение проблем — корректировка тестовых сценариев и настроек окружения

4. Финальная проверка — все 1700+ тестов выполнены успешно

Дополнительно: проведено ручное дымовое тестирование (smoke testing) базовых сценариев — установка, запуск интерфейса, создание тест-кейсов.

Этап 4. Нагрузочное тестирование системы

Клиенты, использующие RedOS, часто представляют крупные предприятия с тысячами пользователей. Критически важно подтвердить, что система сохраняет производительность под высокой нагрузкой.

Сценарий 1: Пользовательская нагрузка

• Эмуляция 500 одновременно работающих пользователей

• Действия: создание тест-планов, запуск проверок, загрузка вложений

• Инструменты: JMeter + собственный генератор нагрузки

Сценарий 2: API-нагрузка

• 10 000 запросов в минуту к различным точкам подключения API

• Критерий успеха: 95-й процентиль времени отклика не более 500 мс

Обнаруженные проблемы:

• Снижение скорости файловых операций из-за настроек монтирования (решено оптимизацией параметров ядра)

• Консервативные настройки PostgreSQL по умолчанию (скорректирован параметр shared_buffers)

Результат: после оптимизации производительность соответствует эталонной системе на Ubuntu 20.04.

Результаты проекта

Преимущества для бизнеса и клиентов

Для клиентов:

• Возможность использовать платформу для управления тестированием на отечественной операционной системе

• Соответствие требованиям импортозамещения и информационной безопасности

• Отсутствие рисков при аудитах и закупочных процедурах

• Техническая поддержка на всех уровнях (ОС и приложение)

Для компании:

• Сохранение и расширение присутствия на растущем рынке импортозамещения

• Конкурентное преимущество перед решениями без поддержки RedOS

• Оптимизация внутренних процессов DevOps и QA

• Дополнительная маркетинговая ценность (официальная сертификация)

Практические рекомендации

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

1. SELinux требует внимания — изучите создание политик безопасности (.te-файлы) и управление контекстами. Отключение SELinux недопустимо для клиентов с требованиями ИБ.

2. Версии OpenSSL различаются — если приложение использует устаревшие криптографические алгоритмы, потребуется настройка crypto-policies или модификация кода.

3. systemd имеет особенности — изучите нюансы работы параметров перезапуска и зависимостей служб именно в RedOS.

4. Тестируйте нагрузку — различия в настройках ядра и файловой системы могут влиять на производительность непредсказуемым образом.

Автоматизация процессов сборки и тестирования обеспечила воспроизводимость и стабильность решения. Полученный опыт позволяет эффективно адаптировать продукт под другие отечественные операционные системы.

Вот такой у нас вышел технический проект.