Question Quels sont les avantages et les inconvénients d'AWS Elastic Beanstalk par rapport aux autres stratégies de déploiement?


Je suis assez nouveau pour l'ensemble de la pile Netflix OSS et des déploiements en général. En tant que contexte pour mon niveau actuel de connaissances, mon rôle principal est celui d’ingénieur d’application front-end. Cependant, j'aime le côté des opérations et j'essaie donc de définir une nouvelle stratégie de déploiement et les outils nécessaires à un nouveau projet.

Nos buts

  • Déploiement super facile (nous voulons appuyer sur un bouton pour mettre à jour la production)
  • Déploiement automatisé dans des environnements de test (à l'aide de Jenkins)
  • Facilité de maintenance (nous avons une application à écrire, nous ne voulons pas passer notre temps à régler des problèmes de production)
  • Capacité à gérer une architecture orientée service (nombreuses petites applications, langages variés et magasins de données)
  • Suffisamment de flexibilité pour nous assurer que nous n'aurons pas à changer de stratégie dans un avenir rapproché (nous essayons déjà de sortir de RightScale)

Nous sommes d'accord avec un peu plus de temps d'installation initiale si cela nous évitera des maux de tête à l'avenir.

Ainsi, dans le même ordre d’idées, j’ai écouté des podcasts, regardé des conférences Ops et lu des tonnes de billets de blog. En fonction de nos objectifs et de ce que j’ai considéré comme une pratique exemplaire, nous avons commencé à élaborer un plan en utilisant Asgard, roule notre paquet dans un bocal et le transforme en un AMI.

Tout cela était planifié et les avantages du processus par rapport à l'utilisation d'un serveur Chef et d'instances convergentes à la volée (nous avons pensé que c'était sujet aux erreurs compte tenu de notre calendrier limité et du manque de compréhension du flux de travail d'un serveur Chef). Cependant, un collègue a un peu cherché de ses propres yeux et s'est senti comme si Elastic Beanstalk répondait à nos besoins.

J'ai étudié la situation et créé un environnement de test avec un fichier WAR et une base de données RDS attachée. Les choses semblent fonctionner et je pense que nous pouvons automatiser les déploiements dans un environnement de test utilisant Jenkins via l'API AWS. Cela semble assez simple ... peut-être trop simple.

Ce que je me demande, c'est quel est le piège? Si Elastic Beanstalk est si simple et efficace, pourquoi n'en parle-t-on pas davantage? J'ai du mal à trouver suffisamment d'opinions objectives et de faits sur les deux stratégies de déploiement différentes, alors j'ai pensé poser des questions.

Utilisez-vous Elastic Beanstalk? Si oui, pourquoi et quels facteurs ont conduit à cette décision? Qu'est-ce que tu aimes et n'aimes pas?

Si vous n'utilisez pas Elastic Beanstalk mais que vous y avez pensé, qu'utilisez-vous et pourquoi n'avez-vous pas utilisé Elastic Beanstalk?

Quels sont les avantages et les inconvénients d'une stratégie de déploiement basée sur Elastic Beanstalk pour une SOA? Autrement dit, Elastic Beanstalk fonctionnera-t-il correctement avec de nombreuses petites applications qui dépendent les unes des autres?


16
2018-06-25 15:28


origine




Réponses:


J'ai évalué Elastic Beanstalk en plus d'autres offres AWS tout en essayant d'améliorer nos instances AWS roulées à la main. Les raisons pour lesquelles j'ai choisi de ne pas l'utiliser étaient dues à des complications entraînant la migration de mon application existante et non à l'offre elle-même. Le problème, c'est que vous n'avez pas autant de contrôle sur le déploiement / la configuration des applications des serveurs. Si vous démarrez une nouvelle application, il peut être utile de ne pas traiter ces problèmes pour le moment. Si vous avez une application existante, il est plus difficile de s'intégrer dans le modèle Beanstalk.

Beanstalk propose une offre similaire à Heroku et à d’autres fournisseurs de PaaS, mais ne présente pas un grand avantage pour ceux qui souhaitent simplement se concentrer sur la création de leur application. Vous devez au moins déterminer les ressources virtualisées dans une plus grande mesure que les autres fournisseurs de PaaS.

Problèmes rencontrés avec mes applications:

  • Déploiements basés sur Git - Je les adore mais notre repo est supérieure à 1 Go. Plutôt gros pour pousser régulièrement. Ce référentiel contient également environ 40 applications (qui devraient être scindées), mais cela prendrait un certain temps. Le téléchargement de n'importe quel type de paquet pourrait fonctionner, mais la plupart de nos applications nécessiteraient beaucoup de travail pour en faire un paquet.

  • Intégration avec d'autres services - D'après ce que j'ai vu, Beanstalk suppose en quelque sorte que tout ce à quoi vous vous connectez est un service unique. Cela fonctionne bien si vos services sont en retard et ELB mais que nous étions des nœuds distincts que nous avons utilisés via HAProxy exécuté sur chaque serveur d'applications. Si vous exécutez vos magasins de données et d’autres services en tant que point final unique, tout devrait bien se passer.

Dans mon évaluation, j'ai également inclus OpsWorks et CloudFormation. OpsWorks a des problèmes d'intégration similaires avec le fonctionnement de l'automatisation existante pour ces applications. CloudFormation n'a pas fait beaucoup plus que ce que certains scripts Python et Chef prenaient déjà en charge pour nous.

J'ai finalement choisi d'utiliser AWS Autoscaling Groups avec une certaine automatisation fournie par Asgard. Il s'agissait du plus petit changement apporté au code de configuration / d'application existant et nous fournissait les avantages que nous recherchions, à savoir la gestion simple de plusieurs serveurs disponibles via l'API AWS.

Les restrictions mises en place par Elastic Beanstalk sur votre application sont très utiles. Vous devrez vous assurer que votre application est généralement sans état, fournit un point de terminaison pour un service et s'appuie sur d'autres services pour state. Si vous essayez de créer des services autonomes réutilisables, plusieurs applications dans Beanstalk sont un bon début.

Si vous êtes sur le point de vouloir plus de configuration, OpsWorks est une excellente étape. Les rôles prédéfinis doivent faciliter le démarrage de la transition et fournissent un cadre d'automatisation autour de Chef permettant de coordonner le provisionnement de plusieurs serveurs.


11



Excellente réponse, Philip. Il semble que la plus grande limitation d’Elastic Beanstalk réside dans la configuration d’AMI de base. Donc, oui, pour un service de base, apatride, il semble être génial. Toutefois, lorsque vous devez exécuter plusieurs services (par exemple, nginx, surveillance spécialisée) au sein d'une seule instance, vous devez lancer votre propre AMI, puis perdre les mises à jour automatiques de l'AMI de base pour les services AWS. À ce stade, vous êtes déjà bien familiarisé avec un processus de déploiement personnalisé. Mon sentiment est que c'est à peu près le moment où vous voudriez envisager de vous éloigner d'EB. - James van Dyke


Je vois le point de la perte de contrôle, mais je ne vois pas nécessairement l'apatridie prescrite. Tout ce que fait eb, c'est déployer une automatisation, ce qui est génial. Je vois l'intérêt d'un grand référentiel. Je pense qu'en général, séparer les fonctions des applications logiques dans des applications de beans distinctes, puis créer des environnements de "staging" et de "prod", est vraiment agréable. Nous avons des environnements de modules comme uploader, cela ne fait pas grand chose et, en théorie, cela ajoute beaucoup de coûts, mais ensuite, vous utilisez des instances plus petites, mais en plus grande quantité. Nous avons exécuté un nginx centralisé et avons dû écrire beaucoup de descripteurs de message sns personnalisés pour notifier à ngnix les modifications apportées à la stratégie d’échelle automatique. Un autre problème important est l’incapacité à supprimer les équilibres de charge, car nous utilisons ngnix, pourquoi? elb ne supporte pas websocket.


0