Contactez-nous

Déploiement simple sur une machine virtuelle

Guide étape par étape pour déployer facilement votre application Spring Boot (Fat JAR) sur une machine virtuelle Linux ou Windows.

Introduction au déploiement sur machine virtuelle

Une fois votre application Spring Boot packagée sous forme de JAR exécutable (Fat JAR), l'une des méthodes de déploiement les plus directes consiste à l'exécuter sur une machine virtuelle (VM). Que ce soit une VM hébergée dans le cloud (AWS EC2, Google Compute Engine, Azure VM) ou sur votre propre infrastructure (VMware, VirtualBox), le principe reste similaire.

Cette approche est relativement simple et constitue une étape naturelle après le développement local. Elle ne nécessite pas la complexité des orchestrateurs de conteneurs ou des plateformes PaaS, la rendant idéale pour des applications monolithiques, des microservices simples, ou pour des environnements de test et de pré-production.

Ce chapitre décrit les étapes fondamentales pour déployer et exécuter votre Fat JAR sur une VM, en se concentrant sur les aspects essentiels pour rendre l'application opérationnelle.

Prérequis sur la machine virtuelle

Avant de pouvoir déployer votre application, la machine virtuelle cible doit disposer de l'environnement d'exécution Java (JRE) ou du kit de développement Java (JDK) compatible avec la version de Java utilisée pour compiler votre application Spring Boot. Le Fat JAR contient le code et les dépendances de l'application, mais il repose sur la présence d'une JVM sur le système hôte pour s'exécuter.

Assurez-vous qu'une version appropriée de Java est installée. Vous pouvez vérifier cela en vous connectant à la VM via SSH (pour Linux) ou Bureau à distance (pour Windows) et en exécutant la commande :

java -version

Si Java n'est pas installé ou si la version est incorrecte, vous devrez l'installer en utilisant le gestionnaire de paquets de votre système d'exploitation (comme `apt` pour Debian/Ubuntu, `yum` ou `dnf` pour CentOS/Fedora/RHEL) ou en téléchargeant et installant manuellement le JDK/JRE depuis le site officiel (OpenJDK, Oracle JDK, etc.).

Vérifiez également que les ports réseau requis par votre application (par exemple, le port 8080 par défaut pour une application web) ne sont pas bloqués par un pare-feu sur la VM ou au niveau du réseau (groupes de sécurité dans le cloud).

Transfert du fichier JAR vers la VM

L'étape suivante consiste à copier le fichier Fat JAR généré lors du build (par exemple, `my-app-1.0.0.jar`) depuis votre machine de développement ou votre serveur d'intégration continue vers la machine virtuelle cible.

Plusieurs méthodes peuvent être utilisées :

  • SCP (Secure Copy Protocol) : Un outil en ligne de commande standard sur les systèmes Linux et macOS (et disponible sur Windows via des clients SSH ou WSL) pour copier des fichiers de manière sécurisée via SSH. Exemple :
scp path/to/your/my-app-1.0.0.jar username@vm_ip_address:/path/on/vm/
  • SFTP (SSH File Transfer Protocol) : Un protocole similaire à FTP mais sécurisé via SSH, utilisable avec des clients graphiques (comme FileZilla, WinSCP) ou en ligne de commande.
  • Outils spécifiques au fournisseur Cloud : Certains fournisseurs cloud proposent des outils ou des interfaces pour faciliter le transfert de fichiers vers leurs VM.
  • Téléchargement direct : Si le JAR est hébergé quelque part (par exemple, un gestionnaire d'artefacts comme Nexus ou Artifactory), vous pourriez le télécharger directement sur la VM en utilisant des outils comme `wget` ou `curl`.

Choisissez la méthode la plus appropriée à votre environnement et à vos outils. Il est recommandé de placer le fichier JAR dans un répertoire dédié sur la VM (par exemple, `/opt/my-app` ou `/var/www/my-app`).

Exécution de l'application Spring Boot

Une fois le fichier JAR transféré sur la VM et Java installé, vous pouvez lancer l'application Spring Boot très simplement en utilisant la commande `java -jar` dans le terminal de la VM :

cd /path/on/vm/
java -jar my-app-1.0.0.jar

L'application va démarrer, et vous verrez les logs de Spring Boot s'afficher directement dans la console. Si c'est une application web, elle commencera à écouter sur le port configuré (par défaut 8080).

Il est souvent nécessaire de passer des configurations spécifiques à l'environnement lors du lancement. Vous pouvez le faire via des arguments de ligne de commande Spring Boot ou des propriétés système Java :

# Spécifier un profil actif et un port différent
java -Dspring.profiles.active=production -jar my-app-1.0.0.jar --server.port=80

# Augmenter la mémoire allouée à la JVM
java -Xms512m -Xmx1024m -jar my-app-1.0.0.jar

Ces configurations peuvent également être gérées via des fichiers `application-{profile}.properties` ou des variables d'environnement, qui sont souvent préférables pour éviter de longues lignes de commande.

Exécution en arrière-plan (Approche simple)

Si vous lancez l'application directement dans une session SSH comme ci-dessus, elle s'arrêtera dès que vous fermerez la session. Pour une exécution continue, l'application doit tourner en arrière-plan.

Une méthode très basique sur les systèmes Linux consiste à utiliser `nohup` (No Hang Up) et l'esperluette (`&`) :

nohup java -jar my-app-1.0.0.jar &

`nohup` empêche le processus de recevoir le signal SIGHUP (envoyé lors de la fermeture du terminal), et `&` le place immédiatement en arrière-plan. La sortie standard (logs) sera généralement redirigée vers un fichier nommé `nohup.out` dans le répertoire courant.

Vous pouvez rediriger explicitement la sortie vers un fichier de log spécifique :

nohup java -jar my-app-1.0.0.jar > /path/to/logs/my-app.log 2>&1 &

Cette commande redirige la sortie standard (`>`) et la sortie d'erreur (`2>&1`) vers le fichier `my-app.log`, puis lance le tout en arrière-plan.

Important : Bien que simple, cette méthode `nohup` est très rudimentaire. Elle ne gère pas le redémarrage automatique en cas de crash de l'application ou de redémarrage de la VM. Pour des déploiements plus robustes, il est fortement recommandé d'utiliser un gestionnaire de processus comme `systemd` ou `supervisor`, qui sont abordés dans un chapitre ultérieur.

Considérations finales pour un déploiement simple

Ce déploiement simple sur VM est un bon point de départ, mais il présente des limitations :

  • Gestion manuelle : Le transfert et le lancement sont souvent manuels. L'automatisation via des scripts ou des outils de déploiement est nécessaire pour la répétabilité.
  • Pas de haute disponibilité : Une seule instance sur une VM unique représente un point de défaillance unique (Single Point of Failure).
  • Gestion des processus limitée : Comme mentionné, `nohup` est basique. Un vrai gestionnaire de processus est nécessaire pour la production.
  • Gestion de la configuration : Passer la configuration en ligne de commande n'est pas idéal. L'utilisation de profils, de variables d'environnement ou d'un serveur de configuration est préférable.
  • Sécurité : Exécuter l'application avec un utilisateur dédié (non-root) est une bonne pratique. La gestion des secrets (mots de passe, clés API) doit être sécurisée.
  • Mises à jour : Le processus de mise à jour (arrêter l'ancienne version, copier la nouvelle, redémarrer) doit être défini et idéalement automatisé pour minimiser les temps d'arrêt.

Malgré ces limites, comprendre ce processus de déploiement simple est fondamental avant d'aborder des solutions plus complexes comme la conteneurisation avec Docker ou le déploiement sur des plateformes cloud gérées.