Сборка Quarkus приложения в исполняемый файл.md
All checks were successful
continuous-integration/drone/push Build is passing
All checks were successful
continuous-integration/drone/push Build is passing
This commit is contained in:
parent
3987a892c7
commit
d8605648be
@ -8,7 +8,7 @@ zero-link:
|
||||
parents:
|
||||
linked:
|
||||
---
|
||||
Когда-то давным давно скачал [JDK](JDK.md), работает и ладно. Посмотрел доклад про [нативные сборки](../../../../knowledge/dev/java/Нативные%20сборки%20в%20Java.md), и там упоминалось про [JDK](JDK.md) для Apple Silicon. Решил проверить, а такой ли у меня. Оказалось не такой.
|
||||
Когда-то давным давно скачал [JDK](JDK.md), работает и ладно. Посмотрел доклад про [нативные сборки](Нативные%20сборки%20в%20Java.md), и там упоминалось про [JDK](JDK.md) для Apple Silicon. Решил проверить, а такой ли у меня. Оказалось не такой.
|
||||
|
||||
В итоге вот сколько собирался большой [монолит](../../../../_inbox/Монолитная%20архитектура.md) (с генерацией javadoc), состоящий из 22 модуля на обычной [JDK](JDK.md). Все зависимости были закачены заранее и сборка была запущена в [многопоточном режиме](Параллельная%20сборка%20модулей%20в%20Maven.md).
|
||||
|
||||
|
||||
@ -0,0 +1,60 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
- maturity/🌱
|
||||
date:
|
||||
- - 2024-04-07
|
||||
zero-link:
|
||||
- "[[../../../meta/zero/00 Quarkus|00 Quarkus]]"
|
||||
parents:
|
||||
- "[[../Нативные сборки в Java|Нативные сборки в Java]]"
|
||||
linked:
|
||||
---
|
||||
Провозился два дня, но в итоге смог собрать один из микро-сервисов в нативном режиме. Ничего сложного, но было много нюансов в настройке CICD.
|
||||
|
||||
Самое полезное, это вот [эта документация Quarkus](https://quarkus.io/guides/building-native-image). А конкретно флаги:
|
||||
- `-Dquarkus.native.container-build=true`
|
||||
- `-Dquarkus.native.remote-container-build=true`
|
||||
|
||||
Эти флаги необходимо добавить в команду сборки
|
||||
|
||||
```shell
|
||||
gradle build -Dquarkus.package.type=native -Dquarkus.native.remote-container-build=true
|
||||
```
|
||||
|
||||
```shell
|
||||
./mvnw package -Dnative -Dquarkus.native.remote-container-build=true
|
||||
```
|
||||
|
||||
Во время сборки будет скачан докер образ с GraalVM и сборка будет проходить уже в этом образе. То есть можно использовать любой раннер CI без предварительной настройки базового образа.
|
||||
|
||||
А вот так выглядит [Dockerfile](../../../../../_inbox/Dockerfile.md) сервиса:
|
||||
|
||||
```Dockerfile
|
||||
FROM registry.access.redhat.com/ubi8/ubi-minimal:8.6
|
||||
WORKDIR /work/
|
||||
RUN chown 1001 /work \
|
||||
&& chmod "g+rwX" /work \
|
||||
&& chown 1001:root /work
|
||||
COPY ./build/*-runner /work/application
|
||||
|
||||
EXPOSE 8080
|
||||
USER 1001
|
||||
|
||||
CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]
|
||||
```
|
||||
|
||||
Сервис стал собираться в 2,5 раза больше, около 5 минут, вместо 2. Но теперь он стартует моментально, наверное за доли секунды. При этом на под выделяется всего 256 mb ОЗУ на старте и 512 mb в момент работы.
|
||||
## Более сложный путь
|
||||
Также слепил образ для GitLab-раннера, который совмещает GraalVM и Docker, осталось добавить в него Gradle, но пока использую `./gradlew`. Оставлю это тут на всякий случай.
|
||||
|
||||
```Dockerfile
|
||||
FROM ghcr.io/graalvm/graalvm-ce:ol9-java17-22.3.0
|
||||
WORKDIR /opt/graalvm
|
||||
RUN gu install native-image
|
||||
RUN microdnf -y install dnf-plugins-core
|
||||
RUN microdnf -y install yum
|
||||
RUN yum install -y yum-utils
|
||||
RUN yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
|
||||
RUN yum install -y docker-ce docker-ce-cli containerd.io
|
||||
```
|
||||
27
dev/java/Нативные сборки в Java.md
Normal file
27
dev/java/Нативные сборки в Java.md
Normal file
@ -0,0 +1,27 @@
|
||||
---
|
||||
aliases:
|
||||
- нативные сборки
|
||||
tags:
|
||||
- maturity/🌱
|
||||
date: 2023-11-15
|
||||
zero-link:
|
||||
- "[[../../meta/zero/00 Java разработка|00 Java разработка]]"
|
||||
parents:
|
||||
linked:
|
||||
---
|
||||
Нативные сборки в контексте Java относятся к процессу компиляции Java-приложений в нативный машинный код, специфичный для конкретной операционной системы и архитектуры процессора. Это отличается от традиционного подхода Java, где приложения компилируются в байт-код и выполняются на Java Virtual Machine ([JVM](JVM.md)). Основным инструментом для создания нативных сборок в Java является GraalVM Native Image.
|
||||
|
||||
**Плюсы:**
|
||||
1. **Быстрый Старт и Низкое Расходование Ресурсов**: Нативные сборки могут значительно ускорить время запуска приложения и уменьшить потребление ресурсов (например, памяти), поскольку они не требуют запуска JVM и загрузки классов ([Class Loader Subsystem](Class%20Loader%20Subsystem.md)) во время выполнения.
|
||||
2. **Уменьшение Зависимости от JVM**: Нативные приложения уменьшают зависимость от конкретной версии JVM, что может быть полезно в контекстах с ограниченными ресурсами или в случаях, когда требуется минимизировать размер сборки.
|
||||
3. **Лучшая Интеграция с Системой**: Нативные приложения могут лучше интегрироваться с операционной системой и использовать системные библиотеки.
|
||||
4. **Безопасность и Изоляция**: Нативные сборки могут предложить улучшенную безопасность и изоляцию, так как они меньше зависят от внешних факторов, таких как настройки JVM.
|
||||
|
||||
**Минусы:**
|
||||
1. **Ухудшение Производительности**: Несмотря на ускорение запуска, нативные сборки могут иметь более низкую производительность выполнения по сравнению с JVM, особенно для долго работающих приложений, где JVM оптимизирует выполнение кода во время работы ([[JIT Compilation]]).
|
||||
2. **Сложность Сборки**: Процесс создания нативной сборки может быть сложнее и требует дополнительных настроек по сравнению с традиционной Java-сборкой.
|
||||
3. **Ограниченная Совместимость**: Не все библиотеки и фреймворки Java совместимы с нативной компиляцией, и некоторые могут требовать специальной адаптации или полностью не поддерживаться. Чаще всего проблема в генерации классов во время выполнения программы. Например, [такого очень много в SpringBoot.](Создание%20прокси-объектов%20в%20SpringBoot.md)
|
||||
4. **Отсутствие Кросс-Платформенности**: Одним из ключевых преимуществ Java является ее кросс-платформенность, которая теряется при переходе к нативным сборкам, так как они специфичны для каждой платформы.
|
||||
## Дополнительные заметки по теме
|
||||
- [Сборка Quarkus приложения в исполняемый файл](quarkus/Сборка%20Quarkus%20приложения%20в%20исполняемый%20файл.md)
|
||||
- [Исследование сборки исполняемых файлов](Исследование%20сборки%20исполняемых%20файлов.md)
|
||||
@ -31,4 +31,6 @@ title: Java разработка
|
||||
- [Java 12](Java%2012.md)
|
||||
- [[Java 15]]
|
||||
- [[Java 17 LTS]]
|
||||
- [[Java 21 LTS]]
|
||||
- [[Java 21 LTS]]
|
||||
## Дополнительно
|
||||
- [Нативные сборки в Java](../../dev/java/Нативные%20сборки%20в%20Java.md)
|
||||
@ -12,3 +12,4 @@ zero-link:
|
||||
parents:
|
||||
linked:
|
||||
---
|
||||
- [Сборка Quarkus приложения в исполняемый файл](../../dev/java/quarkus/Сборка%20Quarkus%20приложения%20в%20исполняемый%20файл.md)
|
||||
Loading…
Reference in New Issue
Block a user