Dockerは私のユースケースに適していますか？

私の会社には、基本的にUbuntu 12.04を実行しているミニコンピューター「Smartbox」で構成されるシステムがあります。このボックスは、Djangoアプリケーションとそれに関連するいくつかの異なる起動プロセスを実行します。他にあまりない。私たちはこれらの箱をフィールドに何千も持っています。パッケージの依存関係、プロセスの登録などを、debパッケージを介して管理しますが、成功の度合いはさまざまです。

現場でユーザーに更新を効率的かつ堅牢にプッシュする方法が必要です。また、OSをアップグレードするときに（おわかりのようにUbuntuのアップグレードが遅れているので）、パッケージが "正常に動作している"ことについて比較的安心できることも必要です。

私はDockerについてあまり知りませんが、私たちの問題について初めて聞いたとき（私は新入社員です）、Dockerが私の最初の考えでした。しかし、それについて考えれば考えるほど、そうではないのではないかと感じました。これらのボックスは、Dockerの価値提案の大きな部分であるOSを制御する私たちのものだからです。それで、ボックスが常にUbuntuであり、基本的にDjangoアプリと実行するいくつかのプロセスがあるだけだとしたら、Dockerはdebパッケージよりも優れているでしょうか？

TL; DR：常にUbuntuを実行する分散アプライアンスのDocker vs debパッケージ。プラットフォームの独立性はそれほど重要ではありません。

質問から私が100％確信しているわけではありませんが、Dockerソリューションは、OSとあなたのアプリがインストールされた（物理的な？）アプライアンスを持っていることから、OSとアプライアンスを持っていることになりますDockerで、アプリを含む単一のコンテナを実行します。これにより、ホストのOSを更新する必要がなくなり、複雑なレイヤーが追加されます（そして、Docker と OSにパッチを適用する必要があるため、より多くの更新に対処する必要があります）。質問で言及された特定の領域に関する限り。

ただし、仮想アプライアンスからDockerコンテナーに移行することについて話している場合は、潜在的に問題を解決できますが、製品の依存関係としてDockerも追加されます。Dockerを使用しておらず、製品を使用するためだけにスタックに追加することを望まない人は誰も締め出しません。以前のように（現在の「レガシー」）仮想アプライアンスを出荷し続けることで、Dockerを使用しない/使用しないものを引き続きサポートできますが、サポートするディストリビューションが2つあるため、ワークロードが2倍になりました。 1。

私は長い間Dockerで働いてきました。プラットフォームの独立性は優れていますが、Dockerについて私が最も有用と考えるものではありません。

何よりもまず、再現性が得られます。Dockerfileを作成し、開発者のマシンのコンテナーでデバッグし、継続的インテグレーションサーバーでテストを実行してから、最終製品で実行すると、これらすべての環境で同じように動作します。開発者がマシンにインストールした依存関係を忘れないでください。また、開発者はデスクでUbuntuを使用する必要はありません。Arch Linuxユーザーを満足させるために重要です:-)

次に、アップグレードシナリオでは、複数のバージョンを一度にマシンにプルすることができます。その場合はdocker pull myapp:2.0しばらくは1.0実行されている、あなたはに交換することができ2.0、非常に素早く。通常、完全なOSアップグレードを実行するよりもはるかに高速です。オーケストレーターを複数のマイクロサービスインスタンスで使用する場合、サービスをまったく中断しないローリングアップグレードを行うこともできます。

マイクロサービスモデルを使用する場合、Dockerにはサンドボックスも用意されており、エクスプロイトが発生した場合に攻撃者が受けることができる損害の量を制限できます。マシン全体を制御する代わりに、1つのコンテナのみを制御します。

主な欠点は、ホストOSと何らかのオーケストレーションが必要なことです。それには多くの選択肢がありますが、評価し、適切な場所に置いて、それを維持するために必要な作業量を過小評価しないでください。

重複する小さなリージョンがいくつかありますが、DockerとDebianパッケージングシステムは、本質的に2つの非常に異なる問題を解決します。

• Debianパッケージングシステムは、ホストにソフトウェアをインストールし、できるだけ簡単にアップグレードできるように構築されています。「ソフトウェアXバージョンAにはバージョンB以降のソフトウェアYが必要」または「ソフトウェアXバージョンCにはソフトウェアXをインストールしない」など、ソフトウェアコンポーネント間の複雑な依存関係と制約パターンを処理できます。

• Dockerシステムは、サービス（特にマイクロサービス）を簡単に記述してデプロイし、おそらく複数のホスト（Docker swarmやKubernetesクラスターなど）に展開するように設計されています。

これら2つの問題は本質的に直交しています。つまり、解決する展開の問題を考えると、ソリューションの一部として、どちらか一方、または両方を使用できます。両方を使用する場合、DebianパッケージはDockerイメージの生成に使用され、Dockerfile（コンテナーで実行される「仮想化システム」を記述するDockerイメージの準備に使用されるレシピ）は、本質的にDebianリポジトリをDebianパッケージングシステムのソースとパッケージをインストールします。

