Elastic Beanstalk 環境のプラットフォームバージョンの更新 - AWS Elastic Beanstalk
方法 1 – 環境のプラットフォームバージョンを更新する方法 2 – Blue/Green デプロイを実行する

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Elastic Beanstalk 環境のプラットフォームバージョンの更新

Elastic Beanstalk は、新しいプラットフォームバージョンを定期的にリリースして、すべての Linux ベースおよび Windows Server ベースの プラットフォームを更新します。新しいプラットフォームバージョンは、既存のソフトウェアコンポーネントへの更新と、新しい機能および設定オプションのサポートを提供します。プラットフォームとプラットフォームバージョンの詳細については、「Elastic Beanstalk プラットフォームの用語集」を参照してください。

Elastic Beanstalk コンソールまたは EB CLI を使用して環境のプラットフォームバージョンを更新できます。更新先のプラットフォームバージョンに応じて、Elastic Beanstalk ではプラットフォームの更新を実行する 2 つの方法のいずれかを推奨します。

  • 方法 1 – 環境のプラットフォームバージョンを更新する。この方法は、同一のプラットフォームブランチ (同じランタイム、ウェブサーバー、アプリケーションサーバー、およびオペレーティングシステムを使用) の最新のプラットフォームバージョンに更新する場合で、メジャープラットフォームバージョンを変更しない場合にお勧めします。これは、最も一般的で定期的なプラットフォームの更新です。

  • 方法 2 – Blue/Green デプロイを実行する。この方法は、異なるプラットフォームブランチ (異なるランタイム、ウェブサーバー、アプリケーションサーバー、またはオペレーティングシステムを使用) のプラットフォームバージョンに更新する場合、または異なるメジャープラットフォームバージョンに更新する場合にお勧めします。これは、新しいランタイム機能や最新の Elastic Beanstalk 機能を利用する場合、あるいは非推奨または廃止されたプラットフォームブランチから移行する場合に適しています。

    Linux プラットフォームバージョンから移行するには、青/緑のデプロイが必要です。これらのプラットフォームバージョンは現在サポートされているバージョンと互換性がないためです。

    Amazon Linux 2 プラットフォームバージョンは、以前の Amazon Linux AMI プラットフォームバージョンと互換性がないため、Linux アプリケーションを Amazon Linux 2 に移行するには、Blue/Green デプロイが必要です。

プラットフォームの最適な更新方法の選択に関する詳細については、環境のプラットフォームに関するセクションを展開してください。

方法 1 を使用してプラットフォームの更新を行います。

方法 1 を使用してプラットフォームの更新を行います。

以下の場合を考慮します。

  • アプリケーションを別のプラットフォームに移行させる場合。例えば、Go 1.4 (Docker) から Go 1.11 に移行させたり、Python 3.4 (Docker) から Python 3.6 に移行させたりする場合は、方法 2 を使用します。

  • アプリケーションを別の Docker コンテナバージョンに移行させる場合。例えば、Glassfish 4.1 (Docker) から Glassfish 5.0 (Docker) に移行させる場合は、方法 2 を使用します。

  • 最新のプラットフォームバージョンに更新する際に、コンテナバージョンやメジャーバージョンの変更がない場合は、方法 1 を使用します。

方法 1 を使用してプラットフォームの更新を行います。

以下の場合を考慮します。

  • アプリケーションを別の Java ランタイムバージョンに移行させる場合。例えば、Java 7 から Java 8 に移行させる場合は、方法 2 を使用します。

  • 最新のプラットフォームバージョンに更新する際に、ランタイムバージョンの変更がない場合は、方法 1 を使用します。

