Les images natives de GraalVM

Introduction

GraalVM se distingue comme une innovation technologique significative au sein de l’écosystème du développement logiciel, se positionnant aux côtés d’autres avancées majeures telles que Spring et la programmation réactive, mais aussi aux côtés de technologies disruptives comme les conteneurs Docker, qui ont révolutionné l’isolation et le déploiement des applications, Kubernetes pour l’orchestration de conteneurs à grande échelle, et les microservices qui ont transformé l’architecture des applications en permettant des développements plus modulaires et agiles. Le développement dirigé par les événements (Event-Driven Development) et l’informatique sans serveur (serverless computing) sont également des innovations qui ont remodelé les paradigmes de programmation et d’infrastructure, en offrant des moyens plus efficaces de construire et de déployer des applications. Ensemble, ces technologies ont façonné l’avenir du développement logiciel, en ouvrant la voie à des architectures plus flexibles, performantes et évolutives.

GraalVM est une technologie polyglotte de machine virtuelle (VM) avancée développée par Oracle Labs. Sa particularité réside dans sa capacité à exécuter...

Images natives de GraalVM

Les images natives de GraalVM révolutionnent le déploiement et l’exécution des applications Java. Ce sont des exécutables autonomes créés par traitement anticipé des applications Java compilées. Elles se distinguent par une empreinte mémoire réduite et un démarrage plus rapide par rapport aux applications sur JVM (Java Virtual Machine).

Ces images natives sont idéales pour les applications déployées via des images de conteneur et s’intègrent parfaitement aux plateformes de type fonction en tant que service (FaaS). À la différence des applications Java traditionnelles, celles basées sur GraalVM Native Image nécessitent un traitement préalable pour générer un exécutable. Ce processus inclut une analyse statique du code de l’application à partir de son point d’entrée principal.

Une image native GraalVM est un exécutable spécifique à une plateforme, qui ne requiert pas l’installation d’une JVM pour son exécution.

Les images natives de GraalVM, étant produites en amont, présentent des caractéristiques distinctives par rapport aux applications JVM, notamment :

Ahead Of Time (AOT)

Les applications Spring Boot typiques présentent une dynamique importante, et leur configuration est habituellement réalisée lors de l’exécution. Cette dynamique repose en grande partie sur la capacité à réagir en temps réel aux conditions d’exécution pour assurer une configuration appropriée, ce qui est au cœur de l’autoconfiguration de Spring Boot.

Cependant, informer GraalVM de ces aspects dynamiques pourrait compromettre les avantages liés à l’analyse statique. Par conséquent, lors de la création d’images natives avec Spring Boot, on part du principe que le contexte d’exécution est un « monde fermé », où les aspects dynamiques de l’application sont limités. Dans un tel environnement, les contraintes imposées par GraalVM sont accompagnées de restrictions supplémentaires :

Avec ces restrictions en place, Spring peut procéder à un traitement préalable (AOT) durant la phase de construction et générer des ressources supplémentaires utilisables par GraalVM.

La compilation AOT de GraalVM permet de compiler le code source en exécutables natifs avant l’exécution, améliorant ainsi les performances au démarrage et réduisant la consommation de mémoire des applications.

Une application traitée par Spring AOT va typiquement engendrer :

Application optimisée pour le mode natif

GraalVM présente certaines limitations et considérations spécifiques lors de la conception d’une application Spring Boot. Parmi les principales contraintes figurent les problématiques liées à la réflexion et à la génération dynamique de code, car GraalVM exige une connaissance préalable et statique du code pour la compilation en natif. Pour intégrer cette limitation dans la conception d’une application Spring Boot, voici un exemple :

Lorsque vous utilisez des fonctionnalités qui s’appuient sur la réflexion, comme l’injection de dépendances via @Autowired ou l’accès à des champs de manière dynamique, il est crucial de fournir à GraalVM des configurations explicites. Ces configurations permettent à GraalVM de comprendre et d’inclure les parties nécessaires du code lors de la compilation native. Une approche consiste à utiliser le fichier reflect-config.json pour lister explicitement les classes, méthodes, et champs auxquels GraalVM doit accéder par réflexion.

  { 
    "name" : "com.votreapplication.VotreClasse", 
    "allDeclaredConstructors" : true, 
    "allPublicConstructors" : true, 
    "allDeclaredMethods" : true, 
    "allDeclaredFields" : true 
  } 

Ce fichier doit être placé dans le répertoire META-INF/native-image du projet, permettant ainsi à GraalVM de préparer l’image native en tenant compte de ces éléments.

