x2openeuler. Часть 4: Функция оценки ПО: Как это работает?

/ /

Функция оценки ПО: Как это работает?

Функционал оценки программного обеспечения в x2openEuler — это автоматизированный анализ артефактов вашего приложения. Инструмент выступает в роли опытного эксперта, который вскрывает упаковку приложения и изучает его «внутренности» на предмет совместимости с целевой средой openEuler.

Что анализируется?

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

  • Пакеты RPM: Наиболее частый случай при миграции с CentOS/RHEL.

  • Архивы с исходным кодом: TAR, а также директории с кодом.

  • Интерпретируемые языки и бинарные файлы: Скрипты Python (.py, .pyc), Java-архивы (.jar), бинарные файлы (.bin).

Уровни проверки

Результаты анализа собираются в детализированный HTML/XLS-отчет, который наглядно показывает следующие ключевые аспекты совместимости :

  1. Совместимость зависимостей (RPM-пакеты):
    Это первый и самый важный фильтр. Инструмент проверяет, сможет ли пакет программного обеспечения просто установиться в новой операционной системе. Он анализирует, все ли библиотеки и зависимости, необходимые приложению, доступны в репозиториях openEuler или могут быть корректно перенесены. Если зависимость отсутствует, инструмент укажет на это, что позволяет заранее найти замену или доработать пакет.

  2. Совместимость интерфейсов (Application Binary Interface — ABI):
    Приложение может установиться, но отказаться работать из-за изменений в системных вызовах или библиотеках. x2openEuler анализирует, какие функции динамических библиотек и системные вызовы использует ваше ПО, и сравнивает их с тем, что предлагает openEuler.

    • C/C++ интерфейсы: Проверяется бинарная совместимость. Если приложение использует устаревшую функцию, которой больше нет в новой версии библиотеки, отчет укажет на потенциальный сбой.

    • Java интерфейсы: Анализируются классы и методы, чтобы убедиться, что они не устарели и не удалены в среде выполнения openEuler.

Результат оценки: Не просто «Да» или «Нет»

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

Отчет может показать 100% совместимость интерфейсов, но предупредить, что зависимости требуют «ручной проверки» . Это позволяет расставить приоритеты: ПО с наивысшими показателями можно мигрировать автоматически, а проблемные участки взять на особый контроль.

Где это использовать?

Возможность «прицельного» анализа программного обеспечения делает x2openEuler незаменимым в ряде сценариев.

Подготовка к миграции проприетарного ПО:

У компании есть критически важное приложение, поставляемое в виде RPM-пакета от стороннего вендора, который больше не поддерживается. Просто установить его на openEuler — рискованно.
Тогда, администратор запускает x2openEuler scan для этого RPM-пакета, из отчета узнаёт, что пакет зависит от старой версии библиотеки libssl.so.10, которая отсутствует в openEuler (там используется libssl.so.11 и выше) . И становится понятно, что прямая миграция невозможна. Это дает администратору информацию для принятия решения: либо искать способ контейнеризации приложения со старыми библиотеками, либо договариваться с вендором о новой версии, либо планировать глубокий рефакторинг.

Анализ самописных приложений и скриптов:

Разработчики компании активно используют Python и Bash. Перед миграцией важно убедиться, что скрипты не используют устаревшие конструкции, которые интерпретатор в openEuler может не понять.
x2openEuler может проанализировать директорию с исходным кодом проекта на Python . Он не только проверит синтаксис, но и оценит, все ли используемые модули доступны в репозиториях openEuler в нужной версии. Это позволяет команде разработки заранее внести правки в код или обновить зависимости, сделав приложение готовым к «переезду».

Практическое применение.

Пример 1. Анализ бинарного приложения

Для примера мы просто скачаем с официального сайта firefox бинарный архив firefox-147.0.2.tar.xz и попробуем проанализировать его на предмет возможности запуска на openEuler 24.03 SP1. Для этого мы распакуем его и поместим в каталог `/opt/x2openEuler/scan` на том же сервере, где мы развернули x2openeuler:

Рисунок 4.1 Архив с firefox.

Заходим на привычный нам уже веб-интерфейс x2openeuler и создаём задачу типа «Software Package Assessment».

Рисунок 4.2 Создание задачи

Задаём ей название:

Рисунок 4.3 Название задачи

Нажимаем кнопку «Choose Software Packages»

Рисунок 4.4

В возникшем диалоговом окне выбираем радио-кнопку «Scan path» (по умолчанию путь `/opt/x2openEuler/scan`, именно в него мы разархивировали firefox), Source OS (версию ОС с которой мы мигрируем наш софт), Target OS (версия ОС, на которой мы планируем наш софт запускать и для которой мы проводим тестирование софта).

Рисунок 4.5 Выбор параметров проверки

После того, как мы кликнем «ОК», начнётся проверка, которая займёт непродолжительное время. В случае проверки firefox буквально 20-30 секунд.

