Déploiement manuel par rapport à 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 du serveur tomcat et au déploiement, etc. pour une application Web Java typique. L'équilibrage de charge, la surveillance et l'autoscaling 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 sera-t-elle créée dans l'instance nouvellement créée ou elle accédera à la base de données que j'ai créée dans l'instance maître ... S'il ne crée qu'un réplica lors de l'autoscaling, comment la synchronisation des données se produira-t-elle entre les instances?

Tout ce que vous avez mentionné, comme l'équilibrage de charge, la surveillance et la mise à l'échelle automatique, sont sans aucun doute des avantages.

Cependant, vous devez y penser de cette façon: dans une véritable plate-forme en tant que service (PAAS), le but est de séparer l'application de la plate-forme. 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 (du moins en théorie).

EC2 en soi n'est pas PAAS. Cela ressemble plus à IAAS ( Infrastructure as a Service ). Vous devez toujours vous occuper des instances de serveur, y installer des logiciels, les maintenir à jour, etc.

Elastic Beanstalk est un système PAAS. Il en va de même pour App Engine et Azure, entre autres.

Dans un vrai système PAAS, le SGBD est un composant distinct du ou des serveurs d'applications Web. La raison est évidente: le SGBD ne peut pas être éventuellement installé sur les instances qui sont utilisées pour le serveur d'application car, comme les 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 votre ou 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 simplement équilibrer la charge, surveiller et mettre à l'échelle automatiquement.

1) Gère les versions des applications 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 d'abord déployer facilement une build 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 importantes du conteneur (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 enregistrez et archivez automatiquement les fichiers journaux dans S3. (Certes, cette fonctionnalité est actuellement un peu faible.)

J'avais une application déployée à la fois dans EC2 dédié (Nginx & Gunicorn) et 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é avec par défaut CentOS et Apache (Httpd). Vous pouvez choisir le système d'exploitation dans une instance dédiée.

• Ces choses qui m'importaient,

  • De nombreuses erreurs 504 se sont produites 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.
  • Installer / configurer des outils comme Celery, Redis (besoin d'exécuter un autre port), etc.,. dans une instance dédiée, c'est beaucoup plus facile.

• Dans mon cas, j'ai dû mettre à l'échelle 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 des serveurs est simple dans BeanStalk.

• J'avais pris des micro dans les deux cas (dédié & Beanstalk). Je sentais que la micro-instance dédiée était meilleure.

• Déploiement automatisé dans Beanstalk. J'ai dû écrire des scripts pour automatiser la même chose, ce qui est bien, car ce n'est qu'une seule fois.