以下の場合を考慮します。

  • アプリケーションを別の Java ランタイムバージョンまたは Tomcat アプリケーションサーバーバージョンに移行させる場合。例えば、Java 7 と Tomcat 7 から Java 8 と Tomcat 8.5 に移行させる場合は、方法 2 を使用します。

  • アプリケーションを Java と Tomcat のメジャープラットフォームバージョン (v1.x.x、v2.x.x、v3.x.x) 間で移行させる場合は、方法 2 を使用します。

  • 最新のプラットフォームバージョンに更新する際に、ランタイムバージョン、アプリケーションサーバーバージョン、またはメジャーバージョンに変更がない場合は、方法 1 を使用します。

以下の場合を考慮します。

  • アプリケーションを別の Windows オペレーティングシステムバージョンに移行させる場合。例えば、Windows Server 2008 R2 から Windows Server 2016 に移行させる場合は、方法 2 を使用します。

  • アプリケーションを Windows Server のメジャープラットフォームバージョン間で移行させる場合は、「Windows サーバープラットフォームの以前のメジャーバージョンからの移行」を参照し、方法 2 を使用します。

  • アプリケーションが現在 Windows Server プラットフォーム V2.x.x で実行されていて、最新のプラットフォームバージョンに更新する場合は、方法 1 を使用します。

注記

Windows Server プラットフォームバージョンが v2 より前である場合は、意味論的にバージョン管理されません。これらの Windows Server メジャープラットフォームバージョンについては、それぞれの最新バージョンのみを起動できます。また、アップグレード後のロールバックはできません。

方法 2 を使用してプラットフォームの更新を行います。

以下の場合を考慮します。

  • アプリケーションを別の PHP ランタイムバージョンに移行させる場合。例えばPHP 5.6 から PHP 7.2 に移行させる場合は、方法 2 を使用します。

  • アプリケーションを PHP のメジャープラットフォームバージョン (v1.x.x と v2.x.x) 間で移行させる場合は、方法 2 を使用します。

  • 最新のプラットフォームバージョンに更新する際に、ランタイムバージョンやメジャーバージョンの変更がない場合は、方法 1 を使用します。

以下の場合を考慮します。

  • アプリケーションを別の Python ランタイムバージョンに移行させる場合。例えば、Python 2.7 から Python 3.6 に移行させる場合は、方法 2 を使用します。

  • アプリケーションを Python のメジャープラットフォームバージョン (v1.x.x と v2.x.x) 間で移行させる場合は、方法 2 を使用します。

  • 最新のプラットフォームバージョンに更新する際に、ランタイムバージョンやメジャーバージョンの変更がない場合は、方法 1 を使用します。

以下の場合を考慮します。

  • アプリケーションを別の Ruby ランタイムバージョンまたはアプリケーションサーバーバージョンに移行させる場合。例えば、Ruby 2.3 と Puma から Ruby 2.6 と Puma に移行させる場合は、方法 2 を使用します。

  • アプリケーションを Ruby のメジャープラットフォームバージョン (v1.x.x と v2.x.x) 間で移行させる場合は、方法 2 を使用します。

  • 最新のプラットフォームバージョンに更新する際に、ランタイムバージョン、アプリケーションサーバーバージョン、またはメジャーバージョンに変更がない場合は、方法 1 を使用します。

方法 1 – 環境のプラットフォームバージョンを更新する

この方法を使用して、環境のプラットフォームブランチを最新バージョンに更新します。以前のプラットフォームバージョンを使用して環境を作成した場合や、古いバージョンから環境をアップグレードした場合は、この方法を使用して、同じプラットフォームブランチにある以前のプラットフォームバージョンに戻すこともできます。

環境のプラットフォームを更新するには

  1. Elastic Beanstalk コンソールを開き、[Regions] (リージョン) リストで AWS リージョンを選択します。

  2. ナビゲーションペインで、[環境] を選択し、リストから環境の名前を選択します。

    注記

    環境が多数ある場合は、検索バーを使用して環境リストをフィルタリングします。

  3. 環境の概要ページの [プラットフォーム] で、[変更] を選択します。

    Elastic Beanstalk の使用できる新しいプラットフォーム

  4. [プラットフォームのバージョンの更新] ダイアログで、プラットフォームのバージョンを選択します。ブランチ内の最新 (推奨) のプラットフォームバージョンが自動的に選択されます。過去に使用したことがあるどのバージョンにも更新できます。

    Elastic Beanstalk プラットフォームバージョン更新の確認

  5. [Save] を選択します。

