debパッケージを、アプリケーションを展開するコンテナであるかのように使用することの欠点はありますか？

私のチームは現在、NodekerアプリをDockerなどのコンテナーで実行するのではなく、debパッケージとして展開するかどうかを決定しようとしています。

私はこのブログ読んでからこのアイデアを得た、ここで既存のPythonアプリケーション用のdebパッケージを使用するためのいくつかの良い引数になります。私たちにとって魅力的なこのブログの主なポイントは、Dockerエコシステムの維持の問題です（ポート共有、アクセス許可、Dockerイメージのホスティングなど）。

「元のコンテナとしてのdep-packages」は、ポートの競合の心配がなく、すべての依存関係が仮想環境内で維持される小規模なサービスにとって非常に理にかなっているようです。

しかし、私の腸は、debパッケージが適切であれば、より一般的であり、ドッカーはより言語固有のソリューションとして宣伝されるだろうと言っています。Dockerなどのフルシステムを使用する代わりに、debパッケージなどを使用してサービスを展開することの欠点はありますか？

まず、Dockerはアドホックパッケージシステムとして見られ、使用されることもありますが、実際にはまったく異なる問題を解決します。Dockerはプログラムの実行に関するものです。ドッカーシステムを記述することを可能にするサービスことができるスケーリング自由にし且つ制御するために、群れの容器を。Debianパッケージはプログラムをインストールするためのもので、ソフトウェアバージョン間の依存関係を処理できます。 Docker 確かに、下降パッケージングシステムとしての資格はありません。各「パッケージ」は1つの依存関係のみを持つことができ、システムには「再帰ビルド」オプションがなく、複雑なバージョン制約をサポートしません！

可能な答えは、アプリケーション用のDebianパッケージを作成する場合は、Dockerを使用してアプリケーションをデプロイすることもできます。これは、次のような構成スクリプトapt_setup.shで実現できます。

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

とDockerfileの線に沿って

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

（特定の状況ではapt_setup.sh、nodesourceリポジトリとapt-transport-httpsなどのヘルパーパッケージを追加して、より複雑になります。）

したがって、DebianパッケージとDockerを同時に使用することは本当に可能ですが…

私の直感[…]は、debパッケージが適切であれば、より一般的だと言っています。

これは、Dockerがアドホックパッケージシステムとして人気があることを証明しているのに、なぜそうなるのではないのかを自分自身に問う正しいヒッチです。（上記を参照。）

特定のディストリビューションの「公式の」パッケージングシステムは、他の多くのユーザーの間で、一部のコンピューティング環境にソフトウェアをインストールする可能性にすぎません。npmやopamなどのコミュニティ固有のパッケージマネージャー、pkgsrcなどのポートツリー、プレーンなソースコード配布など、他にも多くのソースが利用可能です。この観点から、アドホックパッケージシステムとしてのDockerの成功を理解するのは簡単です。

• Dockerの仕様はシェルスクリプトに非常に近く、ソースが何であれ、シェルを使用してソフトウェアをインストールします。

• Dockerには、生成するアーティファクトをホストするDocker Hubという「組み込み」（有料）サービスがあります。

今の強さ何Debianパッケージは、上ドッカー画像パッケージシステムとして？インストール時の依存関係の厳密な制御。（アップグレードとダウングレードの可能性もありますが、不変サーバーパターンを実装している場合、実用的な重要性はありません。）これは、

結論

単一のバージョン（SaaSで一般的）に単一の製品のみがデプロイされている場合、バージョン管理のニーズは非常に単純であり、アドホックパッケージマネージャーとしてDockerを使用することには大きな欠点はありません。単一の製品または複数の製品の複数のバージョンを使用するとすぐに、解決する必要があるバージョン制約の問題の複雑さが増し、このための適切なツールが必要になります。Debianパッケージまたは構成管理システム異なる起源のソフトウェアをミキシング。

はい、欠点があります。

