Déploiement manuel par rapport à Amazon Elastic Beanstalk


114

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?

Réponses:


144

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.


3
Bien placé. Juste un ajout: vous pouvez spécifier une AMI personnalisée qui servira de base à chaque création d'instance. Ainsi, vous pouvez par exemple personnaliser une image Apache avec toutes les configurations et applications nécessaires et l'utiliser comme AMI de base (il existe un champ ID AMI personnalisé dans la configuration de l'environnement Beanstalk). Néanmoins, les données générées par l'exécution seraient effectivement supprimées à chaque arrêt d'instance (et l'équilibreur de charge le fera!).
André Felipe

1
Une chose qui m'a pris au dépourvu est le fait qu'Elastic Beanstalk crée un équilibreur de charge pour chaque environnement déployé. Les équilibreurs de charge ne sont pas vraiment coûteux à exécuter, mais ils coûtent à peu près le même coût qu'une micro-instance.
Ken Liu

@KenLiu, Load Balancer est plus puissant qu'une micro-instance.
BigSack

7
@BigSack - le point que j'essayais de faire valoir est qu'Elastic Beanstalk est censé être gratuit, mais AWS ne montre pas clairement que chaque environnement allouera un équilibreur de charge qui vous coûtera environ 15 $ par mois. Je ne comparais pas avec une micro-instance.
Ken Liu

Pour autant que je sache, RDS est presque équivalent en prix à EC2 ces jours-ci, tout en offrant une utilité, une maintenabilité et une fiabilité bien supérieures.
Justin Schier le

38

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.)


Quoi qu'il en soit, dans mon concept, je pense qu'il veut comprendre les performances, ce que je n'aime pas dans beanstalk, les dysfonctionnements au déploiement et les cas de catastrophe, et tout peut être pareil ou mieux en utilisant LAMBDA. Difficile mais c'est une solution miracle pour votre haute disponibilité.
Lucas Rodrigues Sena le

Juste pour ajouter au dernier point: vous pouvez envoyer tous les journaux d'application à CloudWatch.
SebaGra

6

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.