Un exemple de virtualisation d’applications

Problématique

Dans l’histoire de la virtualisation, il y a 30 ans IBM a implémenté une solution pour virtualiser les mainframes. Plus tard dans la fin des années 80 et le début des années 90, les applications client-serveur distribuées ont été introduites par Microsoft. Mais ces solutions couvraient certains aspects techniques mais pas tous, par exemple voici quelques problèmes de la virtualisation à cette époque :
  – énorme consommation de ressources,
  – l’infrastructure physique qui coûte cher,
  – gestion des applicatifs difficile,
  – problèmes de sécurité.

Fonctionnalités et solutions

---

Pour répondre à ces besoins, la virtualisation est un moyen d’abstraire le système d’exploitation et les applications; chaque application étant isolée des autres, si l’une des applications tombe en panne, elle n’a aucun impact sur les autres.
Lorsque nous avons de nombreux serveurs en tant que machines virtuelles, cela aide à mieux répartir les ressources et les distribuer, quand un utilisateur veut communiquer via des requêtes avec l’une des applications c’est le serveur concerné qui répond à l’utilisateur et quand l’utilisateur exécute l’application depuis son poste il n’y a aucun risque de compatibilité ou de paramétrage. Comme ça nous pouvons avoir plusieurs utilisateurs utilisant la même ressource en même temps sans risquer de générer des problèmes avec la consommation de ces ressources.

VMware ThinApp

VMware ThinApp est une solution de virtualisation d’applications. ThinApp est capable d’exécuter des applications sans qu’elles soient installées (au sens habituel). Le présent virtuel à l’utilisation est une vue des ressources physiques et virtuelles, ThinApp ne nécessite pas l’installation de pilotes de périphérique permettant aux applications de s’exécuter à partir de partages réseau sans nécessiter de droits d’administrateur. Il est également capable d’analyser un système avant et après l’installation d’une application et de créer un exécutable portable basé sur les modifications apportées aux fichiers système et au registre.

Microsoft App-V

App-V permet de déployer des applications sur n’importe quel client à partir d’un serveur d’applications virtuel, le client App-V doit être installé sur les machines clientes et les données d’application stockées sur le serveur d’applications virtuel sont installées au cache client à la demande lors de sa première utilisation ou pré-installé dans un cache local. App-V permet ainsi une installation et une gestion centralisée des applications déployées. Il prend en charge le contrôle d’accès basé sur des règles, c’est un composant supplémentaire nécessitant une licence d’utilisation.

Conteneurisation

La conteneurisation est une alternative à la virtualisation complète des machines qui implique l’encapsulation d’une application dans un conteneur avec son propre environnement d’exploitation. Cela offre de nombreux avantages du chargement d’une application sur une machine virtuelle, car l’application peut être exécutée sur n’importe quelle machine physique appropriée sans se soucier des dépendances.

La conteneurisation a récemment gagné en importance avec Docker. Les conteneurs Docker sont conçus pour fonctionner sur tout, des ordinateurs physiques aux machines virtuelles.

---

Exemple de conteneurisation Docker d’une API SpringBoot

Nous commençons maintenant avec un exemple basique de virtualisation d’application, une API avec Java (Spring boot SB) et Docker pour la conteneurisation.

La première des choses, est la création d’une SB application, pour l’intérêt de notre sujet, on va se concentrer plus sur la partie Docker. Pour cela, je vous invite a crée une API SB, sous cette architecture.

Si vous regardez plus bas, il y a ce mystèrieux fichier nommé Dockerfile, c’est celui qui contient la configuration du container Docker, je vous en parlerai après.

Ensuite, il faut qu’on prépare notre contrôleur, c’est le cœur de notre application.

Bien sûr, il faut ajouter deux annotation obligatoires la @SpringBootApplication , et @RestController.

Ensuite, on fait un petit test sur local pour s’assurer que tous ça marche.

Maintenant, on va crée un ficher Dockerfile, mais avant, il faut qu’on répond à la question, à quoi sert ce fichier ?

Dockerfile est un fichier crée à la racine du projet, définissant les étapes à suivre pour créer une image à partir d’un projet. Pour cela il vous faut créer un nouveau fichier nommé Dockerfile sans extension.

Ensuite vous allez spécifier, une image de base, sur laquelle le reste sera construit.

FROM openjdk:8-jdk-alpine

Sachez que tous les fichiers Dockerfile commencent par cette ligne, vous pouvez commencer par :

FROM scratch

C’est-à-dire que vous allez créer une image basée d’une image vide, dans notre cas on a utilisé comme image de base une image d’alpine, cette image contient un déploiement du JDK.

Le reste du fichier est comme suit :

ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} DockerSpringBoot-0.0.1-SNAPSHOT.jar
ENTRYPOINT ["java","-jar","/DockerSpringBoot-0.0.1-SNAPSHOT.jar"]

• ARG : déclaration d’une variable avec une valeur par défaut, cette variable vous pouvez la modifie au moment du build.
• COPY : copier le jar de notre application dans le dossier déjà déclaré
• ENTRYPOINT : exécuter le fichier jar de l’application dans le container,

Vous voyez, ce n’est pas grand chose mais c’est suffisant pour la bonne exécution de notre API, et bien sûr il existe beaucoup de commandes à explorer, selon vos besoins.

Voici notre version finale de Dockerfile

#Getting base image of alpine
FROM openjdk:8-jdk-alpine 
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} DockerSpringBoot-0.0.1-SNAPSHOT.jar
ENTRYPOINT ["java","-jar","/DockerSpringBoot-0.0.1-SNAPSHOT.jar"]

Build Docker image

Maintenant, nous avons un fichier Dockerfile qui répond à notre besoin. On va créer notre image Docker. Après que l’on se déplace à la racine, on exécute une ligne de commande pour lancer le build :

 sudo docker build -t dockerspringboot .

Vous allez voir des messages durant chaque phase de build, chacune des phases correspond à une instruction du ficher Dockerfile

Comme je vous déjà mentionné, chaque phase (step) correspond a une instruction dans Dockerfile, et le dernier message indique que le build est terminé avec succès.

Run Docker image

Avant d’exécuter notre image, on va lister les images Docker pour voir la notre :

Maintenant on va exécuter notre image avec la commande docker run

sudo docker run -d --name springContainer-p 80:8080 dockerspringboot

• -d ou --detach : pour exécuter notre image en background.
• -p ou --publish : puisque je vais essayer d’accéder depuis extérieure à l’application, docker me permet d’avoir un port depuis lequel je peux y accéder, du coup je déclare
• --name : spécifie un nom avec lequel vous pouvez faire référence à votre conteneur dans les commandes suivantes, dans se cas helloworld

et voila le résultat final.