Одна из сложнейших задач этого года — адаптация под новые условия работы с зарубежными вендорами и с open-source сообществом в целом. Open-source не решает все проблемы; в некоторых случаях он их только создает. При этом в российской разработке есть особенности, связанные с импортозамещением. Все вместе это наложило отпечаток на большинство классических программных платформ и языков программирования.
В 2023 году ЕДИНЫЙ ЦУПИС перевел информационные сервисы на отечественную платформу Java с поддержкой ее поставщика. Сейчас в качестве среды разработки и исполнения Java в ЕДИНОМ ЦУПИС используется Axiom JDK Pro. Давайте посмотрим на проблемы этого года глазами разработчиков Java-платформы, а поможет нам в этом Олег Чирухин, деврел в команде этого дистрибутива.
Проблемы Open-source
Java — одна из лучших платформ для разработки на основе open-source. Зайдя в Maven Central, можно найти тысячи библиотек, которые устанавливаются парой строчек в pom.xml: их код моментально доступен на GitHub и других хостингах. Всевозможный серверный софт лежит на Docker Hub и запускается одной командой через docker run hello-world.
К сожалению, эта простота не достается бесплатно. Большинство свободных проектов не разрабатываются с учетом интересов безопасности. Даже если у них есть свой совет безопасности, нет никаких гарантий, что он будет решать именно ваши проблемы. Это не имеет никакого значения при разработке собственного пет-проекта, но очень болезненно при разработке масштабных проектов, от которых зависят жизни миллионов людей.
Что касается Java, можно рассказать много разных страшных историй. Многие знают про уязвимость Log4Shell, которая при определенной эксплуатации раскрытия строк типа ${prefix:name} может привести к исполнению произвольного кода из произвольного места в интернете. Но не все в курсе, что только в CVE Database зарегистрировано более двух с половиной тысяч уязвимостей, касающихся Java-технологий, и около полутора сотен из них связаны с OpenJDK. Еще меньше разработчиков знают, что количество задач в проекте OpenJDK продолжает расти, а соотношение созданных и решенных задач сильно склоняется к нерешенным.
В других технологиях проблем не меньше. Хакеры повадились удалять или портить файлы на компьютерах разработчиков, установивших «зараженные» пакеты, отображать пропаганду или спам в текстовых логах. Активисты удаляют поддержку российских аппаратных платформ, закрывают возможность коммитить в апстрим русскоязычным разработчикам и так далее. Строго говоря, нет никаких гарантий даже того, что произвольный бинарник из интернета соответствует своему исходнику.
Иногда проблемы возникают не из-за злого умысла, а потому, что так «исторически сложилось». Например, многие все еще используют в своих Dockerfile базовый образ типа FROM openjdk. Если же заглянуть на официальную страницу этого образа на Docker Hub, окажется, что первая строчка там: DEPRECATION NOTICE. Иначе говоря, обновляется этот образ раз в сто лет.
Предупреждая вопрос: «Значит ли это, что Java небезопасна и с нее надо бежать?» Нет, не значит. Практически любой успешный проект, у которого есть клиенты, выглядит так же, как картинка с расходящимися решенными и нерешенными задачами в OpenJDK. Просто всеми этими нюансами нужно кому-то заниматься и вовремя реагировать на возникающие проблемы.
Раньше такие проблемы решались зарубежными вендорами типа Oracle и IBM, но многие из них перестали работать с Россией. Само по себе это могло бы стать огромной проблемой, если бы у нас не было коммитеров в основные программные платформы: Java, Python, JavaScript и т.д. К счастью, такие коммитеры существуют. Есть даже целые компании и команды, целенаправленно занимающиеся разработкой, поддержкой и безопасностью программных платформ.
Одна из таких команд — разработчики российского дистрибутива Java под названием Axiom JDK Pro. У них есть своя кодовая база на основе OpenJDK, которую они разрабатывают и поддерживают для использования на территории России (отдельно от основного опенсорсного проекта OpenJDK). Команда Axiom JDK делает не только сам JDK, но и ряд других продуктов, вместе образующих экосистему для удобной и безопасной разработки. Эти же инженеры в прошлом портировали OpenJDK на процессоры архитектуры ARM, запустили OpenJDK на Alpine и сделали много другой полезной для сообщества работы.
Государственные системы и КИИ
Критическая информационная инфраструктура (КИИ) — это информационные системы, критически важные для государства и общества. Они работают на объектах здравоохранения, промышленности, связи, транспорта, энергетики, финансового сектора и городского хозяйства. Это те области, где более всего важны требования к безопасности ПО.
В России есть достаточно развитая система, которая позволяет говорить о применении ПО в таких областях. Например, ГОСТ Р 54593-2011 определяет термин «свободное программное обеспечение», а Статья 1286.1 ГК РФ регулирует применение открытых лицензий.
Программы регистрируются в нескольких реестрах. В информационных системах органов государственной власти и на объектах критической информационной инфраструктуры разрешено использовать только программы, входящие в Единый реестр российского ПО или Единый реестр евразийского ПО.
Требование использовать ПО из реестров — хорошая идея, позволяющая выполнять задачи, стоящие перед государством. И за этим хорошо следят. Например, если объект КИИ является финансовой организацией и не выполняет требования законодательства, то после проверки Банком России к нему могут применить меры вплоть до отзыва лицензии.
Но переходить на российское ПО нужно не только по формальным требованиям регуляторов. Представьте, что у вас на проде JVM падает с ошибкой и сообщением core dumped, а Oracle не хочет эту ошибку исправлять. Что вы будете делать дальше? Это не тот класс проблем, которые легко и просто решаются штатными Java-разработчиками. Там нужны специальные JVM-инженеры, и пока вы будете их искать, компания будет терпеть убытки. В случае медицины — это чьи-то жизни. Такие проблемы случаются чрезвычайно редко, но даже один раз может стоить для объекта КИИ очень дорого.
Компоненты экосистемы
Java-приложение можно запустить как самостоятельный JAR-файл на JVM в составе сервера приложений либо скомпилировать в исполняемый файл с помощью утилиты Native Image. Делать это можно как на голом железе, так и внутри контейнера или полной виртуальной машины.
Разработчикам экосистемы все эти технологии нужно разрабатывать и поддерживать: добавлять фичи, исправлять баги, следить за удобством использования, обеспечивать безопасность и так далее. Прикладным Java-разработчикам нужно их применять на практике и вовремя переключаться на правильные решения.
Axiom JDK
Самый главный для разработчиков элемент экосистемы — это JDK, Java Development Kit.
Поскольку все основные Java-технологии строго определены рабочими документами вроде JEP и JSR или готовыми спецификациями языка и виртуальной машины, процесс перехода на Axiom JDK Pro максимально простой. Вы устанавливаете в систему Axiom JDK вместо JDK от какого-то зарубежного вендора (например, Oracle JDK), и все просто работает. Вместе с переходом на Axiom JDK Pro у вас появляется возможность получать коммерческую поддержку и своевременные обновления безопасности и функциональности.
При этом Axiom JDK Pro работает как на зарубежных, так и на российских процессорах (Baikal, СКИФ, МЦСТ SPARC, разработки на RISC-V) и операционных системах (Роса, Альт Линукс, РЕД ОС, Астра Линукс). Поддерживаются все основные LTS-версии: сейчас это 8, 11, 17 и недавно вышедшая 21. Кроме того, вы можете договориться даже о поддержке легаси версий: 6 и 7 (но лучше все-таки запустить ваш софт на 8+).
Какую бы подсистему вы не разрабатывали, предмет первой необходимости — максимальная безопасность. Axiom JDK Pro разрабатывается в соответствии с концепцией жизненного цикла безопасной разработки SDL (Secure Development Lifecycle) и перед каждым релизом проходит через жесткий контроль качества, включающий структурный, статический, динамический анализы, регрессионное и PoC-тестирование и другие испытания.
Самый важный инструмент — статический анализатор Svace от ИСП РАН, благодаря которому в коде OpenJDK находят сотни тысяч срабатываний анализатора, из которых инженеры вручную отбирают самые важные и требующие более тщательного анализа. С применением такого подхода во времена JDK 8 были обнаружены и исправлены 26 дефектов, а в JDK 11 — 22. Дефекты продолжают обнаруживаться в свежих версиях Java.
Конечно же, используются регрессионные тесты, которые могут выполняться десятки часов, санитайзеры типа ASan (утечки памяти) или UBSan (неопределенное поведение). Для фаззинга нативного кода используется AFL++, а для Java-кода — JQF и Jazzer. В общем, используется полный набор инструментов и подходов, которые позволяют найти даже самые хитрые баги.
В результате этой работы появилась отдельный продукт под названием Axiom JDK Certified, который сертифицирован во ФСТЭК по 4 уровню доверия, что позволяет использовать его на объектах КИИ, где требуется повышенный уровень безопасности согласно требованиям ФСТЭК.
Команда Axiom JDK советует всем разработчикам критичной к безопасности инфраструктуры организовать у себя SDL-процесс (Secure Development Lifecycle) и внедрить аналогичные технологии. Это непросто, но к цели можно начинать двигаться маленькими шагами.
Сервер приложений: Libercat
Сервер приложений — это классика Java Enterprise Edition. Сервера приложений позволяли реализовывать идеальный DevOps еще в те времена, когда Kubernetes не родился. Общая конфигурация, общие библиотеки, общее развертывание, совместное управление стартом/остановкой — очень удобно. Точнее, было удобно до тех пор, пока вендоры основных серверов приложений не ушли из России.
В качестве ответа команда Axiom JDK выпустила сервер приложений Libercat в двух вариантах: Libercat и Libercat EE. Первый — это контейнер сервлетов (аналог Tomcat), второй — сервер приложений Java EE (аналог TomEE +). Libercat EE поддерживает больше 40 спецификаций Java EE и Jakarta EE.
Это российские сервера приложений, решающие проблему того, что продукты Oracle и IBM ушли с российского рынка. Если вы писали свое приложение в строгом соответствии с этими спецификациями, то переход на Libercat может быть простым и быстрым.
Если же вы глубоко залезли в приватные API или использовали проприетарные технологии без открытого исходного кода, это может привести к переписыванию значительных объемов кода. Сделать с этим ничего нельзя, болезненный отказ от vendor lock-in — это особенность работы с проприетарщиной, но инженеры Axiom JDK окажут вам поддержку при миграции.
Контейнеры
Здесь хочется поговорить сразу о трех элементах экосистемы:
Axiom Runtime Container,
Axiom Linux,
Axiom Native Image Kit.
Переход на облака, Docker, Kubernetes и сопутствующие технологии радикально упрощают поддержку инфраструктуры, но есть нюансы. Облака не бесплатны. Докерные образы занимают внушительное количество дискового пространства, оперативной памяти, нагружают сеть. Они мешают как на проде, так и на компьютерах разработчиков. Долгий пулл образа и забитый кэшем докера жесткий диск никому не нравятся.
Уменьшить размер образов можно двумя путями: либо урезать размер базового образа, либо размер приложения внутри него. Что мы можем сделать, пойдя по первому пути? Взять образ поменьше, например, Debian Slim? Но вот проблема: хотя Debian Slim значительно меньше полной версии Debian, он все еще достаточно массивный. Мы можем зайти дальше и попробовать distroless image. К сожалению, это другая крайность: их очень сложно отлаживать, потому что там нет никаких инструментов отладки, а их настройка может превратиться в ад. Например, для distroless от Google нужно править хитрые конфиги в bazel.
Специально для решения этой проблемы были разработаны базовые образы Axiom Runtime Container. Это одни из самых маленьких контейнеров с Java на рынке (около 40 мегабайт, размер зависит от поставки и версий Java). Кроме того, они могут обеспечивать повышенную производительность по сравнению с классическими контейнерными образами с Java. По результатам тестам приложение, запущенное в Axiom Runtime Container, может тратить вплоть до 30% меньше оперативной памяти, чем в контейнере с ванильным Debian Slim и «официальным» образом с Docker Hub (напоминаем, не нужно его использовать, он устарел и не поддерживается).
Миграция на эти контейнеры обычно очень простая: нужно всего лишь заменить название базового образа в поле FROM. Проблемы могут возникнуть, только если вы использовали какие-то дополнительные пакеты и настройки, и тут вам на помощь придут собственные репозитории пакетов Axiom Linux, по структуре и названиям пакетов очень близкие к Alpine.
Все это стало возможным именно потому, что инженеры Axiom JDK когда-то занимались портированием OpenJDK на Alpine. К сожалению, сам Alpine оказался не лучшей системой, потому что он поддерживается открытым сообществом, где не особо беспокоятся о безопасности и оптимизации исполнения Java-кода. Так появился Axiom Linux — специальный серверный дистрибутив Linux, изначально основанный на кодовой базе Alpine. Это первый в мире дистрибутив, который специально оптимизирован для запуска Java. Секрет того, как он экономит память и процессор, очень прост в объяснении, но очень сложен в реализации. Инженеры Axiom JDK посмотрели, какие функции musl libc используются в Java, и оптимизировали для них все важные части musl. В результате получился модифицированный musl под названием musl-perf, который идет в поставке Axiom Runtime Container.
Второй способ уменьшить размер приложения и ускорить его запуск — использование технологии Native Image. Это компилятор, который превращает код на Java в исполняемые файлы (на Windows это будут .exe-файлы). Таким файлам не нужен прогрев JVM, они мгновенно запускаются вместе с контейнером. В экосистеме российской Java реализацией такого компилятора является Axiom Native Image Kit, построенный на базе GraalVM CE с некоторыми доработками. Важно, что ускорение от Native Image сопряжено с необходимостью изменения кода приложения. Самое главное, в таких приложениях нельзя использовать Java Reflection и похожие на него API. Переписать легаси без Reflection необычайно сложно, поэтому Native Image обычно используется для нового кода, в особенности с использованием современных фреймворков вроде Spring Native, Micronaut, Quarkus.
Выводы
Несмотря на сложные вызовы этого года, российские разработчики имеют все возможности хорошо подготовиться к ближайшему будущему. Экосистема платформы Java хорошо спроектирована, что позволяет сравнительно безболезненно переводить инфраструктуру на решения отечественных вендоров, включая Axiom JDK.
В экосистеме российской Java есть самые важные для миграции технологии: JDK, сервер приложений, базовые образы для Docker, компилятор Native Image и даже свой собственный контейнерный Linux, оптимизированный для выполнения Java-кода.
В дальнейшем мы планируем поделиться подробностями использования разных аспектов экосистемы российской Java и советами по их использованию, а также по миграции с зарубежных продуктов.
Конечно, можно пойти по обоим путям одновременно и положить приложение, собранное Native Image, прямо в контейнер с Axiom Linux.
