AWS OpsWorks vs AWS Beanstalk vs AWS CloudFormation?

Je voudrais savoir quels sont les avantages et les inconvénients de l'utilisation d'AWS OpsWorks par rapport à AWS Beanstalk et AWS CloudFormation?

Je suis intéressé par un système qui peut être mis à l'échelle automatiquement pour gérer tout nombre élevé de requêtes Web simultanées (de 1000 requêtes par minute à 10 millions de tr / min.), Y compris une couche de base de données qui peut également être auto-évolutive.

Au lieu d'avoir une instance distincte pour chaque application, je voudrais idéalement partager certaines ressources matérielles de manière efficace. Dans le passé, j'ai principalement utilisé une instance EC2 + RDS + Cloudfront + S3

Le système de pile hébergera des applications ruby ​​on rails à fort trafic que nous migrons depuis Heroku, ainsi que des applications python / django et certaines applications PHP.

Merci d'avance.

J'aimerais savoir quels sont les avantages et les inconvénients de l'utilisation d'AWS OpsWorks par rapport à AWS Beanstalk et AWS CLoudFormation?

La réponse est: cela dépend.

AWS OpsWorks et AWS Beanstalk sont (on m'a dit) simplement des façons différentes de gérer votre infrastructure, en fonction de la façon dont vous y pensez. CloudFormation est simplement un moyen de modéliser votre infrastructure.

Personnellement, je suis plus familier avec Elastic Beanstalk, mais à chacun le sien. Je le préfère car il peut faire des déploiements via Git. Il est de notoriété publique qu'Elastic Beanstalk utilise CloudFormation sous le capot pour lancer ses environnements.

Pour mes projets, j'utilise les deux en tandem. J'utilise CloudFormation pour créer un environnement VPC personnalisé, des compartiments S3 et des tables DynamoDB que j'utilise pour mon application. Ensuite, je lance un environnement Elastic Beanstalk à l'intérieur du VPC personnalisé qui sait comment parler aux ressources S3 / DynamoDB.

Je suis intéressé par un système qui peut être mis à l'échelle automatiquement pour gérer tout nombre élevé de requêtes Web simultanées (de 1000 requêtes par minute à 10 millions de tr / min.), Y compris une couche de base de données qui peut également être auto-évolutive.

Sous le capot, OpsWorks et Elastic Beanstalk utilisent EC2 + CloudWatch + Auto Scaling, qui est capable de gérer les charges dont vous parlez. RDS prend en charge les bases de données évolutives basées sur SQL.

Au lieu d'avoir une instance distincte pour chaque application, je voudrais idéalement partager certaines ressources matérielles de manière efficace. Dans le passé, j'ai principalement utilisé une instance EC2 + RDS + Cloudfront + S3

En fonction de ce que vous entendez par « certaines ressources matérielles», vous pouvez toujours lancer des instances EC2 autonomes aux côtés des environnements OpsWorks ou Elastic Beanstalk. À l'heure actuelle, Elastic Beanstalk prend en charge une application Web par environnement. Je ne me souviens pas de ce qu'OpsWorks prend en charge.

Le système de pile hébergera des applications ruby ​​on rails à fort trafic que nous migrons depuis Heroku, ainsi que des applications python / django et certaines applications PHP.

Tout cela est entièrement pris en charge par AWS. OpsWorks et Elastic Beanstalk se sont optimisés pour un éventail d'environnements de développement (Ruby, Python et PHP sont tous sur la liste), tandis qu'EC2 fournit des serveurs bruts sur lesquels vous pouvez installer tout ce que vous voulez.

OpsWorks est un outil d'orchestration comme Chef - en fait, il est dérivé de Chef - Puppet, Ansible ou Saltstalk. Vous utilisez Opsworks pour spécifier l'état dans lequel vous voulez que votre réseau se trouve en spécifiant l'état dans lequel vous voulez que chaque ressource (instances de serveur, applications, stockage) se trouve. Et vous spécifiez l'état dans lequel vous voulez que chaque ressource soit en spécifiant la valeur souhaitée pour chaque attribut de cet état. Par exemple, vous pouvez souhaiter que le service Apache soit toujours opérationnel et démarre au démarrage avec Apache en tant qu'utilisateur et Apache en tant que groupe Linux.

CloudFormation est un modèle json (**) qui spécifie l'état de la ou des ressources que vous souhaitez déployer, c'est-à-dire que vous souhaitez déployer une instance AWS EC2 micro t2 dans us-east-1 dans le cadre du VPC 192.168.1.0/24 . Dans le cas d'une instance EC2, vous pouvez spécifier ce qui doit s'exécuter sur cette ressource via votre script bash personnalisé dans la section user-data de la ressource EC2. CloudFormation n'est qu'un modèle. Le modèle ne devient une ressource en cours d'exécution que si vous l'exécutez via AWS Management Console pour CloudFormation ou si vous exécutez la commande aws cli pour Cloudformation, c'est-à-dire aws cloudformation ...

ElasticBeanstalk est un PAAS - vous pouvez télécharger les applications spécifiquement Ruby / Rails, node.js ou Python / django ou Python / Flask. Si vous exécutez autre chose comme Scala, Haskell ou autre chose, créez une image Docker pour celle-ci et téléchargez cette image Docker dans Elastic Beanstalk (*).

Vous pouvez télécharger votre application dans Elastic Beanstalk en exécutant aws cli pour CloudFormation ou en créant une recette pour qu'Opsworks télécharge votre application dans Elastic Beanstalk. Vous pouvez également exécuter le cli aws pour Cloudformation via Opsworks.

(*) En fait, la documentation d'AWS sur son exemple d'application Ruby était si pauvre que j'ai perdu patience et intégré l'exemple d'application dans une image Docker et téléchargé l'image Docker dans Elastic Beanstalk.

(**) Depuis septembre 2016, Cloudformation prend également en charge les modèles YAML.

Dans Opsworks, vous pouvez partager des «rôles» de couches sur une pile pour utiliser moins de ressources en combinant les tâches spécifiques qu'une instance sous-jacente peut effectuer.

Liste de compatibilité des couches (tant que les groupes de sécurité sont correctement définis):

HA Proxy : custom, db-master, and memcached.
MySQL :  custom, lb, memcached, monitoring-master, nodejs-app, php-app, rails-app, and web.
Java : custom, db-master, and memcached.
Node.js : custom, db-master, memcached, and monitoring-master
PHP : custom, db-master, memcached, monitoring-master, and rails-app.
Rails :  custom, db-master, memcached, monitoring-master, php-app.
Static :  custom, db-master, memcached.
Custom : custom, db-master, lb, memcached, monitoring-master, nodejs-app, php-app, rails-app, and web 
Ganglia :  custom, db-master, memcached, php-app, rails-app. 
Memcached :  custom, db-master, lb, monitoring-master, nodejs-app, php-app, rails-app, and web. 

référence: http://docs.aws.amazon.com/opsworks/latest/userguide/layers.html

AWS Beanstalk: il s'agit de déployer et de gérer des applications dans le cloud AWS sans se soucier de l'infrastructure qui exécute vos applications Web avec Elastic Beanstalk. Pas besoin de vous soucier des installations EC2 ou autres.

AWS OpsWorks AWS OpsWorks n'est rien d'autre qu'un service de gestion d'applications qui permet aux nouveaux utilisateurs DevOps de modéliser et de gérer facilement l'ensemble de leur application

AWS CloudFormation - Créez et mettez à jour vos environnements.

AWS Opsworks - Gérez vos systèmes dans ces environnements comme nous le faisons avec Chef ou Puppet

AWS Beanstalk - Créer, gérer et déployer.

Mais personnellement, j'aime CloudFormation et OpsWorks en utilisant toute sa puissance pour ce à quoi ils sont destinés.

Utilisez CloudFormation pour créer votre environnement, puis vous pouvez appeler Opsworks à partir de scripts de formation cloud pour lancer votre machine. Ensuite, vous aurez la pile Opsworks pour le gérer. Par exemple, ajoutez un utilisateur dans Linux Box en utilisant Opsworks ou appliquez des correctifs à vos boîtes en utilisant des recettes de chef. Vous pouvez également écrire des recettes de chef pour le déploiement. Sinon, vous pouvez utiliser CodeDeploy spécialement conçu pour le déploiement.

AWS OpsWorks - Cela fait partie du service de gestion AWS. Cela aide à configurer l'application à l'aide de scripts. Il utilise Chef comme framework devops pour cette gestion et cette opération d'application. Il existe des modèles qui peuvent être utilisés pour la configuration du serveur, de la base de données, du stockage. Les modèles peuvent également être personnalisés pour effectuer toute autre tâche. Les ingénieurs DevOps contrôlent les dépendances et l'infrastructure des applications.

AWS Beanstalk - Il fournit l'environnement pour des langages tels que Java, Node Js, Python, Ruby Go. Elastic Bean stalk fournit la ressource pour exécuter l'application. Les développeurs ne doivent pas se soucier de l'infrastructure et ils n'ont pas de contrôle sur l'infrastructure.

AWS CloudFormation - CloudFormation propose des exemples de modèles pour gérer les ressources AWS dans l'ordre.

Comme beaucoup d'autres l'ont commenté, AWS Beanstalk, AWS OpsWorks et AWS Cloud Formation proposent différentes solutions pour différents problèmes.

Afin d'accomplir

I am interested in a system that can be auto scaled to handle any high number of simultaneous web requests (From 1000 requests per minute to 10 million rpm.), including a database layer that can be auto scalable as well.

Et compte tenu du fait que vous êtes en cours de migration, je vous recommande vivement de commencer à jeter un œil à la solution AWS Lambda et AWS DynamoDB (ou hybride).

Les deux sont conçus pour une mise à l'échelle automatique de manière simple et peuvent être une solution très bon marché.

Utilisez simplement terraform et ECS ou EKS.

opsworks, beanstalk élastique et cloudformation ancienne technologie maintenant. -)