Docker は公式イメージを使用しません

現在の IT 業界では、Docker テクノロジーの使用がトレンドであり、避けられないトレンドになっています。多くの企業や個人が Docker テクノロジーを使用していますが、Docker テクノロジーを使用する場合、適切なイメージを選択することもプロジェクトの開発にとって非常に重要です。公式ではさまざまな画像が提供されていますが、実際に使用する場合、公式画像を使用することが必ずしも最良の選択であるとは限りません。では、なぜ公式画像の使用を避けるべきなのでしょうか?次に、その理由をいくつかの側面から説明します。

1. セキュリティ問題

公式ではさまざまなイメージが提供されていますが、実際に使用する場合、公式イメージの使用には一定のセキュリティ上のリスクがあります。まず、公式イメージが最新かつ最も安全なバージョンであることは保証されていません。イメージは通常、定期的なビルド ジョブをトリガーするか手動でオンデマンドでビルドされるためです。この場合、画像の品質とセキュリティは異なります。さらに、公式イメージを使用すると、非常に広く使用されているコード ベースを使用することになり、攻撃者が公式イメージに悪意のあるコードを挿入するリスクが高まります。

しかし、問題はそれだけではありません。公式イメージの方が使いやすいため、多くの人が同じソースイメージを使用し、その上にビルドします。これは、攻撃者が共通のソース イメージを侵害できる場合、悪意のあるコードを多くのプロジェクトに挿入し、エコシステム全体に壊滅的な結果をもたらす可能性があることを意味します。

2. 脆弱性

セキュリティの問題に加えて、公式イメージを使用すると、アプリケーションが攻撃に対して脆弱になるリスクにさらされます。公式イメージは root ユーザーを使用して実行されるため、攻撃者がスーパーユーザー権限を取得することが容易になります。特に、イメージが CentOS や Ubuntu などの一般的な Linux ディストリビューションに基づいている場合、攻撃者が root 権限を取得してフル コントロールを取得するのが簡単になる可能性があります。ただし、docker では、root 権限を必要とするアプリケーションはほとんどないため、root 以外のユーザーを使用してイメージを実行することが非常に重要です。

3. カスタマイズには適していません

公式イメージを使用すると、パッケージ化されたアプリケーションが得られるだけで、カスタマイズしたり何もすることはできません。あなたの環境に。したがって、アプリケーションをデプロイおよびカスタマイズするには、他の方法を使用する必要があります。イメージを構築するには複数のイメージを使用し、それらを連結する必要があるため、アプリケーションの実行が非効率になることがよくあります。

逆に、Dockerfile を使用すると、アプリケーションに変更を加えて、独自の実行環境に適応させることができます。基本イメージを使用して独自のイメージを構築する場合、必要なバージョン、依存関係、およびツールを選択し、それらを独自のイメージに追加できます。これは、コンテナ化されたアプリケーションを構築する最良の方法になります。

4. 公式イメージはかさばりすぎます

公式イメージには共通の依存関係や非常に多様なツールが含まれているため、かさばる場合があります。ただし、イメージを使用し、その一部のみが必要な場合は、イメージのダウンロードとデプロイにかかる時間が大幅に増加し、その結果、アプリケーションのデプロイが遅くなり、実行時間が長くなります。

結論

つまり、docker テクノロジを使用する場合、公式イメージを選択することを常に推奨するわけではありません。公式イメージには完全なアプリケーションとパブリックな依存関係が含まれていますが、セキュリティ、脆弱性、カスタマイズの不適性、および過度のサイズの点で特定の問題もあります。したがって、公式イメージの適切な代替として、独自に構築したイメージを使用することをお勧めします。自分で構築したイメージは自由にカスタマイズおよび制御できるため、セキュリティと制御性が向上し、アプリケーションの展開と運用が高速化されます。

以上がDocker は公式イメージを使用しませんの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。