Créer une image native à partir de l'application Spring Boot avec le générateur GraalVM

Aperçu

Cette section explique comment créer une image native à partir d'une application Spring Boot à l'aide du générateur d'images natives de GraalVM, et comment exécuter cette image native dans un conteneur Docker.

Objectif

Dans la conception de l'architecture logicielle et de l'architecture des microservices, nous devons prendre en compte l'évolutivité et les performances de notre application. Notre application doit commencer à évoluer rapidement et à utiliser la ressource efficacement chaque fois que le nombre de demandes augmente dans notre application.

J'envisage d'utiliser la compilation Spring Boot Ahead of Time (AOT) avec GraalVM pour exécuter l'exécutable dans des conteneurs, ainsi que Java Virtual Threads (disponibles dans JDK 21 et versions ultérieures).

• La compilation AOT est avantageuse pour les scénarios dans lesquels des temps de démarrage rapides et des performances prévisibles sont importants, avec le compromis d'une moindre adaptabilité d'exécution.
• Les conteneurs sont légers et utilisent moins de ressources que les machines virtuelles (VM), car ils partagent le noyau du système d'exploitation hôte. Les conteneurs peuvent démarrer et s'arrêter beaucoup plus rapidement que les VM, ce qui permet une mise à l'échelle et un déploiement plus rapides.
• Les threads virtuels peuvent améliorer les performances des applications qui gèrent un grand nombre de tâches simultanées. Ceci est particulièrement avantageux pour les applications telles que les serveurs Web, les bases de données et autres systèmes liés aux E/S. Les threads virtuels utilisent moins de ressources que les threads traditionnels. Ils sont gérés par le runtime de manière à minimiser l'utilisation de la mémoire et la surcharge du processeur.

Dans cette décision de conception architecturale, nous obtenons des avantages, mais devons également prendre en compte les défis de mise en œuvre et les considérations de conception suivants :

• Threads virtuels : nous devrions éviter d'utiliser des threads virtuels si notre logique métier est gourmande en CPU, comme dans les scénarios nécessitant un calcul de mémoire étendu.
• Compilation Ahead of Time (AOT) : le compilateur AOT peut ne pas gérer correctement la réflexion, le codage proxy ou la sérialisation. De plus, GraalVM est une technologie relativement nouvelle, qui pose des défis dans la création d'images natives à partir d'applications Spring Boot et entraîne une augmentation des temps de construction.
• Conteneurs : les conteneurs offrent de nombreux avantages, mais certains des défis sont liés à la sécurité, au réseau, aux performances, au CI/CD, etc. Certains exemples sont
  • Les conteneurs peuvent inclure des vulnérabilités provenant d'images de base ou de dépendances.
  • L'intégration de conteneurs dans des pipelines CI/CD existants peut s'avérer difficile, nécessitant des modifications dans les processus de création, de test et de déploiement.
  • La gestion des plateformes d'orchestration de conteneurs comme Kubernetes peut être complexe et nécessite des connaissances spécialisées.
  • Augmenter et réduire efficacement les conteneurs pour gérer des charges variables sans surprovisionner ou sous-provisionner les ressources.

Application Spring Boot
Pour tester ce cas d'utilisation, je construis une application Spring Boot qui expose un point de terminaison REST à "/hello". J'utilise la configuration, les bibliothèques et les outils suivants :

• Spring Boot 3.2.8 avec REST
• Compilation AOT Spring Boot
• Image native GraalVM de Spring Boot
• Outil de construction Maven 3.9.8
• Java 22

Nous devons ajouter la configuration suivante dans le fichier XML POM.

Configuration de la propriété Spring Boot

<properties>
    <java.version>22</java.version>
    <spring-native.version>0.12.1</spring-native.version>
</properties>

Configuration du plugin Spring Boot AOT

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
       <execution>
          <id>process-aot</id>
          <goals>
             <goal>process-aot</goal>
          </goals>
       </execution>
    </executions>
</plugin>

Configuration du plugin GraalVM

<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
    <configuration>
       <imageName>app-native-binary</imageName>
       <metadataRepository>
          <enabled>true</enabled>
       </metadataRepository>
       <buildArgs>
          <buildArg>--static --libc=musl</buildArg>
          <buildArg>-H:+ReportExceptionStackTraces</buildArg>
       </buildArgs>
       <mainClass>com.developerhelperhub.tutorial.springboot.tutorial.TutorialStartupPerformanceApplication</mainClass>
    </configuration>
    <executions>
       <execution>
          <id>add-reachability-metadata</id>
          <goals>
             <goal>add-reachability-metadata</goal>
          </goals>
       </execution>
    </executions>
