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に焼き付け、それらのAMIをLaunchConfigurationグループとAutoScalingグループに追加し、そのグループは必要に応じてインスタンスを起動していました。したがって、デプロイのために、古いec2インスタンスを破棄し、新しいインスタンスを起動します。Dockerを使用すると、これらのコンテナーはec2インスタンスで実行されるため、VMをスピンアップ/破棄する必要はありませんか、それともコンテナーを交換してVMを実行し続けるだけですか？
Docker環境の外で、RDS、Elasticache、およびその他のフルマネージドサービスを維持することは合理的です。はい、高可用性を実現するには、Dockerデーモンを実行している複数のEC2インスタンスが必要です。
本当の利点は、2つのEC2インスタンスがそれぞれで2つのWebサーバーDockerコンテナーを実行していることではありません。アプリケーションをマイクロサービスに分割すると、真の利点が得られます。マイクロサービスでは、複数のコンテナーを組み合わせてWebアプリケーションを構築し、マイクロサービスの利点を提供します。
それとは別に、DevOpsフローは、自動スケーリングと負荷分散を備えたEC2での従来のWebアプリケーションのデプロイとは異なり、多くの利点があります。たとえば、ソースコードにはコンテナコードも含まれます。これにより、ステージングと本番環境で環境が均一に機能することが保証されます。また、ソース管理のブランチ/タグを指す画像があり、新しいリリースの新しい更新（デルタダウンロード）を取得できます。
AWSでDockerをセットアップする場合は、管理オーバーヘッドを削減するためにAWSECSを使用することをお勧めします。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加