生産中のドッカーの理解

Question

私はDockerを使用して開発環境を構築する方法を学んできましたが、私は というアイデアがどのようにプロダクションスタックに変換されているのか興味があります。例として、MySQL、Redis、Nginxを使用するLaravel（Php）アプリケーションを持っています。

したがって、通常、AWSのロードバランサの背後に2つのアプリケーションec2インスタンスがあるとしましょう。 Dockerを使用して同様の生産状況を設定する場合...

1）私はRDSとElasticacheを使用しているため、それらのコンテナは必要ありません。だから、基本的に、idはPHP-FpmとNginxのコンテナしか必要ないのですか？

2）高可用性を得るためには、ELBの背後に2つ（または少なくとも1つ以上）のec2インスタンスがあります。だから私は、各インスタンスが上記のコンテナ（PHPとNginx）を実行すると思います。しかし、それは、各サーバがアプリケーションを提供するために必要なものを実行する、私の以前のVMセットアップと変わりません。それは正確ですか？

3）VMで、私は伝統的にAMIにコードを焼き付けて、Launch ConfigurationとAuto ScalingグループにそれらのAMIを追加し、そのグループは必要に応じてインスタンスをスピンアップします。展開のために、私は古いec2インスタンスを解体し、新しいインスタンスをスピンアップします。 Dockerでは、これらのコンテナはec2インスタンス上で実行されるため、VMをスピンアップ/ティアダウンする必要はありませんか、コンテナを置き換えてVMを実行し続けるのですか？

Answer 1

docker環境の外で、RDS、Elasticacheおよびその他の完全に管理されたサービスを維持するのが妥当です。はい、高可用性の場合、ドッカーデーモンを実行している複数のEC2インスタンスが必要です。

2つのEC2インスタンスがそれぞれ2つのWebサーバードッカーコンテナを実行しているのは本当の利点です。実際のメリットは、複数のコンテナを組み合わせてWebアプリケーションを構築して、benefits of microservicesを提供するマイクロサービスにアプリケーションを細分化するときです。

EC2の従来のWebアプリケーションのデプロイメントとは異なり、自動スケーリングとロードバランシングがあり、benefitsが多数あります。たとえば、ソースコードにはコンテナコードも含まれているため、ステージングとプロダクションで環境が一様に動作することが保証されます。また、ソースコントロールのブランチ/タグを指し示すイメージを持つことになります。これにより、新しいリリースの新しいアップデート（デルタダウンロード）が可能になります。

AWSでドッカーを設定する場合は、AWS ECSを使用して管理オーバーヘッドを削減することをお勧めします。

Answer 2

1. あなたはそうです。コードをコンテナで実行するだけで、リモートサービスにアクセスするだけです。考慮する必要があるのは、それらへの接続を確実にすることだけです。

2. もう一度やり直してください。以前と同じようにコードが動作するように、Dockerコンテナ内のVMに以前持っていたすべてのものを用意する必要があります。とにかく、Dockerコンテナでは、同じEC2インスタンス上で複数のアプリケーションインスタンスを実行することができます。もちろん、あなたのアプリケーションは同じポート上で実行しようとするので、ポートを管理するためにいくつかの追加のネットワークレイヤーが必要ですが、可能です。すべてのEC2インスタンスにドッカーがインストールされている必要があります。

3. AMIを作成してEC2インスタンスを閉じてスピンアップする代わりに、新しいDockerイメージをプルして新しいイメージでコンテナを再起動するだけで済みます。これは、EC2インスタンスフローの数分に比べてほんの数秒を意味します。これは、バギーデプロイを元に戻すことが本当に素早くできていることを意味し、0％のダウンタイムに達することができるセットアップの扉を開きます。