En adoptant cette stratégie, les développeurs peuvent surmonter une des limitations clés de GraalVM lors de l’utilisation de Spring Boot, assurant que l’application compilée nativement se comporte comme prévu, sans omettre des parties critiques du code nécessaires à son exécution. Cette méthode exige une compréhension précise des parties du code qui utilisent la réflexion, soulignant l’importance d’une planification et d’une documentation adéquates lors de la conception d’applications...

Exemple d’application

Voici un exemple d’application sur lequel on se basera pour créer une image native :

@RestController 
@SpringBootApplication 
public class MonApplication { 
 
  @RequestMapping("/") 
  String accueil() { 
    return "Bonjour à vous!"; 
  } 
 
  public static void main(String[] args) { 
    SpringApplication.run(MonApplication.class, args); 
  } 
 
} 

Cette application est basée sur Spring MVC et utilise un Tomcat intégré. Ces deux composants ont été testés et sont confirmés comme étant compatibles avec la création d’images natives via GraalVM.

Pour créer un exécutable natif (sans passer par Docker), les outils de build natifs de GraalVM sont une option efficace. Disponibles pour Maven et Gradle, ils offrent diverses fonctionnalités liées à GraalVM, dont la création d’images natives.

Pour générer une image native, il est nécessaire d’avoir GraalVM sur votre machine. 

Vous pouvez installer GraalVM (https://www.graalvm.org/latest/docs/getting-started/) et/ou Liberica Native Image Kit (https://bell-sw.com/liberica-native-image-kit/ version 22.3), ainsi que les outils de build...

Conteneurisation de l’exemple

L’utilisation de Docker facilite grandement les choses. Spring Boot facilite la création d’images natives en intégrant le support des buildpacks pour Maven et Gradle. Cela permet de générer rapidement une image optimisée dans Docker local via une simple commande. Ces images ne comprennent pas de JVM, car elles sont compilées statiquement, ce qui les rend plus légères.

Le builder utilisé est paketobuildpacks/builder-jammy-tiny:latest, caractérisé par sa légèreté et une surface d’attaque minimale. Le dépôt GitHub est ici : https://github.com/paketo-buildpacks/builder-jammy-tiny.

Alternativement, il est possible d’utiliser paketobuildpacks/builder-jammy-base:latest (https://github.com/paketo-buildpacks/builder-jammy-base) ou paketobuildpacks/builder-jammy-full:latest (https://github.com/paketo-buildpacks/builder-jammy-full) pour disposer d’outils supplémentaires dans l’image, si nécessaire.

Il est nécessaire d’avoir Docker installé. Pour les utilisateurs Linux, Docker doit être configuré pour un usage par des utilisateurs non-root.

Support natif et tests

Notions avancées

Configuration des propriétés imbriquées

Pour les propriétés de configuration, le moteur de Spring en traitement anticipé génère des indices de réflexion de manière automatique. Toutefois, pour que les propriétés de configuration imbriquées qui ne sont pas des classes internes soient reconnues, elles doivent impérativement porter l’annotation @NestedConfigurationProperty.

Voici un exemple avec la classe MesProperties :

@ConfigurationProperties(prefix = "my.properties") 
public class MesProperties { 
 
  private String name; 
 
  @NestedConfigurationProperty 
  private final Nested nested = new Nested(); 
 
  // getters / setters... 
 
} 

Puis la classe Nested correspondante :

public class Nested { 
 
  private int number; 
 
  // getters / setters... 
 
} 

Dans cet exemple, des propriétés de configuration sont créées pour my.properties.name et my.properties.nested.number. Sans l’annotation @NestedConfigurationProperty sur le champ nested, la propriété my.properties.nested.number ne serait pas accessible dans une image native.

Pour une liaison via constructeur, il est nécessaire d’annoter le champ avec @NestedConfigurationProperty :

@ConfigurationProperties(prefix = "my.properties") 
public class MonPropertiesCreator { 
 
  private final String name; 
 
  @NestedConfigurationProperty 
  private final Nested nested; 
 
  public MonPropertiesCreator(String name, Nested nested) { 
    this.name = name; 
    this.nested = nested; 
  } 
 
  // getters / setters... 
 
} 

En ce qui concerne l’utilisation de records, l’annotation @NestedConfigurationProperty doit être placée sur le paramètre :

@ConfigurationProperties(prefix = "my.properties") 
public record MyPropertiesRecord(String name,
@NestedConfigurationProperty Nested nested) { 
 
} 

Il est crucial d’utiliser des getters et setters publics dans tous les cas pour garantir que...

Alternatives

L’utilisation de GraalVM avec Spring Boot pour la compilation AOT et la génération d’images natives offre des avantages significatifs en termes de temps de démarrage et de consommation mémoire. Il existe des alternatives à l’utilisation de Spring avec GraalVM pour atteindre des objectifs similaires ou pour l’utiliser dans d’autres contextes.