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とは異なります。それをバラバラに分解すると、仮想化されたインスタンステンプレートや、人形やシェフなどのアプリケーションデプロイメントの自動化に似ています。これに加えて、畏敬のロードバランサーサービスとクラウドウォッチモニタリングへの自動アクセスが提供され、メトリックに基づいて新しいアプリケーションサーバーを起動したり、既存のサーバーをシャットダウンしたりできます。
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環境の作成を自動化したり、準備が整ったらそれに交換したり、古い環境をシャットダウンしたりできます。これはここで説明されています： http://docs.aws.Amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html
AWSの他の部分と同様に、SaaS以外のすべての機能にプログラムでアクセスして制御する方法があります。そのため、パッチが適用されたAMIの作成を妨げるものはなく、それを使用して新しいEB環境を作成します。 EBが構成の詳細を強制することも、インフラストラクチャを維持するためのシステム管理グループを提供することもありません。
2016年4月の時点で、Elastic Beanstalkは自動プラットフォーム更新をサポートしています。
すべてのBeanstalkアプリケーションと環境は、アプリケーションデプロイメントパッケージ（Javaアプリ用のWARファイル）など）と一緒にパッケージ化されたEBEXTENSIONSファイルを使用して構成でき、アプリケーション、コンテナー、OSなど。Beanstalkは、基盤となるIaaSを気にすることなくアプリケーションをデプロイできるプラットフォームであるため、PaaSです。1日の終わりに、すべてのPaaSプロバイダーは、何らかの形の自動化を通じて基盤となるIaaSを難読化します。ただし、これはコンピューターサイエンスであるため、すべてのアプリケーションに単一の最適な状態は存在せず、PaaSの下でIaaSを微調整する機能がないため、アプリケーションがスムーズに高速で実行されることを保証するために、PaaSサービスプロバイダーの判断が必要です。そして安全に。
Herokuは、AWSの上で、すべて異なる別の管理レイヤーを使用して実行されます。ただし、アプリケーションのセキュリティ保護などを行う必要がある場合は、お尻の痛みになります。彼らはソリューションを効率的に管理し、セキュリティなどを維持するために最善の努力をしますが、結局のところ、アプリの脆弱性のリスクと結果を受け入れることはできません。彼らは彼らのサービスを可能な限りクッキーカッターにしたいと考えています。
プラットフォームの基礎となるIaaSを調整する機能は、Beanstalk IMOの強みであり魅力です。