![すでに仮想マシンがありますが、本番環境でDockerイメージを使用するのはなぜですか? [閉鎖]](https://linux33.com/image/176007/%E3%81%99%E3%81%A7%E3%81%AB%E4%BB%AE%E6%83%B3%E3%83%9E%E3%82%B7%E3%83%B3%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%81%8C%E3%80%81%E6%9C%AC%E7%95%AA%E7%92%B0%E5%A2%83%E3%81%A7Docker%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E3%81%AE%E3%81%AF%E3%81%AA%E3%81%9C%E3%81%A7%E3%81%99%E3%81%8B%EF%BC%9F%20%5B%E9%96%89%E9%8E%96%5D.png)
私はLinuxをサーバープラットフォームとして使用し、DigitalOceanなどのクラウドホスティングプロバイダーで本番アプリケーションを提供する最も効率的な方法を研究しています。 DigitalOceanはDropletsと呼ばれる仮想マシンを提供します。常識的に最善のアプローチは、提供されたVM(ドロップ)にあるままアプリケーションをデプロイすることです。 Dockerコンテナには間違いなくオーバーヘッドが発生するため、デプロイされたアプリケーションの応答時間が遅くなります。仮想マシン内でDockerコンテナを実行するためにクラウドホスティングプロバイダが最適化したものはありません。
Dockerコンテナと同じスクリプトを使用して仮想マシンを構成できることを考えると、本番環境でDockerを使用するのは妥当ですか?
答え1
Dockerエコシステムには、Dockerfileの仕様に従ってDockerコンテナを最初から(再)構築するための非常に便利なツールセットがあります。
アプリケーションのオーバーヘッドが重要ではない場合や、並列化によってアプリケーション設計を拡張できる場合でも、コンテナが提供する開発と保守の容易さのため、仮想マシン内でコンテナを使用することは依然として妥当です。より多くのパフォーマンスが必要な場合は、並列ノードを追加するだけです。
しかし、これは誰にとっても適切な解決策ではないかもしれません。必要に応じて、正しい種類の新しいVMを自動的に構築できるインフラストラクチャがすでにあり、それに満足している場合は、おそらくすでに同じ利便性を享受しています。 。あるいは、複数のインスタンスを並列に実行する必要がない場合、利便性の利点はそれほど大きくない可能性があります。
デフォルトでは、目標は本番アップデートを簡単に作成することです。 「VM/コンテナを停止し、古いコンテナを廃棄し、新しいVMイメージ/コンテナをその場所にデプロイしてから再起動します。必要に応じてVMに対してこれを繰り返します。同じアプリケーションを並列に実行するマシン/コンテナです。 」
Dockerコンテナなどの事実上の標準を使用すると、必要に応じてあるサービスプロバイダから別のサービスプロバイダに簡単に移動できます。 DigitalOceanドロップレットは、設計および最適化された開発インフラストラクチャを介して簡単に作成されますが、DigitalOceanから移行する場合は、一部の開発自動化を再構築する必要があります。
一方、シングルノードのパフォーマンスがアプリケーションの重要な要素である場合、正解はクラウドではなく、ある種の既存のホスティングまたはオンプレミスサーバーです。これはまた、アプリケーションが既存の単一サーバー設計をクラウドの世界に迅速に適用したことであり、可能であれば、スケーラビリティとマルチノード並列処理を利用するために、クラウドエコシステムに実際に合うようにいくつかの追加の設計作業が必要であることを示している可能性があります。 。
答え2
私は最近コンテナとドッカーを使い始めました。どこでもコンテナを実行でき、軽量アーキテクチャであり、仮想マシンよりも高速に起動できるため、より良い方法です。 Dockerハブから多くの画像をインポートしてインフラストラクチャを構築できます。たとえば、wordpresまたはLAMPを含むWebサーバーが必要な場合は、dockerハブにパブリックイメージをインストールするだけです。
次に、クバネティスの美しい世界について学びましょう。
この答えが役に立つことを願っています。