AWS Elastic Beanstalkのセキュリティ更新を自動的に適用する

私はHerokuがまだ初期の頃からファンでした。ただし、AWS Elastic Beanstalkを使用すると、インスタンスの特性をより詳細に制御できるという事実が気に入っています。Herokuで気に入っていることの1つは、アプリをデプロイでき、管理する必要がないことです。私は仮定して Herokuのは、すべてのOSのセキュリティアップデートが適時に適用されている保証することです。アプリが安全であることを確認するだけです。

Beanstalkに関する私の最初の調査では、インスタンスを構築および構成しますが、その後、より手動の管理プロセスに移行することが示されています。セキュリティ更新プログラムは、インスタンスに自動的に適用されません。2つの懸念領域があるようです。

• 新しいAMIリリース-新しいAMIリリースがヒットすると、最新の（おそらく最も安全な）を実行したいと思われます。しかし、私の調査では、最新のAMIバージョンを表示するには新しいセットアップを手動で起動し、その新しいバージョンを使用する新しい環境を作成する必要があることが示されているようです。インスタンスを新しいAMIリリースにローテーションするより良い自動化された方法はありますか？
• リリースの間に、パッケージのセキュリティ更新プログラムがリリースされます。それらも同様にアップグレードしたいようです。私の調査では、人々がコマンドをインストールしてyumアップデートを時々実行することを示しているようです。ただし、新しいインスタンスは使用法に基づいて作成/破棄されるため、新しいインスタンスには常に更新があるとは限りません（つまり、インスタンスの作成から最初のyum更新までの時間）。そのため、パッチが適用されていないインスタンスが存在する場合があります。また、新しいAMIリリースが適用されるまで、インスタンスに絶えずパッチを適用します。私のもう1つの懸念は、おそらくこれらのセキュリティ更新プログラムはAmazonのレビューを経ていない（AMIリリースのように）ため、アプリが自動的に更新されない可能性があることです。Dreamhostは、レビューなしで完全に自動的にdebianアップデートを適用していたため、12時間の停止があったことを知っています。同じことが私に起こらないようにしたい。

私の質問は、AmazonはHerokuのような完全に管理されたPaaSを提供する方法を提供していますか？または、AWS Elastic Beanstalkは実際には単なるインストールスクリプトに過ぎず、その後は自分で（監視ツールとデプロイツールが提供するものを除いて）自分自身になりますか？

最初に、明確にするために、Elastic Beanstalkはあなたが考えている方法ではPaaSではありません。細かく分割すると、仮想化されたインスタンステンプレートと、人形やシェフのようなアプリケーションの展開の自動化に似ています。これに加えて、メトリックに基づいて新しいアプリケーションサーバーを起動したり、既存のサーバーをシャットダウンしたりできるa敬のロードバランサーサービスおよびクラウドウォッチモニタリングへの自動アクセスを取得します。

PaaSのように感じるのは、主なセールスポイントは、コードを取得してクラスター内のすべてのアプリケーションサーバーにコピーするアプリケーションデプロイメントシステムであるということです。

一部の人々がPaaSについて抱えている不満の1つは、PaaSベンダーがアプリケーション環境について決定することです。これは、PaaSの価値提案のように思えます。顧客として、アプリケーションの機能に集中し、他のすべての詳細をPaaSベンダーに任せることができます。インフラストラクチャを管理し、システム管理を提供するために他の誰かにお金を払っています。その単純さのために、ec2の上でインフラストラクチャを実行しているHerokuの場合のように、それらにプレミアムを支払っています。

Amazonは、Ec2およびそのREST APIの上にElastic Beanstalkを実際に提供しており、それをユーザーから隠す努力をあまりしていません。これは、彼らがIaaSを介してお金を稼いでおり、EBが、時間と方法を考慮して、自分でセットアップできるec2リソースのグループのセットアップを調整しているからです。

現在、AMIの詳細に関しては、AMIもEBを促進するために採用されている多くのec2ピースの1つです。EB AMIには魔法のようなものはありません-EBで動作するように事前設定されたAmazon linux amiにすぎません。他のAMIと同様に、EC2で起動し、微調整して、実行中のインスタンスから新しいカスタマイズされたAMIを取得できます。Amazon Linuxは基本的に、CentosとFedoraのクロスであり、準仮想化パッチと、Amazonが管理する事前構成されたyumリポジトリを備えています。

おそらくご存知のように、Amazon linuxはすでにブート時にセキュリティパッチをインストールするように設定されています。ただし、実行中のインスタンスは、パッチ適用に関して他のサーバーと変わりません。パッチを適用すると、サービスが中断される場合があります。セキュリティのパッチ適用を非常に心配している場合は、コンテナコマンドを使用してcronを設定し、定期的にyum update --securityを実行できます。

EB APIを利用してEB構成を変更したり、新しいEB環境の作成を自動化したり、準備ができてから古いEB環境をシャットダウンした後、その環境に切り替えることができます。これについては、http：//docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.htmlで説明しています。

AWSの他の部分と同様に、SaaS以外のすべての機能をプログラムでアクセスおよび制御する方法があるため、パッチを適用したAMIを作成し、それを使用して新しいEB環境を作成し、展開することを妨げるものは何もありません。EBは、構成の詳細を強制することも、インフラストラクチャを維持するためのシステム管理グループを提供することもありません。

2016年4月現在、Elastic Beanstalkは自動プラットフォーム更新をサポートしています。

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

すべてのBeanstalkアプリケーションと環境は、アプリケーション、パッケージ、OSなどの一部を更新または再構成するためのYAMLベースの構成で、アプリケーション展開パッケージ（JavaアプリのWARファイルなど）にパッケージ化されたEBEXTENSIONSファイルを介して構成できます。 PaaSは、基盤となるIaaSを心配することなくアプリケーションを展開できるプラットフォームであるためです。結局のところ、すべてのPaaSプロバイダーは、何らかの形の自動化を通じて基礎となるIaaSを難読化します。ただし、これはコンピューターサイエンスであるため、すべてのアプリケーションに最適な状態は存在せず、PaaSの下でIaaSを調整する能力がないため、ユーザーはPaaSサービスプロバイダーに頼って、アプリケーションがスムーズに実行されることを保証します。迅速かつ安全に。

Herokuは、すべて異なる管理レイヤーを使用して、AWS上で実行されます。ただし、アプリケーションの保護などを行う必要がある場合は、お尻の痛みになります。ソリューションを効率的に管理し、セキュリティなどを維持するために最善を尽くしていますが、1日の終わりにアプリの脆弱性のリスクと結果を引き受けることはできません。彼らはサービスを可能な限りクッキーカッターにすることを望んでいます。

プラットフォームの基礎となるIaaSを調整できることは、Beanstalk IMOの強みであり魅力です。