これを念頭に置いて、あなたが本当に探しているのは不変のサーバーパターンを実装することです。クラウドテクノロジーの最近の開発により、ソフトウェアパッケージシステム（Debianパッケージシステムなど）から従来のソフトウェアアップグレードシステムを使用するのではなく、サーバー全体を一度に置き換えるだけでソフトウェアをアップグレードできるようになりました。（この開発の前に、サーバー上に3台のOSがあり、2台がアプライアンスを実行するために交互に使用され、ミニOSがアプライアンスの交換専用に使用されていました。過度に複雑ではありませんが、これは常に残っているようですニッチ。）この手法は、パッケージマネージャーを使用してサーバー上のソフトウェアをアップグレードするのに慣れている場合、サーバーの最終状態はサーバーの「アップグレード履歴」に依存するため、特にエラーが発生する場合、アップグレードプロセス。この不均一性は悪いです、

私たちはこれらの箱をフィールドに何千も持っています。パッケージの依存関係、プロセスの登録などを、debパッケージを介して管理しますが、成功の度合いはさまざまです。

これに関連する可能性があります。不変のサーバーパターンは、「アップグレード履歴」という概念を問題から本質的に破壊することにより、このエラーの原因を一掃します。

不変のサーバーパターンを実装するためのさまざまなオプションがあります。2つの一般的な選択肢は、Dockerイメージ、イメージを使用するか、クラウドプロバイダーの「マスターインスタンスイメージ」を使用することです（AWSではAMIと、Google Compute Engineでは単にカスタムイメージと呼ばれます） 。あなたのユースケースはクラウドベースのテクニックの使用を禁止しているので、Dockerイメージが唯一の適格な選択肢であると仮定します。（完了のために、Dockerの代替として、たとえばVirtual Boxまたは同様の仮想化ソリューションを使用するなど、他のアプローチを使用することは確かに可能です。）

不変のサーバーパターンテクニックを使用する場合、サーバーを表す新しいアーティファクト（Dockerイメージ）を導入し、このアーティファクトもテストできます。サービスの負荷を除いて、実稼働設定を忠実に複製するセットアップを簡単に取得できます。

さて、あなたが説明した具体的な問題を検討するために、Dockerで不変のサーバーパターンを実装することが実際に必要だと仮定しましょう。DockerシステムとDebianパッケージングシステムは相互に排他的ではなく補完的であるため（introを参照）、ソフトウェア用にDebianパッケージを準備する必要がある場合は、引き続き質問に対処する必要があります。

Debianパッケージを使用して（Dockerイメージまたはホストに）ソフトウェアをインストールすることの適切性は、解決しなければならないバージョン管理の問題の複雑さにあります。ソフトウェアの複数のバージョンを同時に実行し、時々ダウングレードする必要があり、慎重に文書化する必要がある複雑なバージョン要件がある場合、Debianパッケージを持っていることは必須です。それ以外の場合、この手順は省略できます。ただし、これらのパッケージを作成して展開するための努力を既に行っているため、作業を中止することに真の価値はありません。したがって、引き続きDebianパッケージを作成することをお勧めします。

Dockerは、社内のコンテナに変更を加えてテストし、その後リリースプロセスに応じて、コンテナを再起動して、テスト済みのアップグレードを提供する：latestまたは類似のものを常にプルできるので、合理的です。

コンテナは再起動時に変更を保持しないため、対処する必要がある考慮事項にはデータストレージが含まれるので、データボリュームが必要になります。掘り下げたら、おそらくもっと多くの考慮事項があるでしょう。私が現在作業しているシステム（すべてドッカーベース）は1年以上開発されており、コンテナ、構成などを変更する必要がある領域をまだ見つけています。

概して、ドッカーは開発者と運用担当者の両方に多くの利点を提供します。いくつかのアプリケーションでdockerを使用していますが、非常に信頼性が高く堅牢なアプローチであることがわかりました。

Dockerを採用しているあなたの私の問題は、あなたが正しい質問をするのを聞いていないことであり、あなたはあなたの最も重要な要件に対処せずにあなたの人生をより複雑にする可能性があります。

あなたが尋ねるべき最初の質問（あなたはあなたが新しいと言った）は、OSとアプリケーションの更新は今どのように扱われているのですか？現在の方法論はあなた（あなたの会社）に有効ですか？何がうまくいく？何を改善できますか？フィールド内のターゲットマシンで物理的な構成監査を行って、正しいOSパッチ、アプリケーションがあり、不正な変更があったことを確認できますか。

私は港湾労働者が大好きですが、何がうまくいくのか、何を改善する必要があるのか​​を含めて、あなたが今どこにいるのかを最初に評価せずに、港湾労働者の時流に飛び乗りません。

私はそれが良い選択肢だと思う（さらにテストが必要です）

作成したコンテナのすべてのタグ/バージョンをURLに指定すると、クライアントはそのURLを読み取って、コンテナの新しいバージョンがあるかどうかを確認します。

個人のファイル/設定をローカルに保存することができ、アップグレードでその情報を失うことはありません。また、作成およびテストした内容がすべての人に同じように機能することを確認します。

ユーザーに、使用可能なバージョンからどのバージョンを使用するかを選択できるようにすることもできます（その可能性を提供する場合）。

これは、「 "1つのパッケージのみをアップグレードする"」ようなもので、コンテナの新しいバージョンのみを取得することについて話します。debianパッケージを扱うよりもはるかに優れています;）