Déploiement manuel vs Amazon Elastic Beanstalk
Quels sont les avantages que nous obtenons en utilisant Elastic Beanstalk par rapport à la création manuelle d'une instance EC2 et à la configuration d'un serveur Tomcat et à un déploiement, etc. pour une application Web classique Java. L'équilibrage de charge, la surveillance et la mise à l'échelle automatique sont-ils les seuls avantages?
Supposons que pour mon application Web qui utilise la base de données, j'ai installé la base de données dans l'instance EC2 elle-même. Lorsque l'autoscalling a lieu, la base de données est-elle créée dans la nouvelle instance créée ou accède-t-elle à la base de données que j'ai créée dans l'instance principale ... Si elle crée juste une réplique lors de la mise à l'échelle automatique, comment se fera la synchronisation des données entre les instances?
Toutes les choses que vous avez mentionnées comme l'équilibrage de charge, la surveillance et la mise à l'échelle automatique sont certainement des avantages.
Cependant, vous devez y penser de cette façon: Dans un vrai Platform as a Service (PAAS), le but est de séparer l'application de la plateforme. En tant que développeur, vous ne vous souciez que de votre application. La plateforme vous est "louée". Les "instances" de la plateforme sont automatiquement mises à jour, administrées, mises à l'échelle, équilibrées, etc. pour vous. Vous venez de télécharger votre fichier WAR et cela fonctionne (au moins théoriquement).
EC2 n'est pas en soi PAAS. Cela ressemble plus à l'IAAS ( Infrastructure as a Service ). Vous devez toujours prendre soin des instances de serveur, installer des logiciels sur celles-ci, les maintenir à jour, etc.
Elastic Beanstalk est un système PAAS. Il en va de même pour App Engine et Azure parmi tant d'autres.
Dans un véritable système PAAS, le SGBD est un composant distinct des serveurs d'applications Web. La raison est évidente: le SGBD ne peut pas être installé sur les instances utilisées pour le serveur d'applications car, à mesure que des instances sont créées et détruites en fonction de votre trafic, le SGBD serait perdu! Avoir le SGBD et le serveur d'applications sur la même machine/instance n'est généralement pas une bonne idée de toute façon.
Dans un système PAAS, le SGBD est un service distinct. Pour Amazon, ce serait Amazon RDS . Tout comme avec Elastic Beanstalk, où vous n'avez pas à vous soucier du serveur d'applications et vous téléchargez simplement votre fichier WAR, avec RDS, vous n'avez pas à vous soucier du SGBD et vous déployez simplement vos bases de données.
Elastic Beanstalk et RDS fonctionnent très bien ensemble, en particulier lorsqu'ils sont déployés dans la même zone de disponibilité, où la latence serait très faible.
Enfin, l'utilisation d'Elastic Beanstalk ne coûte rien de plus que les ressources déployées (instances EC2 et équilibreur de charge). Cependant, RDS n'est pas bon marché et serait certainement plus cher que d'utiliser une seule instance EC2 pour le serveur d'applications et le SGBD.
Elastic Beanstalk fait plus que l'équilibrage de charge, la surveillance et la mise à l'échelle automatique.
1) Gère les versions d'application en stockant et en gérant différentes versions de votre application, ce qui vous permet de basculer facilement entre les différentes versions de vos applications.
2) A le concept "d'environnements" pour chaque application, vous permettant de déployer différentes versions de votre application dans chaque environnement. C'est pratique par exemple si vous souhaitez configurer des environnements QA et DEV séparés, et que vous souhaitez facilement déployer une build d'abord dans DEV puis déployer la même version de l'application dans QA lorsque votre équipe QA est prête pour la prochaine build.
3) Externalise les propriétés de configuration de conteneur importantes (paramètres de mémoire Tomcat, par exemple) vers la console et l'API Elastic Beanstalk. Pour cette raison, vous pouvez facilement enregistrer les paramètres et les copier entre les environnements.
4) Affichez les fichiers journaux des applications via la console et effectuez automatiquement le roll et l'archivage des fichiers journaux sur S3. (Certes, cette fonctionnalité est actuellement un peu faible.)
J'ai fait déployer une application à la fois dans EC2 dédié (Nginx & Gunicorn) et dans Beanstalk Environment (CentOS & Apache2).
Mes observations:
BeanStalk est Paas. Créer manuellement une instance EC2 (IAAS), c'est comme tout faire à partir de zéro, mais vous avez un contrôle solide.
BeanStalk est livré par défaut avec CentOS et Apache (Httpd). Vous pouvez choisir le système d'exploitation dans une instance dédiée.
Ces choses qui m'importaient,
- Il y avait beaucoup d'erreurs 504 apparaissant dans l'environnement Beanstalk.
- Il était difficile de déboguer lorsque le serveur BeanStalk tombait en panne, car les journaux n'apparaissaient pas non plus et ne pouvaient pas ssh dans la machine. C'est très important.
- Installation/configuration d'outils comme Celery, Redis (besoin d'exécuter un autre port), etc.,. en instance dédiée est beaucoup plus facile.
Dans mon cas, j'ai dû faire évoluer le serveur (Beanstalk) afin d'exécuter l'installation de certains packages (comme pandoc). Ces choses sont plus simples dans Ubuntu.
La mise à l'échelle est beaucoup plus facile dans BeanStalk. Le clonage de serveurs est simple dans BeanStalk.
J'avais pris du micro dans les deux cas (dédié & Beanstalk). Je pensais que la micro-instance dédiée était meilleure.
Déploiement automatisé dans Beanstalk. J'ai dû écrire des scripts pour les automatiser, ce qui est bien, car ce n'est qu'une seule fois.