Dockerをデータベースに使用しない理由は何ですか？

私はDockerのユースケースについて友人と議論しています。チームの1人の男は、あらゆる種類のDockerを使用したいと考えています-ユニバーサルUNIXプロセスラッパーのようなもの。もう1人は、DockerはマイクロサービスやAWS Lambdaスタイルのアプリなどのステートレスアプリケーションにのみ使用すべきだと考えています。

両方の概念実証を設計しました。Dockerクラスターには、Dockerホストのマウント時にマウントされる共有ドライブがあり、コンテナー内のデータベースがマウントされている場合は、単に共有ドライブにボリュームをマウントします。

私の友人は、相反する証拠を見せられたにもかかわらず、彼の立場に固執しています。（彼はまた、Dockerがスタックに複雑さを追加することで不必要なリスクを追加すると主張しています。）

私は彼の視点を聞いて理解しようとしています。共感の行為だけでなく、彼とのより良い理由にも。（私たちは皆、非常にうまくやっています-それで、これはインジェストと真剣な議論の混合です）。

質問の背後にある質問の種類は次のとおりです。データベースは牛ですか？このコメントは、データベースの適切な自動化されたバックアップおよび取得戦略が、牛サーバーと見分けがつかないことを示唆しています。

私の質問は、Dockerをデータベースに使用すべきでない理由は何ですか？

編集： 人々は私の用語を明確にするように私に頼みました。データベースアプリケーションはコンテナにあり、ストレージはボリュームにあると想定していました。つまり、RDBMSはコンテナ内にあり、データベースストレージはボリューム内にあります。

一部のコメンテーターは、ドッカーボリュームドライバーがデータベースの書き込みでうまく機能しないことを示唆しています。（またはその効果をもたらすもの）。それについて詳しく説明していただけますか？

Dockerでデータベースを実行することについて話すとき、コンテナにデータを保存することを意味しません。DBソフトウェアでdockerイメージを使用し、データをボリューム（コンテナボリュームではなくバインドボリューム）としてマウントすることについて話している。

ボリュームはDockerの重要な部分であり、不安定なものでも、単に付け加えられたものでもありません。Dockerは、ステートレス（マイクロ）サービス専用ではありません。

Dockerでデータベースを実行しない技術的な理由を見つけることはできませんが、残念ながら引数の反対側を選択するため、探している答えが得られない可能性があります。

（私はOracleを例として使用していますが、これはベアメタルとドッカー化の両方に精通しているため、デフォルト設定を超えて操作するのが少し自明でないことで非常に悪名高い獣だからです。）

• DBソフトウェア自体をコンテナにパッケージ化すると、通常の利点が得られます。どこにでも同じバージョンを持ち、依存関係/共有ライブラリの問題を回避し、開発者のラップトップまたは必要な場所でまったく同じDBをスピンアップできます。
• どこでも実行するのは簡単です。更新は簡単です。すべてのDockerの利点が適用されます。DockerhubにはOracleのイメージがあり、1〜3分で作業DBを起動できます（もちろん、他のデータベースも同様です）。
• 人々はパフォーマンステストを行いましたし、ボリュームとベアメタルの間にはI / Oの違いは認められなかった（https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/、https：//でのstackoverflow .com / questions / 21889053 / what-is-the-runtime-performance-cost-of-a-docker-container）。
• とにかく、Dockerが何らかの方法ですべてのI / Oをインターセプトするわけではありません。標準のLinuxツール（この場合はマウントをバインドし、Docker-fuをまったく可能にする内部カーネルテーブルをマングリング）で創造的になります。
• 明らかに、これは、DBの2つのインスタンスを実行し、それらを同じファイルで動作させることができるという意味ではありませんが、それを暗示している人はいません。Dockerは、ボリュームへの同時かつ魔法のような自動アクセスを自動的に提供するものではありません。残りの利点は引き続き適用されます。DB自体がこのような競合を検出しない場合は、ボリュームが既に使用されているときに2番目のコンテナーのスピンアップを拒否するCMDスクリプトをイメージに提供する方が適切です。
• コンテナのスピンアップ/シャットダウンにはもう少し注意する必要があります（単にベアメタルDBサーバーのスイッチをオフにするのと同じように）が、これは非常に管理しやすいものです。

現在、状況に応じて、それをしないソフトな理由があるかもしれません：

• たとえば、Oracle（会社）は、DockerコンテナでRDBMSを実行する場合、確実にサポートしません。ただし、開発者とテスト環境でのみドッキングされたOracle RDBMSイメージを使用している場合、ベアメタルプロダクションサーバー用に予約する必要があります。（ただし、ライセンスを支払うことを忘れないでください...）。
• 運用担当者がDockerに慣れていない場合、誤ってすべてを削除したり、データファイルを破壊したりするのは少し簡単かもしれません。
• あなたは非常に高速な専用のSANストレージの大容量で、すでに大きな専用金属DBマシンを持っているし、とにかく何も実行しない場合は、ちょうどcontainerizeするドッカーを使用しても意味がないのでしょう、それらをあなたがされますよう決してときそこだけ別のサーバをスピンアップしません数百GBまたはTBのデータです。結局のところ、本番環境では、OracleのようなRDBMSは、すべてのレプリケーション、データ統合、ダウンタイムなしのフェイルオーバーなどの面で非常に高度です。この引数は、「RDBMSをコンテナ化する必要はない」というだけであることに注意してください。「やるべきではない」とは書かれていません-コンテナを通じて、または想像できる他の理由でデータベースソフトウェアのアップグレードを展開したいので、それをしたいかもしれません。

それであなたは行き​​ます。すべての手段によってん（永遠に感謝するでしょう）、あなたの開発者とあなたのテスト環境のために非常に少なくとも、あなたのDBをdockerize。生産では、それが味に降りてくるだろう、とそこ少なくとも、私はまた、専門のDBA /オプスで最高の座っているソリューションを好むだろう-彼らはベアメタルDBサーバの作業数十年の経験を持っている場合は、すべての手段によってそれらを信頼しますそう続けるために。しかし、とにかくすべてのITがクラウドにあるスタートアップの場合、Dockerコンテナーは全体像のたった1つのタマネギになります。

これについては詳細に書きましたが、概要は次のとおりです。

• スプリットブレインの防止（複数のマスターノードの選択）を解決する必要があります。そうしないと壊滅的なことができます

• すべてのデータを失うことなく、あるインスタンスでデータベースをシャットダウンし、別のインスタンスで起動できるようにする本番用の共有ストレージソリューションはありません。

データがdockerコンテナーにマウントされていると言うとき、「データベース」がdockerコンテナーにマウントされていると言うのはより正確ではないでしょうか？コンテナの外部でデータを永続化している場合、データベースをコンテナに入れないという「正しい」ことをしています。

確かに、DBMSをコンテナに入れて、外部に保存するデータを管理できるようにしてください。個人的には、ロジックとデータを完全に分離できるので、これは良い設計だと思います。ただし、データをコンテナに格納すると、潜在的に火事になります。

コンテナーストレージドライバーは長い道のりを歩んできましたが、個人的にはまだデータに飛び込んでコンテナー内にデータを絡ませようとはしていません。