Je suis fan d'Heroku depuis ses débuts. Mais j'aime le fait qu'AWS Elastic Beanstalk vous donne plus de contrôle sur les caractéristiques des instances. Une chose que j'aime chez Heroku, c'est le fait que je peux déployer une application sans me soucier de la gérer. Je suppose que Heroku s'assure que toutes les mises à jour de sécurité du système d'exploitation sont appliquées en temps opportun. Je dois juste m'assurer que mon application est sécurisée.

Mes premières recherches sur Beanstalk montrent que bien qu'il crée et configure les instances pour vous, il passe ensuite à un processus de gestion plus manuel. Les mises à jour de sécurité ne seront pas automatiquement appliquées aux instances. Il semble qu'il y ait deux domaines de préoccupation :

  • Nouvelles versions d'AMI - Au fur et à mesure que de nouvelles versions d'AMI arrivent, il semble que nous voudrions exécuter la dernière (probablement la plus sécurisée). Mais mes recherches semblent indiquer que vous devez lancer manuellement une nouvelle configuration pour voir la dernière version d'AMI, puis créer un nouvel environnement pour utiliser cette nouvelle version . Existe-t-il un meilleur moyen automatisé de faire pivoter vos instances dans de nouvelles versions d'AMI ?
  • Entre les versions, des mises à jour de sécurité seront publiées pour les packages. Il semble que nous souhaitions également les améliorer. Mes recherches semblent indiquer que les gens installent des commandes pour exécuter occasionnellement une mise à jour yum. Mais puisque de nouvelles instances sont créées/détruites en fonction de l'utilisation, il semble que les nouvelles instances n'auraient pas toujours les mises à jour (c'est-à-dire le temps entre la création de l'instance et la première mise à jour de yum). Donc, parfois, vous aurez des instances qui ne sont pas corrigées. Et vous aurez également des instances qui se corrigeront constamment jusqu'à ce que la nouvelle version de l'AMI soit appliquée. Mon autre préoccupation est que ces mises à jour de sécurité n'ont peut-être pas été examinées par Amazon (comme le font les versions AMI) et que cela pourrait casser mon application pour les mettre à jour automatiquement. Je sais que Dreamhost a déjà eu une panne de 12 heures parce qu'ils appliquaient les mises à jour de Debian de manière entièrement automatique sans aucune révision. Je veux m'assurer que la même chose ne m'arrive pas.

Ma question est donc la suivante : Amazon fournit-il un moyen d'offrir un PaaS entièrement géré comme Heroku ? Ou AWS Elastic Beanstalk est-il vraiment plus qu'un simple script d'installation et après cela, vous êtes seul (à part les outils de surveillance et de déploiement qu'ils fournissent) ?

answer

Tout d'abord, pour être clair, aucun Elastic Beanstalk n'est pas PaaS dans la façon dont vous le pensez. Si vous le divisez en morceaux, cela ressemble plus à des modèles d'instance virtualisés et à une automatisation du déploiement d'applications comme Puppet ou Chef. Parallèlement à cela, vous bénéficiez d'un accès automatisé au service d'équilibrage de charge d'awe et à la surveillance de la surveillance du cloud, qui vous permet de démarrer de nouveaux serveurs d'applications ou d'arrêter ceux existants en fonction de métriques.

Ce qui donne l'impression que PaaS est que le principal argument de vente est le système de déploiement d'applications qui prend votre code et le copie sur tous les serveurs d'applications de votre cluster.

L'une des plaintes que certaines personnes ont au sujet du PaaS est que le fournisseur de PaaS prend des décisions à votre place concernant l'environnement d'application. Cela me semble être la proposition de valeur du PaaS : en tant que client, vous pouvez vous concentrer sur les fonctionnalités de l'application et laisser tous les autres détails au fournisseur de PaaS. Vous payez quelqu'un d'autre pour gérer l'infrastructure et assurer l'administration du système. Pour cette simplicité, vous leur payez une prime, comme dans le cas de Heroku, qui exécute également son infrastructure sur ec2, uniquement d'une manière transparente pour vous.

