レイヤー化を使用した Docker イメージの最適化

レイヤー化を使用した Docker イメージの最適化

1. Dockerイメージ階層化ストレージ

イメージの再利用を最大限に高め、操作を高速化し、メモリとディスクの使用量を削減するために、実行時に Docker コンテナによって構築される動作環境は、実際には依存関係を持つ複数のレイヤーで構成されています。図 1 に示すように、デジタル ID の各文字列は Docker イメージ レイヤーを表します。 Docker イメージをプルすると、依存するすべてのレイヤー ファイルがダウンロードされることがわかります。

図 1. Docker イメージ レイヤー図

たとえば、Docker アプリ イメージの動作環境は、基本的な Docker ベース イメージに基づいており、これに Anaconda などのさまざまなツールを含むイメージ、モデル ドキュメントと関連する依存ライブラリを含むイメージ、および最終アプリケーションのコード パッケージを含むレイヤーが重ね合わされています。これらのイメージは、AUFS ファイル システムによって読み込まれ、統一されたパスにマージされ、読み取り専用で存在します。最後に、書き込み可能な空白レイヤーがその上に読み込まれ、現在の実行環境に加えられた変更が記録されます。したがって、ベースイメージから Docker イメージが作成されるたびに、新しいイメージによってレイヤーが自動的に追加されます。図2に示すように:

図2. Dockerイメージレイヤーのオーバーレイ

2つのDockerイメージから1つのベースイメージが派生する

Docker ベースのプロジェクトの使用が増えるにつれて、Docker イメージの数も増加します。次の疑問は、これらの Docker イメージのアップグレードをどのように維持するかということです。計画と設計が不十分で、各 Docker イメージが基本 OS イメージから取得されている場合は、すべての Docker イメージを再構築する必要があります。図3に示すように:

図3. Dockerイメージは単一のベースイメージを派生する

環境が更新およびアップグレードされるときに、すべてのノードが基本 OS イメージからのものである場合、重複するレイヤーが繰り返し更新されます。つまり、重複コンテンツのこの部分は繰り返しダウンロードされることになります。 Docker イメージが 1G より大きい場合、Docker ホスト ノードを更新するたびに新しいイメージを再度ダウンロードする必要があります。これにより、環境の更新にかかる時間が飛躍的に増加します。図 4 に示すように、Docker イメージ 2 と Docker イメージ 3 はどちらも Docker イメージ 1 に基づいています。

図4. 同じベースイメージに基づくDockerイメージレイヤーのオーバーレイ

図5. Dockerホスト上のDockerイメージレイヤーのストレージ関係

図 5 から、同じ Docker ホスト上の同じベース イメージから Docker イメージをダウンロードする場合、Docker はイメージ レイヤーをダウンロードするときに既存のレイヤーを繰り返しダウンロードしないことがわかります。ただし、レイヤーが異なると、内容が同じであっても繰り返しダウンロードされることになります

3. レイヤー化メカニズムを使用してDockerイメージを最適化する

前の 2 つのセクションの紹介から、適切に設計された Docker イメージがないと、将来のメンテナンスとその後の CICD の効率に大きな問題が発生することがわかります。次に、階層化メカニズムを使用してプロジェクトの Docker イメージを合理的に計画する方法を紹介します。これにより、CICD プロセスにおける Docker の持続可能性が向上し、CICD の効率が向上します。

3.1 階層化メカニズムに基づく Docker イメージの設計

システムに App1 と App2 という 2 つのアプリケーションがあるとします。これら 2 つのノードの環境情報は次のとおりです。

分類

APP1

APP2

基本環境イメージ(os)

Python 3.7

Python 3.7

セキュリティツール

セキュリティフレームワーク

セキュリティフレームワーク

一般的なツール

make/gcc/path/wget/sudo/tar

make/gcc/path/wget/sudo/tar

依存ライブラリ

pip install -y 依存関係

pip install -y 依存関係

モデル

some-path/dust.model

some-path/dust.model

コード

コード.1

コード.2

構成

app1.conf

app2.conf

上記の表の環境情報を比較すると、これら 2 つの異なる参照ノード上の唯一の異なる部分は、最終コードと構成ファイルであることがわかります。その他の同一部分については、Docker イメージ レイヤーの概念を通じて再利用することを検討できます。これにより、Docker の機能が最大限に活用されます。上記の表の環境情報の2つの部分は、ノード名に分類され、図6に示すようにツリー構造に再構成されます

図6. 環境構成ツリー図1

頻繁に変更されないコマンドや同じタイプのコマンドを同じレイヤーにマージすることをお勧めします。図7に示すように:

図7. 環境構成ツリー図2

最後に、図の 2 つのツリー構造を重ね合わせて繰り返しノードをマージし、最終的に次のツリー構造が得られます。

図8. 環境構成ツリー図3

これで、Docker イメージの階層型ストレージ メカニズムに基づいた予備的な Docker イメージの計画が完了しました。次に、上図の構造に従って画像を作成します。最終的には、コードが追加された 3 つのベース イメージとビジネス イメージが作成されます。同時に、これに基づいて、Dockerfile も次のようになります。4 つの GitLab リポジトリによって作成された 4 つのイメージがあります。画像の再利用関係をわかりやすく示すために、コード ブロックを使用して表示します

 # f1 :運用保守セキュリティチームが基本的なセキュリティコンポーネントを追加し、最適化します
Python3 から
apt install -y some -security -frameworkを実行します。
# プッシュ: abc .hub .com / libary / python3

# f2 :アーキテクトがインフラストラクチャをインストールする
abc .hub .com / libary / python3 より
wget -c anaconda12 .sh &&を実行します。 / anaconda12 .sh && rm - f anaconda12 .sh
# プッシュ: abc .hub .com / ai - tools / env - anaconda : 12