.debパッケージを使用すると、同じホスト上で同じアプリケーションの2つのバージョンを使用できなくなります。たとえば、アプリがnodejsに依存している場合は、配布バージョンにとらわれるか、独自のパッケージをインストールする必要があります。配布可能なパッケージに依存する必要があります。

同じホスト上で複数のアプリケーションをホストする場合、2つの異なるバージョンで同じものに依存している場合（ここではnodejsを保持しましょう）、非常に迅速に壁にぶつかります。

Dockerの主な目的は、各アプリケーションをホスティングシステムや同じホスト上の他のアプリケーションから分離することです。この分離を行う理由は2つあります。1。アプリの妥協を回避してホストを引き継ぐか、別のアプリケーションに影響を与えるため。依存。

アプリケーションをインストールするためのDebian（またはRedHat）パッケージは、正しく行われた場合の良い習慣です。パッケージは、まれにしか変更されないアプリケーションをデプロイする目的で使用されます。Debianパッケージには、バージョン管理、依存関係管理、インストール前およびインストール後スクリプトなどのオーバーヘッドが伴います...

多くの場合、いくつかの古いバージョンから新しいバージョンにアップグレードするには、スクリプトの注意深い記述、バージョンの詳細への注意などが必要です。既存の状態を変更することは難しいためです。何も変更せずに、現在の状態を新しい状態に完全に置き換える方がはるかに簡単です。

構成が簡単になり、エラーが発生しにくくなるため、各展開の構成、依存関係、またはアプリケーションを完全に置き換えることを決定したら、ほとんどの組織は（まったく）まったく新しいVMまたはクラウドインスタンスに切り替えます。つまり、パッケージのインストールは「クリーンな」サーバーで行われ、サーバー上のファイルと構成を変更することはもう問題ではありません。

パッケージを作成し、突然変異の誤りと複雑さを理解していなかった開発者は、結果として非常に多くの困難に苦しみました。

VMの交換は、アプリケーションを交換するだけでよい場合に最適ではないため、軽量コンテナーが答えとして導入されました。Docker（または他のLWC）を使用すると、サーバー自体を置き換えることなく、すべての依存関係を含むユーザーベースを置き換えることができます。また、同じサーバー上で、依存関係の異なる同じアプリケーションの複数のバージョンをホストし、アップグレード時に着信ネットワークトラフィックのみを切り替えることもできます。ネットワークトラフィックをロールバック（青緑）に切り替えるだけでなく、パッケージを介して展開を管理する場合には非常に困難でした。

コンテナは、すべてのアプリケーションコード、依存関係、および構成をイメージにバンドルする方法を導入します。このイメージには、従来のオペレーティングシステムパッケージよりもはるかに優れた複数のプロパティがあります。たとえば、バージョン管理を有効にするタグがありますが、スペースも節約できるレイヤーもあります。レジストリを使用して、これらのイメージをサーバーおよび開発環境に簡単に出荷できます。また、これらのイメージは、ほぼすべての環境およびサーバーでコンテナーとして実行できます。これには、開発者のラップトップと実稼働環境が含まれます。繰り返しになりますが、VMやパッケージベースのバージョンのソフトウェアで行うのははるかに困難でした。開発者のラップトップで同じ画像をテストし、本番環境で同じビットとバイトを維持すると、多くの「

コンテナランタイムではなく、Dockerのイメージパッケージング部分について具体的に説明すると、いくつかのマイナービットがあります。最大のものはDockerイメージがchrootに似ていることです。これは、使用中のすべてのファイルを明示的にイメージに含める必要があるため、共有システムの状態に誤って依存することを防ぎます。他のパッケージとより密接に絡み合うことを期待するか、そうでなければ取得します。これにより、OpenSSLなど、複雑なC依存関係が知らない間にロードされることがあります。さらに、debパッケージを使用しても、Dockerのストレージシステムで共有ビットを重複排除しないでください。一部の人にとってはこれは良いことであり、I / Oパフォーマンスが向上し、動く部分が少なくなりますが、他の人にとっては問題になるかもしれません。