Spring Boot a publié la version 2.3.0 qui ajoute la prise en charge de Docker avec buildpacks, les images en couches, la prise en charge de l'arrêt gracieux et les sondes de vivacité et de disponibilité. Un autre changement notable est la prise en charge de Java 14 tout en maintenant la prise en charge des versions LTS 8 et 11.
Les Buildpacks sont une alternative aux Dockerfiles. Buildpacks détecte automatiquement les requis nécessaires pour exécuter l'application dans un conteneur Docker. Par exemple, il détecte la version de Java utilisée dans l'application. En fonction de cette version, le buildpack sélectionne le JRE spécifié dans le buildpack et crée une image Docker. Avec Maven ou Gradle, la commande suivante crée une image Docker :
spring-boot:build-image
Notez qu'aucune configuration n'a été nécessaire pour créer une image Docker basée sur des buildpacks.
Il est possible de modifier certaines configurations du buildpack en utilisant la tâche bootBuildImage. Par exemple, la configuration du plug-in Spring Boot Maven suivante dans le fichier de construction montre comment modifier le nom de l'image Docker :
<configuration>
<image>
<name>infoq.com/${project.artifactId}:${project.version}</name>
</image>
</configuration>
La spécification du nom de l'image Docker peut également être effectuée à partir de la ligne de commande :
mvn/gradle bootBuildImage --imageName=infoq.com/my-app:v1
Les images Docker fonctionnent avec des couches. L'ajout de l'artefact d'application en tant que dernière couche permet de réduire la taille sur disque des images. Les développeurs stockent généralement l'artefact d'application sous forme de fichier JAR. L'inconvénient est que le fichier JAR contient des éléments qui changent souvent, comme le code. Mais le fichier JAR contient également des éléments qui changent moins fréquemment tels que les dépendances. Les modifications entre les versions dans les images Docker sont stockées sous forme de différences. Lorsque les fichiers JAR sont stockés pour chaque version de l'application, la différence est assez importante et consomme beaucoup d'espace disque. Les buildpacks réduisent l'espace requis en divisant l'application en plusieurs couches en fonction de ce qui change plus fréquemment.
La fonctionnalité de division de l'artefact en plusieurs couches peut également être utilisée dans un Dockerfile. Les buildpacks offrent une certaine forme de configuration, mais les Dockerfiles donnent un contrôle total sur l'image résultante. Les développeurs préféreront donc parfois un Dockerfile à un buildpack. Lorsque vous choisissez d'utiliser un Dockerfile, il est conseillé de diviser les couches de l'artefact. C'est un peu plus de travail qu'avec un buildpack, mais c'est une tâche à faire qu'une seule fois.
Configurez d'abord le plugin spring-boot-maven pour produire un JAR en couches :
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layers>
<enabled>true</enabled>
</layers>
</configuration>
</plugin>
</plugins>
</build>
Cette configuration de plug-in garantit que l'application est divisée en quatre parties : dépendances, spring-boot-loader, snapshot-dependencies et application.
L'extrait ci-dessous montre un Dockerfile multistage. Dans la première étape, l'application est exécutée avec l'argument spécifique jarmode. Il en résulte que les quatre parties sont chacune stockées dans son propre répertoire. Dans l'étape suivante, ces quatre répertoires sont copiés à l'intérieur de l'image Docker dans des couches séparées et le point d'entrée est spécifié.
FROM adoptopenjdk:14-jre-hotspot as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract
FROM adoptopenjdk:14-jre-hotspot
WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]
Les développeurs peuvent utiliser le Dockerfile pour créer une image Docker et ensuite exécuter un conteneur basé sur l'image :
docker build . --tag infoq
docker run -p8080:8080 infoq
Les sondes de vivacité et de disponibilité sont utilisées par des systèmes de conteneurs comme Kubernetes. Kubernetes démarre un nouveau pod lors de la mise à niveau d'une application vers une nouvelle version. Ce pod est démarré à côté de l'ancien pod qui contient l'ancienne version. Lorsque le nouveau pod est prêt, il accepte le trafic et l'ancien pod est supprimé. Cependant, lorsque le conteneur est prêt, l'application n'est souvent pas complètement démarrée. Dans le cas de Spring Boot, cela peut prendre quelques secondes. Par défaut, cela signifie que la nouvelle application, qui n'est pas complètement démarrée, reçoit déjà du trafic, tandis que l'ancienne application est arrêtée.
Cela peut être résolu en interrogeant une URL spécifique dans l'application qui est disponible après le démarrage de l'application. Chaque fois que l'URL est disponible, l'application est prête à recevoir du trafic et l'ancienne version peut être supprimée. Dans Kubernetes, cela peut être implémenté par un ReadinessProbe.
Spring Boot offre désormais la prise en charge par défaut de la sonde de disponibilité, par exemple via l'URL http://localhost:8080/actuator/health/readiness qui est exposée après l'avoir activée dans la configuration de l'application : management.health.probes.enabled = true.
Outre ReadinessProbe, il existe également le concept d'une sonde de vivacité dans Kubernetes. Il sert à vérifier si l'application fonctionne toujours correctement à un intervalle prédéfini. Si l'application ne répond pas, le module redémarre. Spring Boot propose également un endpoint : http://localhost:8080/actuator/health/liveness.
Ces différents endpoints fonctionnent par défaut, mais il est possible de les configurer : par exemple, pour attendre le démarrage d'une base de données.
Un arrêt progressif est utilisé pour continuer les requêtes en attente pendant une certaine période après l'arrêt de l'application.
L'extrait de code suivant montre comment activer l'arrêt progressif et configurer la valeur du délai d'expiration sur 30 secondes :
server.shutdown=graceful
spring.lifecycle.timeout-per-shutdown-phase=30s
Cela signifie que lors de l'arrêt de l'application, les nouvelles demandes ne sont pas autorisées. Cependant, les anciennes requêtes ont encore 30 secondes pour se terminer avant que l'application ne soit complètement arrêtée.