Рисунок 4.6 Выполнение проверки

Всё, проверка firefox завершена и мы видим статус «Compatible», то бишь «совместима».

Рисунок 4.7 Статус завершённой проверки

Идём за подробностями, нажав «View details»:

Рисунок 4.8 Зависимости приложения

И мы видим граф зависимостей приложения firefox. Серый цвет зависимостей указывает на «openEuler replaceable package», то есть у пакета есть замена в репозитории openEuler.

Кликнув на любую зависимость это можно увидеть:

Рисунок 4.9 Зависимости приложения

Замечание: Да, довольно неудобно, что x2openeuler выводит в качестве названия анализируемого приложения не название каталога «firefox», который находится внутри каталога `/opt/x2openEuler/scan`, а почему-то только название самого верхнего каталога.

За получением подробностей кликаем на вкладку отчёта «Software Assessment Report» и видим следующий подробный список зависимостей и результат по каждой из них.

Рисунок 4.10 Отчёт по зависимостям

Можно раскрыть каждый пакет и увидеть ещё более подробную информацию, конкретно по каждой библиотеке:

Рисунок 4.11 Подробности по версиям библиотек

Пример 2. Анализ rpm

Теперь давайте попробуем проанализировать rpm. Для анализа будем использовать всё тот же percona server (percona-server-server-8.0.45-36.1.el8.aarch64.rpm). Поместим его в тот же каталог на сервере x2openeuler, где ранее мы размещали firefox (сам каталог `/opt/x2openEuler/scan/firefox` уже можно удалить, он нам больше не потребуется.

Привычно заводим задачу для оценки ПО, как мы делали в предыдущем примере, казалось бы всё делаем правильно, но получаем следующую картину:

Рисунок 4.12 Assessment Failed

А вот тут надо обратиться к Рисунок 4.5 и разглядеть, что сканирование каталога `/opt/x2openEuler/scan/` через веб-интерфейс не поддерживает анализ rpm. Ну что же, нет так нет, поэтому наш обзор закончен, всем спасибо за внимание, можно расходится.

Стоп! Но нам же обещали анализ rpm! Всё просто. Есть целых два пути сделать анализ rpm. И первый да, через веб-интерфейс — для этого надо просто переключить в диалоговом окне «Scanning Target» в позицию «Upload Software Packages». После чего выбрать в диалоговом окне загрузки файл percona-server-server-8.0.45-36.1.el8.aarch64.rpm и дождаться его загрузки на сервер:

Рисунок 4.13 Загрузка rpm для анализа

После этого анализ rpm пройдёт успешно и из него мы узнаём, что данный rpm пакет не совместим с openEuler 22.03 LTS:

Рисунок 4.14 Анализ rpm закончен

Для более детального отчёта мы можем перейти на вкладку «Software Assessment Report»:

Рисунок 4.15 Детальный отчёт по пакету

Из этого отчёта мы можем увидеть информацию по каждому rpm из зависимостей нашего пакета, и даже можно посмотреть детальную информацию по конкретной библиотеке из каждого rpm:

Рисунок 4.16 Детальный отчёт по пакету

И чтобы два раза не вставать, продемонстрируем второй способ проанализировать rpm. В этот раз мы воспользуемся не веб-интерфейсом, а консолью на сервере, где установлен x2openeuler. Копируем файл percona-server-server-8.0.45-36.1.el8.aarch64.rpm в каталог `/opt/x2openEuler/scan`, при помощи команды su становимся пользователем x2openeuler и даём команду на сканирование:

Рисунок 4.17 Сканирование вручную из консоли

Сканирование прошло успешно и отчёт сформирован. В отчёт входят следующие файлы:

Рисунок 4.18 Файлы отчёта

Копируем xls файл на ноутбук, где у нас есть офисные приложения и открываем отчёт:

Рисунок 4.19 Подробный отчёт

Да, этот отчёт содержит такую же информацию по каждому пакету (и библиотеке) из зависимостей, как и отчёт в веб версии.

Заключение

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

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

Заключение: Стоит ли игра свеч?

Данная статья завершает наш цикл статей про такой инструмент миграции как x2openeuler. И в завершении хотелось бы ещё раз сказать, что x2openEuler — это серьезный и продуманный инструмент, который закрывает огромную боль при миграции. Он не делает всю работу за вас волшебным образом, но систематизирует процесс, выявляет большинство проблем на берегу и экономит массу времени. Его главные плюсы — комплексный подход (софт, конфиги, железо), наличие удобного веб-интерфейса и обширная документация. Минусы — строгие требования к среде выполнения и осознание того, что финальное решение и ответственность все равно лежат на вас.

Если вам предстоит переезд с CentOS на openEuler (а учитывая родство дистрибутивов, это один из естественных путей), то x2openEuler — это не прихоть, а must-have инструмент в вашем арсенале.