</plugin>

• "mainClass": Configuration de la classe de messagerie de l'application Spring Boot
• "imageName": Configuration du nom natif de l'image
• "buildArgs": Configuration de —libc=”msul”, Nous configurons GraalVM pour construire l'image native avec la bibliothèque compatible "libc musl" car nous exécuterons cette image sur une machine Alpine Linux. Musl est conçu pour être plus petit et utiliser moins de mémoire que d'autres bibliothèques standard, ce qui le rend bien adapté aux environnements aux ressources limitées.

Construire le binaire et créer l'image Docker

Nous devons créer l'image native pour l'hôte du système d'exploitation et l'architecture du processeur spécifiques où l'image native s'exécutera dans le conteneur.

Nous utilisons Alpine Linux pour sa petite taille, sa simplicité et sa sécurité pour exécuter notre application dans le conteneur. Pour y parvenir, nous devons utiliser la configuration GraalVM appropriée pour créer notre application. La configuration système requise pour Alpine est le système d'exploitation et l'architecture du processeur.

• "Architecture": "amd64"
• "Os": "linux"
• Bibliothèque commune C : « libc musl »

La commande suivante que nous pouvons utiliser pour inspecter l'image « amd64/alpine »

docker pull amd64/alpine # pull the image

docker image inspect amd64/alpine # inspect the image

We can use docker container to build the native image instead of setup the GraalVM and Java related configuration in our locally. I am using “ghcr.io/graalvm/native-image-community:22-muslib” docker image to build the native.

Following command we can use to inspect the “ghcr.io/graalvm/native-image-community:22-muslib” image

docker pull ghcr.io/graalvm/native-image-community:22-muslib # pull the image

docker image inspect ghcr.io/graalvm/native-image-community:22-muslib # inspect the image

I am creating a build image to test and debug the container, ensuring that all configurations and services are installed correctly. This approach will help us quickly identify and resolve any issues.

Following steps are added in the docker file, the file name “DockerfileBuild”

FROM ghcr.io/graalvm/native-image-community:22-muslib as build

# Install necessary tools
RUN microdnf install wget 
RUN microdnf install xz

# Install maven for build the spring boot application
RUN wget https://dlcdn.apache.org/maven/maven-3/3.9.8/binaries/apache-maven-3.9.8-bin.tar.gz
RUN tar xvf apache-maven-3.9.8-bin.tar.gz

# Set up the environment variables needed to run the Maven command.
ENV M2_HOME=/app/apache-maven-3.9.8
ENV M2=$M2_HOME/bin
ENV PATH=$M2:$PATH

# Install UPX (Ultimate Packer for eXecutables) to compress the executable binary and reduce its size.
RUN wget https://github.com/upx/upx/releases/download/v4.2.4/upx-4.2.4-amd64_linux.tar.xz
RUN tar xvf upx-4.2.4-amd64_linux.tar.xz

# Set up the environment variables required to run the UPX command.
ENV UPX_HOME=/app/upx-4.2.4-amd64_linux
ENV PATH=$UPX_HOME:$PATH

#Copy the spring boot source code into container
RUN mkdir -p /app/spring-boot-rest-api-app
COPY spring-boot-rest-api-app /app/spring-boot-rest-api-app

#Compile the native image
RUN cd /app/spring-boot-rest-api-app && mvn -Pnative native:compile

#Compressed binary file
RUN upx -7 -k /app/spring-boot-rest-api-app/target/app-native-binary
WORKDIR /app
ENTRYPOINT ["/bin/bash"]

I am using the UPX compression tool in the build process to reduce the image size, UPX will typically reduce the file size of programs and DLLs by around 50%-70%, thus reducing disk space, network load times, download times and other distribution and storage costs.

Use the following command to build the Docker image.

docker build --no-cache -f DockerfileBuild -t alpine-graalvm-build .

After the build is complete, the image size will be 1.85 GB.

REPOSITORY                               TAG         IMAGE ID       CREATED          SIZE
alpine-graalvm-build                     latest      81d23bc1bc99   36 seconds ago   1.85GB

