NodeJSアプリケーションのクラスターを実行しています。マイクロサービスとして実行されるため、非常に小さいはずです。 bcryptやimagemagickのような余分なものが必要なのはほんのわずかです-それは私にとって時々いくつかの問題を引き起こします。
現在、アプリをビルドするためのすべてのDockerfileのベースイメージとしてnode:10.13-Alpine
を使用しています。それらのいくつかについては、apk
などを介して依存関係を追加する必要があります。したがって、これらの画像は大きくなります。必要なパッケージ(python、gcc ...など)を追加することで大きくなるアルパインイメージを使用するのが最善のアプローチですか?または、完全な画像を使用する必要がありますか?
node:10.13
を使用すると、ベースイメージははるかに大きくなりますが、私の理解が正しければ、同じベースイメージが使用されるため、アプリケーションは小さなレイヤーのみを追加します。したがって、最後に1つの大きなノードイメージを使用する方がよいでしょうか?
他のパッケージは多くのライブラリを使用しているため、アルパインイメージは小さくなりますが、これらはソリューションでは使用されません。
小さな画像を使用する利点は何ですか?
利点は次のとおりです。メモリの削減、パフォーマンスの向上、セキュリティ、および保守性。
Dockerイメージを小さくすると、ディスクに必要なサイズが小さくなりますが、ディスク容量が安い。
さらに重要なのは、それも消費するメモリが少ないであり、これはすべてのサーバーで制限されています。サーバー上のベースイメージの量を減らすと、必要なメモリも少なくなります。メモリが少ないということは、スワッピングが少ないことも意味するため、すべてのベースイメージをメモリにロードすることでパフォーマンスが向上します。
もう1つの機能は、依存度の低いライブラリを使用するAlpineのベースイメージです。これにより、全体的なセキュリティが向上します。ベースのアルパイン画像と、本当に必要なapkのみを使用する上部の画像を使用して、リスクを簡単に分離できます。これには、全体的なメンテナンスに関しても利点があります。
https://hub.docker.com/r/library/node/tags/ で、Alpineバージョンには脆弱性がないことがわかります。他のすべてのイメージバージョンにはいくつかの問題があり、ソリューションのセキュリティをターゲットにしている可能性があります。
デフォルトがまだ「buildpack-deps」である理由と、おそらくそれらを使用する必要がある理由
ノードのDockerイメージの公式ドキュメントを読むと:
https://hub.docker.com/_/node/
主なポイントは次のとおりです。
私にとってこれは、「buildpack-deps」でビルドされた他のイメージを使用する場合、ほとんどの場合、通常のパッケージを使用できることを意味します。この場合、「buildpack-deps」の横に「Alpine」ベースイメージをディスクとメモリに保持する必要がないため、より良い解決策になる可能性があります。
結論
Docker環境に「Alpineイメージのみ」がある場合は、「Alpine」を使用するか、「ノード」コンテナーのセキュリティが非常に重要である場合に使用する必要があります。
「buildpack-deps」に基づく他のDockerコンテナがあるため、ほとんどの場合、「buildpack-deps」に基づく「ノード」イメージが適しています。
将来的には、「Alpine」に基づいて利用できるパッケージが増えると思います。その場合は、node-Alpineを使用する必要があります。
一般に、はい、アルパインイメージは公式ノードイメージよりも優れていますプリベイクされたバイナリが付属しています。
しかし、これは非常にケース固有です。
libpng16-dev
パッケージで一度発生し、公式ノードイメージでのみ機能し、何日も試してもノードAlpineで機能しなかった理由がわかりませんでした)。まとめると、複雑なセットアップがあり、公式のノードイメージによって作業が簡単にならない限り、通常はノードAlpineを選択することをお勧めします。
私が使用したほとんどすべてのノードコンテナは、90%がアルパインイメージで実行されています。
Nodejs 10以降を実行している場合は、Alpineで検出されたメモリリークの問題を考慮してください。