# f3 :モデルミラーを作成する
abc .hub .com / ai - tools / env - anaconda から: 12
pip install -y some -dependencesを実行します。
wget -c s3 .xx .com / some - path / dust .model - O / some / path を実行します。
# プッシュ: abc .hub .com / ai - tools / env - anaconda - dust :ランタイム

# f4 :ビジネスイメージを作成する
abc .hub .com / rk - ai - tools / env - anaconda - dust :ランタイムから
コード/ワークスペース/コードを追加
エントリポイント[ "/bin/bash" "/entrypoint.sh" ]
# プッシュ: abc .hub .com / rk - ai - pollution / srv - some - appname - amd64 : 1.0 .0-1234567

3.2 階層化メカニズムに基づくDockerイメージの実践

図 10 に示すように、前述のセキュリティ ツール/一般ツール/ライブラリをインストールするための Docker イメージのサイズは約 1.8G です。これを元に作成したアプリイメージのサイズは約1.9Gになります。

図10. Dockerイメージ階層化ストレージ実験1

Liberty Docker イメージがダウンロードされた環境でアプリ イメージをダウンロードします。図 11 に示すように、既存のレイヤーがすでに完了状態になっていることがわかります。ダウンロードされるのは、新しく追加された EAR によって生成された新しいレイヤーのみです。所要時間はわずか1分33秒です。

図11. Dockerイメージ階層化ストレージ実験2

図 12 に示すように、Liberty Docker イメージが存在しないサーバーに App Docker イメージを直接ダウンロードすると、7 分以上かかることがわかります。

図12. Dockerイメージ階層化ストレージ実験3

図 13 から、他のレイヤーのダウンロード時間は 4 分以上であることがわかります。これらの重複した Docker イメージ レイヤーが繰り返しダウンロードされ、更新されると、環境更新の効率が著しく低下します。 Docker イメージ レイヤー内の異なるイメージ間の差異が大きくなるにつれて、Docker イメージのダウンロード コストも増加します。

図13. Dockerイメージ階層化ストレージ実験4

4. まとめ

上記の説明と実際のテストから、イメージを合理的に階層化できれば、イメージの取得時間を短縮して CICD の効率を向上できるだけでなく、異なるチームや異なる担当者の役割を分割できることがわかります。誰もが自分の責任に関連するイメージだけに焦点を当てています。その後、異なるチームまたは同じチーム内の他の担当者が、それらに基づいてレイヤーごとに独自のイメージを構築し、最終的にビジネスリリース用のイメージを作成できます。

<<:  Pod 内のコンテナをリモートでデバッグする方法 (補足記事)

>>:  Amazon Web Services は、新しい Amazon Graviton3 を搭載した Amazon EC2 C7g インスタンスの一般提供を発表

推薦する

Tongwei CIO 周勇: 低コストでユニバーサルなクラウド災害復旧が可能に

[51CTO.comより引用] 3年ぶりに、成都のTongwei本社で、Tongwei Co., L...

ブルーオーシャンからレッドオーシャンへ、ソーシャルコンテンツ電子商取引の未来はどこにあるのでしょうか?

ネットセレブやスターに倣って買い物をすることは、多くの人にとって一般的なショッピングパターンとなって...

ユーザーの検索サイクルを分析して検索エンジンマーケティングの効率を向上

ユーザーの検索領域は非常に広く、さまざまな生活情報がユーザー検索の主な行き先となっています。ユーザー...

アリペイがWeChatに勝つための究極の戦略は、自らを「開発ゲーム」にすること

AlipayまたはWeChat ?これは問題だ!毎日何億回も起こる選択シナリオ: 販売店が Alip...

SEM にはどのような指示が含まれますか?

現在、インターネット上には数え切れないほどのウェブサイトがあります。趣味のために個人のウェブサイトを...

小紅書にとって、この輪から抜け出すのは容易なことではない

今日では、若者の興味や趣味のほとんどは、コンテンツ コミュニティで発見され、満たされます。例えば、知...

ウェブサイトのランキングが下がったらどうすればいい?内部分析

最近、私が運営している心理カウンセリングサイトの順位が下がっています。一週間ほど経ちますが、ざっと観...

ユニクロ:オンラインとオフラインを融合した「型破りな」ゲームプレイで、最も成熟したO2Oモデルを創出

ユニクロといえば、北京や上海などの都市の主要ショッピングモールに店舗が頻繁に出店していることに加え、...

fatcow - 年間 1 ドルで無制限のホスティング (急いでください。もうすぐ期限が切れます)

2017年第4四半期、fatcowは米国の仮想ホスティングランキングで8位にランクされました。 Fa...

百度のアルゴリズム調整:リアルタイムホットスポットのプレビュー

Baidu はアルゴリズムを調整したばかりですが、これはおそらく Baidu アカウントを持つユーザ...

DEDEcms 究極の SEO 最適化チュートリアル

DEDEcms は中国のオープンソース CMS プログラムです。現在、ウェブサイトの構築に dede...

陳偉:デジタル変革とNetEaseマイクロサービスの実践に関する3つの提案

[51CTO.comより] 第9回中国(天津浜海)国際エコシティフォーラムと2018年中国国際デジタ...

SEOプロセスにおける最高レベルのユーザーエクスペリエンス

この業界に入って以来、私は常にユーザーエクスペリエンスの重要性を第一に考えてきました。ウェブサイトの...

企業がクラウド コンピューティングを使用する必要があるのはなぜですか?

今日のビジネスで最も重要な側面が何であるかについては人によって意見が異なりますが、ますます多くの企業...