We can verify the configuration and installation within the container before creating a smaller container inside the Alpine Linux box. The following command will allow us to enter the container:

docker run --rm -it --entrypoint /bin/bash alpine-graalvm-build

java --version #verify the java version
mvn --version #verify the maven version
upx --version #verify the upx version

ls /app/spring-boot-rest-api-app/target/app-native-binary #verify the binary available

/app/spring-boot-rest-api-app/target/app-native-binary #run the executable

We know that this native image includes all the dependencies necessary to run the binary standalone, without requiring any build-related tools such as GraalVM, Maven, UPX, or source code. We can use a Docker multi-stage build approach to copy the build file into our application image. By using multiple stages, you can separate the build environment from the runtime environment. This means only the necessary artifacts are included in the final image, significantly reducing its size.

Following steps are added in the docker file, the file name “DockerfileBuildAndCreateAlpineContainer”

FROM ghcr.io/graalvm/native-image-community:22-muslib as build

# Install necessary tools
RUN microdnf install wget 
RUN microdnf install xz

# Install maven for build the spring boot application
RUN wget https://dlcdn.apache.org/maven/maven-3/3.9.8/binaries/apache-maven-3.9.8-bin.tar.gz
RUN tar xvf apache-maven-3.9.8-bin.tar.gz

# Set up the environment variables needed to run the Maven command.
ENV M2_HOME=/app/apache-maven-3.9.8
ENV M2=$M2_HOME/bin
ENV PATH=$M2:$PATH

# Install UPX (Ultimate Packer for eXecutables) to compress the executable binary and reduce its size.
RUN wget https://github.com/upx/upx/releases/download/v4.2.4/upx-4.2.4-amd64_linux.tar.xz
RUN tar xvf upx-4.2.4-amd64_linux.tar.xz

# Set up the environment variables required to run the UPX command.
ENV UPX_HOME=/app/upx-4.2.4-amd64_linux
ENV PATH=$UPX_HOME:$PATH

#Copy the spring boot source code into container
RUN mkdir -p /app/spring-boot-rest-api-app
COPY spring-boot-rest-api-app /app/spring-boot-rest-api-app

#Compile the native image
RUN cd /app/spring-boot-rest-api-app && mvn -Pnative native:compile

#Compressed binary file
RUN upx -7 -k /app/spring-boot-rest-api-app/target/app-native-binary
WORKDIR /app

#Second stage: Create the runtime image
FROM amd64/alpine

#Set the working directory
WORKDIR /app

#Copy the built application from the first stage
COPY --from=build /app/spring-boot-rest-api-app/target/app-native-binary .

#Expose port which our spring boot application is running
EXPOSE 8080 

#Command to run the application
ENTRYPOINT ["/app/app-native-binary"]

Use the following command to build the Docker image.

docker build -f DockerfileBuildAndCreateAlpineContainer -t alpine-graalvm .

After the build is complete, the image size of container will be 32.8MB.

REPOSITORY                               TAG         IMAGE ID       CREATED          SIZE
alpine-graalvm                           latest      79676c696920   11 seconds ago      32.8MB

We can verify the container.

docker run --rm -it --entrypoint sh alpine-graalvm

ls /app #verify the binary available

/app/app-native-binary #run the executable

The application startup time is just 0.074 seconds, whereas a typical Spring Boot application running on the JVM has a startup time of approximately 1.665 seconds.

Started TutorialStartupPerformanceApplication in 0.074 seconds (process running for 0.075)

Following command can be use to run the docker container for running the application

docker run -d --name test-app -p 8080:8080 alpine-graalvm #run the container

curl http://localhost:8080/hello # checking the endpoints

Spring boot and GraalVM references

• Spring Boot Introduction GraalVM Native Images
• GraalVM documentation build Spring Boot Native Executable
• GraalVM Maven Plugin Documentation
• Sample Spring Boot Application Docker Image Setup with GraalVM
• Sample Native Images with Spring Boot and GraalVM
• Spring Boot 3.2.8 GraalVM Native Images Documentation
• Spring Boot GraalVM UPX Tutorial Video
• Spring Boot Alpine Linux Docker Native Image Example ## Docker and GraalVM References
• GraalVM Containers Images
• Docker Environment Variables
• Maven Download
• UPX Documentation
• UPX Releases
• Docker Stop Container

Source Code

• Spring Boot Github Repo
• Kubernetes Related Repo

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!