Erstellen Sie ein natives Image aus der Spring Boot-Anwendung mit dem GraalVM-Builder

Überblick

In diesem Abschnitt wird erklärt, wie Sie mit dem nativen Image Builder von GraalVM ein natives Image aus einer Spring Boot-Anwendung erstellen und wie Sie dieses native Image in einem Docker-Container ausführen.

Objektiv

Beim Softwarearchitektur- und Microservice-Architekturdesign müssen wir die Skalierbarkeit und Leistung unserer Anwendung berücksichtigen. Unsere Anwendung sollte schnell skaliert werden und die Ressource effizient nutzen, wenn die Anzahl der Anfragen in unserer Anwendung zunimmt.

Ich erwäge die Verwendung der Spring Boot Ahead of Time (AOT)-Kompilierung mit GraalVM, um die ausführbare Datei in Containern zusammen mit Java Virtual Threads (verfügbar in JDK 21 und höher) auszuführen.

• AOT-Kompilierung ist für Szenarien von Vorteil, in denen schnelle Startzeiten und vorhersehbare Leistung wichtig sind, mit dem Nachteil einer geringeren Anpassungsfähigkeit zur Laufzeit.
• Container sind leichtgewichtig und verbrauchen im Vergleich zu virtuellen Maschinen (VMs) weniger Ressourcen, da sie den Kernel des Host-Betriebssystems gemeinsam nutzen. Container können viel schneller gestartet und gestoppt werden als VMs, was eine schnellere Skalierung und Bereitstellung ermöglicht.
• Virtuelle Threads können die Leistung von Anwendungen verbessern, die eine große Anzahl gleichzeitiger Aufgaben verarbeiten. Dies ist besonders vorteilhaft für Anwendungen wie Webserver, Datenbanken und andere E/A-gebundene Systeme. Virtuelle Threads verbrauchen weniger Ressourcen als herkömmliche Threads. Sie werden von der Laufzeit so verwaltet, dass die Speichernutzung und der CPU-Overhead minimiert werden.

Aus dieser architektonischen Designentscheidung ziehen wir Vorteile, müssen aber auch die folgenden Implementierungsherausforderungen und Designüberlegungen berücksichtigen:

• Virtuelle Threads: Wir sollten die Verwendung virtueller Threads vermeiden, wenn unsere Geschäftslogik CPU-intensiv ist, beispielsweise bei Szenarien, die eine umfangreiche Speicherberechnung erfordern.
• Ahead of Time (AOT)-Kompilierung: Der AOT-Compiler verarbeitet Reflektion, Proxy-Codierung oder Serialisierung möglicherweise nicht richtig. Darüber hinaus handelt es sich bei GraalVM um eine relativ neue Technologie, die bei der Erstellung nativer Images aus Spring Boot-Anwendungen Herausforderungen mit sich bringt und zu längeren Erstellungszeiten führt.
• Container: Container bieten zahlreiche Vorteile, einige der Herausforderungen beziehen sich jedoch auf Bereichssicherheit, Netzwerk, Leistung, CI/CD usw. Einige Beispiele hierfür sind
  • Container können Schwachstellen von Basis-Images oder Abhängigkeiten enthalten.
  • Die Integration von Containern in bestehende CI/CD-Pipelines kann eine Herausforderung sein und Änderungen an den Erstellungs-, Test- und Bereitstellungsprozessen erfordern.
  • Die Verwaltung von Container-Orchestrierungsplattformen wie Kubernetes kann komplex sein und erfordert Spezialwissen.
  • Effiziente Skalierung von Containern nach oben und unten, um unterschiedliche Lasten ohne Über- oder Unterbereitstellung von Ressourcen zu bewältigen.

Spring Boot-Anwendung
Um diesen Anwendungsfall zu testen, erstelle ich eine Spring Boot-Anwendung, die einen REST-Endpunkt unter „/hello“ verfügbar macht. Ich verwende die folgende Konfiguration, Bibliotheken und Tools:

• Spring Boot 3.2.8 mit REST
• Spring Boot AOT Compile
• Spring Boot GraalVM Native Image
• Maven 3.9.8 Build Tool
• Java 22

Wir müssen die folgende Konfiguration in der POM-XML-Datei hinzufügen.

Spring Boot-Eigenschaftskonfiguration

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

Spring Boot AOT-Plugin-Konfiguration

<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>

GraalVM-Plugin-Konfiguration

<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": Konfigurieren der Mail-Klasse der Spring Boot-Anwendung
• "imageName": Konfigurieren des nativen Bildnamens
• „buildArgs“: Konfigurieren der —libc=“msul“. Wir konfigurieren GraalVM so, dass das native Image mit der „libc musl“-kompatiblen Bibliothek erstellt wird, da wir dieses Image auf einer Alpine-Linux-Box ausführen werden. Musl ist im Vergleich zu anderen Standardbibliotheken kleiner und benötigt weniger Speicher, wodurch es sich gut für Umgebungen mit eingeschränkten Ressourcen eignet.

Erstellen Sie Binary und erstellen Sie das Docker-Image

Wir müssen das native Image für den spezifischen Betriebssystemhost und die CPU-Architektur erstellen, auf dem das native Image im Container ausgeführt wird.

Wir verwenden Alpine Linux wegen seiner geringen Größe, Einfachheit und Sicherheit, um unsere Anwendung im Container auszuführen. Um dies zu erreichen, müssen wir die entsprechende GraalVM-Konfiguration zum Erstellen unserer Anwendung verwenden. Die Systemvoraussetzungen für Alpine sind das Betriebssystem und die CPU-Architektur.

• „Architektur“: „amd64“
• "Os": "linux"
• Gemeinsame C-Bibliothek: „libc musl“

Mit dem folgenden Befehl können wir das Bild „amd64/alpine“ überprüfen

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

Das obige ist der detaillierte Inhalt vonErstellen Sie ein natives Image aus der Spring Boot-Anwendung mit dem GraalVM-Builder. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!