本番環境でデータベースをコンテナとして使用することをお勧めしますか？
製品にマイクロサービスアーキテクチャを使用しており、「サービスごとのデータベース」モデルを使用し、AWSなどのプロバイダーによってクラウドサーバーにデプロイすることを決定したとします。データベースを開発およびテスト環境のコンテナとして実行すると便利です。
しかし、本番環境でも同様に実装できます！もしそうなら、それはどれほど安全でしょうか？または、代わりにAWS RDS-DBとしてクラウドソリューションを使用するのが適切です!!
本番環境（オンプレミスのエンタープライズアプリケーション）でdbをコンテナー化します。多くの人が行います。これは完全に安定しており、展開が大幅に簡素化されています。もちろん、データベースはストレスを受けていません。数万人ではなく、数百人の同時ユーザーを扱っています。コンテナに十分なRAMがあり、よく監視されていることを確認するだけです。
VMのみをdb専用にする必要がある場合は、dockerをスキップします。
マイクロサービスにサービスごとのデータベースモデルを使用しているため、実稼働環境ではデータベースのAWS RDSインスタンスになります。次の2つのアプローチがあります。
単一のRDSインスタンスを作成し、同じRDSインスタンスで異なるサービスに異なるデータベースを使用できます。コストを大幅に節約できますが、データベース接続とRDSを選択する必要があることに基づいてデータベースにかかる負荷を処理する必要があります。 4xlargeなどのインスタンスタイプの場合、インスタンスタイプがより多くの接続を提供し、より多くのデータベースロードが効率的に処理できるようになります。
2番目のソリューションは複数のRDSインスタンスを作成することができ、RDSインスタンスの数は各サービスがそのデータベースに1つのRDSインスタンスを個別に使用するため、マイクロサービスの数に等しくなります。これは効果的なソリューションではなく、多くのコストがかかり、このソリューションAWS RDSインスタンスを十分に活用します。
以下のリンクによると、本番環境でデータベースコンテナを使用することはお勧めできません。しかし、私が経験したように。コンテナーをアプリから分離し、コンテナーを定期的に更新し、ネットワーク関連のものも管理する場合、問題はないようです。
リンク： https://www.quora.com/Is-it-not-advisable-to-use-database-in-Docker-container
この ブログ投稿 には、コンテナで本番データベースを実行しない理由がいくつかリストされています。また、 別のブログ投稿 dockerおよび不安定なストレージドライバーの更新に関する問題を説明しています。
ここでの主なポイントはこれに要約します：
危険なストレージドライバー。データベースの状態をホストシステムに書き込む場合、これはそれほど問題ではないかもしれませんが、たとえばDockerは、ユーザーがそのためにボリュームを使用することを明示的に奨励します（ docs ：Citation： "Volumes is best way Dockerでデータを保持する」）。通常の状況では正常に機能する場合がありますが、たとえば電源障害や読み取りエラーなどのエッジケースについてはどうでしょうか。
実稼働環境でのデータベースの管理は困難です。多くの企業がフルタイムのDBAを採用して、運用データベースの円滑な運用を確保しています。 devopsパラダイム（すべての開発者がコンテナに多数のDBサーバーを作成する）により、DBAが仕事をすることはほぼ不可能になります。これは、DBAがこれらのDBにアクセスできる場合です。
結論として、コンテナは特定のタスクには適していますが、他のタスクには悪い考えです。実稼働データベースをコンテナで実行することは、これらの悪いアイデアの1つです。