Amazon propose vraiment Elastic Beanstalk en plus d'Ec2 et de leurs API REST, et ne fait pas beaucoup d'efforts pour vous le cacher. En effet, ils gagnent leur argent via IaaS, et EB orchestre simplement la configuration d'un groupe de ressources ec2 que vous pourriez configurer vous-même, compte tenu du temps et du savoir-faire.

Maintenant, en ce qui concerne les spécificités d'une AMI, encore une fois, les AMI sont l'une des nombreuses pièces ec2 utilisées pour faciliter l'EB. Il n'y a rien de magique dans une AMI EB - c'est juste une amie Amazon Linux préconfigurée pour fonctionner avec EB. Comme toute autre AMI, vous pouvez la démarrer dans EC2, la modifier et dériver une nouvelle AMI personnalisée à partir de votre instance en cours d'exécution. Amazon Linux est essentiellement un croisement entre Centos et Fedora, avec des correctifs de paravirtualisation et des dépôts yum préconfigurés gérés par Amazon.

Comme vous le savez probablement, Amazon Linux est déjà configuré pour installer des correctifs de sécurité au démarrage. Cependant, les instances en cours d'exécution ne sont pas différentes de tout autre serveur en ce qui concerne les correctifs. L'application de correctifs peut interrompre le service. Si vous êtes extrêmement préoccupé par les correctifs de sécurité, vous pouvez toujours utiliser une commande de conteneur et configurer cron pour exécuter yum update --security à une certaine périodicité.

Vous pouvez également utiliser l'API EB pour modifier la configuration EB ou automatiser la création d'un nouvel environnement EB, vous pouvez ensuite y accéder une fois qu'il est prêt, puis fermer l'ancien. Ceci est décrit ici : http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

Comme le reste d'AWS, il existe un moyen d'accéder et de contrôler par programmation toutes les fonctionnalités non SaaS, donc rien ne vous empêche de créer des AMI corrigées, qui sont ensuite utilisées pour créer de nouveaux environnements EB et les déployer. EB ne va pas vous imposer des spécificités de configuration et ne vous fournira pas non plus un groupe d'administration système pour maintenir l'infrastructure.

Depuis avril 2016, Elastic Beanstalk prend en charge les mises à jour automatiques de la plate-forme :

https://aws.amazon.com/about-aws/whats-new/2016/04/aws-elastic-beanstalk-introduces-managed-platform-updates/

Toutes les applications et environnements Beanstalk peuvent être configurés via des fichiers EBEXTENSIONS qui sont fournis avec votre package de déploiement d'applications (par exemple, un fichier WAR pour les applications Java) avec une configuration basée sur YAML pour mettre à jour ou reconfigurer n'importe quelle partie de votre application, conteneur, système d'exploitation, etc. PaaS car il s'agit d'une plate-forme qui vous permet de déployer des applications sans avoir à vous soucier de l'IaaS sous-jacent. En fin de compte, tous les fournisseurs de PaaS masquent l'IaaS sous-jacent grâce à une forme d'automatisation. Cependant, étant donné qu'il s'agit d'informatique, il n'existe pas d'état optimal unique pour toutes les applications et sans la possibilité de modifier l'IaaS sous le PaaS, vous êtes à la merci du fournisseur de services PaaS pour vous assurer que vos applications fonctionnent correctement, rapide et en toute sécurité.

Heroku s'exécute sur AWS en utilisant une couche de gestion différente, c'est tout. Cependant, cela devient un casse-tête lorsque vous devez faire des choses comme sécuriser votre application. Bien qu'ils fassent de leur mieux pour gérer efficacement leur solution et maintenir la sécurité, etc., ils ne peuvent pas et n'accepteront pas le risque et les conséquences d'une vulnérabilité dans votre application à la fin de la journée. Ils veulent rendre leurs services aussi simples que possible.

La capacité de modifier l'IaaS sous-jacent à la plate-forme est une force et un attrait de Beanstalk IMO.