さらにプラットフォームの更新を簡素化するために、Elastic Beanstalk で自動的に管理することもできます。環境を設定して、週ごとのメンテナンス時間にマイナーバージョンとパッチバージョンの更新が自動的に適用されるようできます。Elastic Beanstalk では、マネージド更新がダウンタイムや容量の減少なしに適用されます。また、この新バージョンでアプリケーションを実行しているインスタンスがヘルスチェックにパスしなかった場合、マネージド更新はすぐにキャンセルされます。詳細については、「マネージドプラットフォーム更新」を参照してください。

方法 2 – Blue/Green デプロイを実行する

この方法を使用して、異なるプラットフォームブランチ (異なるランタイム、ウェブサーバー、アプリケーションサーバー、またはオペレーティングシステムを使用)、または異なるメジャープラットフォームバージョンにアップデートします。これは、通常、新しいランタイム機能や最新の Elastic Beanstalk 機能を利用する場合に必要です。また、非推奨あるいは廃止されたプラットフォームブランチから移行する場合にも必要です。

メジャープラットフォームバージョン間で移行したり、コンポーネントのメジャー更新を伴うプラットフォームバージョンに移行したりする場合は、アプリケーションやその一部が新しいプラットフォームバージョンで正常に機能しないことがあり、変更が必要になる場合があります。

移行を実行する前に、ローカル開発マシンを、移行先のプラットフォームの最新のランタイムバージョンや他のコンポーネントに更新します。アプリケーションが正常に機能することを確認し、必要なコードの修正や変更を行います。次に、以下のベストプラクティス手順に従って環境を新しいプラットフォームバージョンに安全に移行させます。

メジャー更新を伴うプラットフォームバージョンに環境を移行させるには

  1. 新しいターゲットプラットフォームバージョンを使用して新しい環境を作成し、アプリケーションコードをその環境にデプロイします。新しい環境は、移行する環境がある Elastic Beanstalk アプリケーションに含まれている必要があります。既存の環境はまだ終了しないでください。

  2. アプリケーションコードを移行する先の新しい環境を使用します。特に、次のことに注意してください。

    • 開発フェーズで検出できなかったアプリケーションの互換性問題を見つけて修正します。

    • アプリケーションで設定ファイルを使用して行ったすべてのカスタマイズが新しい環境で正しく機能することを確認します。これには、オプション設定、追加でインストールしたパッケージ、カスタムセキュリティポリシー、環境インスタンスにインストールしたスクリプトや設定ファイルが含まれる場合があります。

    • アプリケーションでカスタム Amazon Machine Image (AMI) を使用している場合は、新しいプラットフォームバージョンの AMI に基づいて新しいカスタム AMI を作成します。詳細については、「Elastic Beanstalk 環境でのカスタム Amazon マシンイメージ (AMI) の使用」を参照してください。特に、これが必要となるのは、アプリケーションで使用している Windows Server プラットフォームに AMI が含まれていて、Windows Server V2 プラットフォームバージョンに移行する場合です。この場合は、「Windows サーバープラットフォームの以前のメジャーバージョンからの移行」も参照してください。

    新しい環境でアプリケーションが適切に動作することが確認されるまで、修正のテストとデプロイを繰り返します。

  3. CNAME を既存の本稼働環境の CNAME と交換することにより、新しい環境を本稼働環境に切り替えます。詳細については、「Elastic Beanstalk を使用したブルー/グリーンデプロイ」を参照してください。

  4. 本稼働環境の新しい環境の状態が適切であることを確認したら、古い環境を終了します。詳細については、「Elastic Beanstalk 環境を終了する」を参照してください。