Le point de départ
Tout a commencé quand un de nos clients nous a sollicité pour déployer en urgence une application web existante. Les serveurs existants devant être décommissionnés à la fin du mois, il fallait donc trouver une solution d'hébergement. Notre réflexe a été naturellement de penser cloud. Le client disposait déjà de comptes AWS, le choix a été rapide. Ensuite il a fallu choisir le service correspondant à nos contraintes :
- pouvoir mettre en ligne une application web Java packagé sous forme de war
- un délai de mise en production court
- un budget non prévu donc un coût minimum
- peu de compétence interne pour reprendre l'exploitation
Dans le cloud, le provider AWS propose de nombreuses solutions pour héberger un workload (EC2, Fargate, Lightsail, EKS). Mais compte-tenu de nos contraintes, le choix du service Paas nous est apparu comme évident : AWS Elastic Beanstalk
Vous connaissez tous l'histoire de Jack et le haricot magique ? 🥭
Et bien le service AWS Elastic Beanstalk, c'est un peu le même concept. C'est une plateforme en tant que service PaaS proposée par AWS. En considérant notre application comme étant un haricot, AWS vous fournit une solution pour le faire pousser : un environnement beanstalk 😲
Cet environnement vous permet de déployer votre application rapidement (presque), tout en faisant abstraction de l'environnement technique (infrastructure, serveur, configurations, etc.).
Un peu d'histoire
Avant de rentrer dans le vif du sujet, il est important de revenir en arrière pour imaginer les progrès qui ont été faits en matière d'hébergement d'applications. Je ne le crie pas sur tous les toits maintenant que je fais partie de la practice Cloud & DevOps Ippon, mais j'ai un lourd passif de développeur fullstack 🤫
Au début de ma carrière de développeur Java, pour builder et déployer une application c'était vraiment un exercice long et pénible. C'est un temps que les moins de 30 ans ne peuvent pas connaître. C'est simple, il fallait presque tout faire de A à Z : commander un serveur, installer, configurer...
Ensuite, il fallait se perdre dans les différents services de la DSI pour trouver la personne habilitée capable de nous aider. On ne va pas se mentir, cela se résumait à copiner avec l’un des barbus 🧔 (nos bons vieux administrateurs systèmes). Seul un membre de cette confrérie, avait le pouvoir de faire pousser notre haricot, moyennant quelques bières 🍻 au bar du coin. Certains constateront que c'est toujours le cas. Je vous parle d'une époque ou les droits d'administration se lèguaient de génération en génération. La finalité consistait à copier notre war dans le répertoire “www” du serveur Tomcat et prier pour que l’application tourne.
Depuis il y a eu énormément d'évolutions, dans les moyens employés et dans les mentalités : CI/CD, cloud, conteneurisation, DevOps.
Sur le sujet, je vous invite d'ailleurs à lire l’excellent livre blanc de Medhi El Kouhen "Comprendre le devops pour le mettre en oeuvre" sur le sujet.
Maintenant avec Jack, mais surtout la puissance magique de l'infrastructure d'AWS, toute la plateforme est déployée en quelques clics !
Le service AWS Elastic Beanstalk
AWS Elastic Beanstalk vous permet de gérer toutes les ressources qui exécutent votre application. Première étape, lire la documentation : documentation AWS EB officielle.
C'est bête à dire mais il faut lire la documentation. Les documentations AWS sont très bien faites et regorgent d'informations permettant d'utiliser ses services correctement. Cela m’aurait fait gagner un temps précieux notamment sur le packaging, j’y reviendrai plus tard.
Voici un condensé des concepts clés du service :
- Application : élément le plus haut niveau du service qui correspond à un dossier contenant l’ensemble des éléments logiques au fonctionnement.
- Version de l'application : fait référence à une itération du code à déployer.
- Environnement : collection de ressources AWS allouées dynamiquement qui exécutent une version de l'application.
- Type d'environnement : Web server ou Worker.
- Configuration de l'environnement : regroupe un ensemble de paramètres et de réglages qui définissent le comportement d'un environnement.
- Configuration enregistrée : template permettant de créer des configurations d'environnement unique.
- Plateforme : Docker, Go, Java SE, Tomcat, .NET Core sous Linux, .NET sous Windows Server, Node.js, PHP, Python, Ruby (liste des versions).
La configuration
Pour déployer votre haricot, la page d'accueil du service vous invite à créer une application. Vous allez devoir remplir plusieurs formulaires pour configurer votre environnement, certains sont optionnels pour vous faciliter le travail.
Step 1 : Configure environment
Point important, sélectionner une branche correspondant à la version de Java (Beanstalk Java utilise la distribution Corretto)
Step 2 : Configure service access
Vous pouvez choisir d'utiliser un rôle préalablement créé ou laisser AWS le créer pour vous. Laisser le service créer le rôle vous permet de le récupérer dans le cas où vous provisionniez l'environnement avec Terraform.
Step 3 (optional) : Networking, database, tags
Sélectionnez un VPC ou créez-en un dédié, et choisissez les subnets dans lesquels vous voulez lancer vos applications. AWS préconise d'utiliser des subnets privés pour ne pas exposer les instances sur internet. En complément, vous pouvez utiliser un load balancer dans un subnet public.
Dans cette étape, vous avez aussi la possibilité de configurer l’accès à une base de données RDS :
Step 4 (optional) : Configure instance traffic and scaling
Step 5 (optional) : Configure monitoring
Step 6 : Review
Une page review vous affiche la synthèse, il vous suffit de valider et d’attendre le lancement de l'environnement :
Au bout de quelques minutes, vous devriez voir apparaître ce message si tout est correctement lancé :
Bien entendu, vous avez aussi la possibilité d'utiliser de l'infra as code (IaC) comme je l'ai fait. Pour ma part, j'ai utilisé Terraform. Cela m'a permis de déployer plusieurs environnements dans différents comptes AWS en modifiant un seul fichier de configuration tfvars pour les connaisseurs. Je vous invite à lire l'article "Gestion de ressources critiques avec Terraform sur AW" sur le blog Ippon.
Dans ce cas, votre environnement est configurable via les namespaces.
Un exemple des configurations possibles avec Terraform :
Le namespace “aws:ec2:vpc” permet de spécifier les paramètres du VPC.
Au passage, j’en profite pour remercier la practice Cloud Ippon (et ce n'est pas parce que c'est mon mananger qui est admin, promis 😂). Nous avons la chance de disposer d’une sandbox AWS qui nous permet de tester l'ensemble des services. Je ne saurais que vous conseiller de mettre en place ce système dans votre entreprise. Moyennant quelques dizaines d'euros d'investissement mensuel 💵 (avec une bonne SCP 😉) vos équipes peuvent tester les services et s'autoformer.
Le packaging
Une fois votre environnement prêt, pour une application web, il faut packager votre war dans un source bundle. Ce bundle doit respecter le formalisme .ebextensions pour le déploiement d'applications web. Pour vos premiers tests, vous pouvez utiliser comme je l'ai fait le sample war d'apache Tomcat.
Le zip doit contenir au moins ces éléments :
-
un script de pré-déploiement qui sera exécuté avant le lancement de l'instance : .platform/hooks/predeploy/fs.sh
(j'avais ajouté une ligne pour monter un filesystem)
-
un fichier "Procfile" contenant la ligne de commande pour démarrer le service War de l’application :
web: java -Duser.timezone=Europe/Paris -Dserver.port=5000 -Djavax.net.debug=ssl:handshake:verbose -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Dspring.profiles.active=prod -jar application-web.war_
mes collègues développeurs Java comprendront, coucou 👋 la practice fullstack Ippon 😁
- votre war à déployer
Une ligne de commande pour créer le zip et c'est terminé !
zip -r topaze-01-prod.zip ./.platform/hooks/predeploy/fs.sh Procfile topaze-web.war
Il ne vous restera plus qu'à déployer la version de votre haricot packagé via la console AWS :
Le déploiement
Un des avantages du service c’est de pouvoir disposer de “Paramètres et stratégies de déploiement”. Plusieurs options de déploiement s'offrent à vous : simultanément, propagation, propagation par lot, immuable, répartition du trafic. Il faut comprendre ici blue/green, canary.
=> Les déploiements avec répartition du trafic vous permettent d'effectuer des tests Canary. Sur le sujet, je vous invite à lire l’article : déploiement progressif d’une application dans un cluster Kubernetes grâce à Flagger.
Tarification
Comme c'est souvent le cas avec les services managés d'AWS, le service est gratuit. Enfin ce n'est pas encore Noël, vous paierez quand même les ressources qui seront utilisées par le service (EC2, S3, EBS, etc..). Il y a évidemment une solution single instance éligible au free tier (offre gratuite limitée à un an). Vous pouvez retrouver l'ensemble du Pricing Beanstalk sur la page du service.
Avantages
- Product-centric : réduit les opérations d’infrastructure, l’équipe de développement se concentre les développements
- Configuration rapide et automatisation : time to market réduit
- Supporte de nombreuses plateformes
- Intégration aux outils AWS : exemple monitoring Cloudwatch
Inconvénients
- Mise à jour de la pile Cloudformation : Beanstalk génère une stack Cloudformation. Les mises à jour impliquent bien souvent la recréation complète de la pile.
- Versions des plateformes limitées et mise à jour non transparente (sans documentation)
- Déploiement très long : il faut attendre 15 minutes !!! Si tout se passe bien…
- Pas facile de diagnostiquer les problèmes
Conclusion
Ce service n’est pas magique contrairement au haricot de Jack. Ce service est parfait quand vous n’avez pas trop de compétences Cloud et que vous souhaitez déployer un WAR rapidement. Je l’ai utilisé de façon transitoire pour permettre au client d’exposer son application en attendant de trouver une solution pérenne. Je vous conseille de l’utiliser, en tant que tel, pour des déploiements ponctuels ou des tests mais pas en production.
Personnellement, j’aime bien garder la main sur ce qui est déployé. L’utilisation de Cloudformation rajoute de l’opacité dans l’utilisation du service et rend les déploiements peu fiables à mon goût. Une modification entraîne la plupart du temps la recréation de la stack complète et finalement on ne sait pas bien ce qui est conservé ou recréé. En résumé, si vous n’aimez pas Cloudformation, vous n’aimerez pas Elastic Beanstalk.
