Назад
2026/10/12
Большинство миграционных проектов начинается с решения: перейти с Oracle Java SE на OpenJDK, заменить дистрибутив Linux, срок поддержки которого истёк, или консолидировать серверы в частном облаке. На бумаге план обычно выглядит простым. Затем проектная команда обнаруживает среды выполнения Java, о которых никто не знал, серверы, за которые никто не отвечает, и приложения, незаметно зависящие от старой версии. Сроки сдвигаются, бюджеты растут.
Избежать этого можно, если начать с обследования: полной и достоверной инвентаризации того, что фактически установлено. В этой статье рассказывается, какие данные собирать, как собирать их в Windows и Linux, каких сюрпризов ожидать и как превратить результаты в план миграции.
Главное
- Проведите полную инвентаризацию Java и Linux, прежде чем планировать какую-либо миграцию.
- Для каждой среды выполнения фиксируйте полную версию, поставщика, путь и ответственного.
- Ищите не только в списках пакетов, но и в файловой системе: многие среды выполнения просто распакованы из архива или встроены в приложения.
- Распределите результаты по четырём группам (удалить, заменить, согласовать, выяснить) и планируйте на этой основе.
Почему инвентаризация предшествует миграции
Миграция хороша ровно настолько, насколько хороши сведения, на которых она основана. Без инвентаризации вы оцениваете объём работ по памяти, старым таблицам и лицензионным записям, и ни один из этих источников не отражает того, что реально работает сегодня.
Хорошая инвентаризация даёт вам три вещи:
- Объём: сколько машин, сред выполнения и приложений затронуто, чтобы реалистично оценить трудозатраты и стоимость.
- Риски: какие системы работают на неподдерживаемых версиях или без обновлений и какие из них критичны для бизнеса.
- Ответственность: кто отвечает за каждую систему, чтобы у тестирования и приёмки был однозначный ответственный.
Кроме того, она защищает вас в переговорах о лицензиях. Если поставщик спросит, сколько у вас установок, актуальная инвентаризация позволит ответить фактами, а не предположениями.
Что собирать: версии, поставщики, пути и ответственные
Для каждой установки Java соберите как минимум следующее:
- Хост: имя машины, IP-адрес и тип: сервер, виртуальная машина или рабочая станция.
- Версия: полная строка версии, например 1.8.0_202 или 17.0.10, а не просто «Java 8» или «Java 17».
- Поставщик: кто собрал среду выполнения, например Oracle или один из дистрибутивов OpenJDK. По одной лишь версии этого не определить.
- Тип и путь: полноценный JDK или только JRE, а также каталог установки.
- Использование: какие приложения или службы её используют, если это удаётся выяснить.
- Ответственный: команда или сотрудник, отвечающие за машину или приложение.
Для серверов Linux дополнительно соберите дистрибутив и его версию, версию ядра, основные установленные пакеты и запущенные службы. Так вы поймёте, какие серверы затрагивает не только миграция Java, но и миграция Linux.
Windows, Linux и рабочие станции: разные подходы
Для каждой среды нужен немного свой метод. Приведённые ниже команды служат отправной точкой; на практике команды оборачивают их в скрипт и запускают его на всех машинах с помощью уже имеющихся средств управления.
Серверы Windows
Установленные среды выполнения Java часто регистрируются в реестре Windows в разделе HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft, но далеко не все. Поиск по файловой системе надёжнее:
Get-ChildItem -Path C:\ -Filter java.exe -Recurse -ErrorAction SilentlyContinue |
Select-Object FullName, @{n='Version'; e={$_.VersionInfo.ProductVersion}}
Проверяйте все диски, а не только C:, поскольку серверы приложений часто устанавливают на отдельный диск с данными.
Серверы Linux
В Linux сочетайте менеджер пакетов с поиском по файлам, поскольку многие среды выполнения Java распаковываются из архива, а не устанавливаются в виде пакета:
cat /etc/os-release
rpm -qa | grep -i -E 'jdk|jre|java'
find / -xdev -type f -name java -perm -u+x 2>/dev/null
В Debian или Ubuntu вместо rpm используйте dpkg -l | grep -i -E 'jdk|jre'. Если запустить каждый найденный исполняемый файл java с параметром -version, он покажет версию и, как правило, поставщика. Кроме того, в большинстве каталогов JDK есть файл release, в котором указан разработчик сборки (implementor).
Рабочие станции
Рабочие станции чаще всего забывают при инвентаризации. Разработчики сами устанавливают себе JDK, а бизнес-приложения порой незаметно устанавливают среду выполнения Java. Поскольку рабочих станций много, по возможности используйте программную инвентаризацию из вашей системы управления конечными устройствами, а лёгкий скрипт запускайте только там, где этих данных нет.
Типичные сюрпризы (встроенные JRE, забытые серверы)
Почти любой проект по инвентаризации находит то, чего никто не ожидал. Чаще всего это:
- Встроенные среды выполнения: многие коммерческие приложения поставляются с собственной частной средой выполнения Java внутри каталога установки. Она может не отображаться ни в реестре, ни в каком-либо списке пакетов.
- Несколько версий на одной машине: при установке новой среды выполнения старые удаляют редко, поэтому на одном сервере их может оказаться три или четыре.
- Забытые серверы: тестовые машины, старые серверы пакетной обработки и виртуальные машины, которые так и не были выведены из эксплуатации и часто работают на устаревших версиях без обновлений.
- Неизвестные владельцы: машины, за которые никто не признаёт ответственности. По ним нужно принять решение до начала миграции, даже если это решение их отключить.
Совет: вопросы со встроенной средой выполнения обычно решаются через поставщика приложения, её нельзя просто заменить напрямую, поэтому учитывайте её отдельно от сред выполнения, которыми вы управляете сами.
От инвентаризации к плану миграции
Собрав данные, сведите их в одном месте и проверьте вместе с владельцами систем. Затем распределите установки по категориям:
| Группа | Что входит | Что делать |
|---|---|---|
| Удалить | Среды выполнения, которые больше не используются | Удалить сейчас, чтобы снизить риски и лицензионные обязательства |
| Заменить | Среды выполнения, которыми вы управляете сами | После тестирования перейти на поддерживаемую сборку OpenJDK |
| Согласовать | Среды выполнения, встроенные в сторонние приложения | Сначала получить заявление о поддержке от поставщика приложения |
| Выяснить | Всё, у чего нет владельца или понятного назначения | Найти владельца или принять решение об отключении |
На основе этих групп можно составить реалистичный график: начните с систем с низким уровнем риска, чтобы отработать процесс, а затем переходите к критичным для бизнеса системам с проверенным планом отката.
Совет: повторите сканирование непосредственно перед окончательным переключением. За время длительного проекта среда меняется, и появляются новые установки.
Чем может помочь LOGIQ
LOGIQ проводит проекты по инвентаризации и миграции сред Java и Linux, используя скрипты и процедуры, отработанные в реальных клиентских проектах на серверах Windows, серверах Linux и рабочих станциях. Если вам нужна помощь в проведении инвентаризации или в составлении на её основе плана миграции, свяжитесь с LOGIQ.
Global
Japan
Korea
China
Taiwan
Vietnam
Thailand
Indonesia
Portugal
Spain
France
Germany
Egypt