レイヤー化を使用した 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 インスタンスの一般提供を発表

推薦する

日本のクラウドサーバーの推奨:帯域幅が大きく、価格が安く、CN2\CU2\Softbank\IIJ\KDDIなどのハイエンド回線

日本のクラウドサーバーで一番良いのはどれですか?どの日本のクラウドサーバーが速いですか?日本のクラウ...

「フォーカスインタビュー」後もSEOと関連業界は引き続き厳しく規制される

CCTV ニュースはいつ放送されても、程度の差こそあれ業界の是正と改革をもたらすだろう。したがって、...

サーバー仮想化の将来はどうなるのでしょうか?

サーバー仮想化は、過剰なサーバー リソースの消費を抑え、コンピューターのパワーをより有効に活用し、エ...

maple-hosting: オランダのサーバー、苦情防止、著作権無視、最大 20Gbps の帯域幅、トラフィック制限なし

Maple-hosting は 2008 年に設立された民間ホスティング会社で、オランダのデータ セ...

クラウドコンピューティングの時代に、企業が無視できないネットワーク要素が 3 つあります。

分散型相互接続クラウド ホスティング アプリケーション経済の時代において、ネットワークは重要な役割を...

30日間でキーワードランキング1位を獲得した方法

私たち中小企業は、SEO を行う際に、特にウェブサイトを構築したばかりの最初の数か月間は非常に悩むこ...

Baidu の外部リンク ツールの統計における外部リンクが不完全なのはなぜですか?

百度は11月25日、百度ウェブマスターツールの外部リンク検索ツールのベータ版をリリースした。武漢SE...

人気のWeiboマーケティングの見方

ショートビデオ、セルフメディア、インフルエンサーのためのワンストップサービス1. まず、Weiboや...

VPC をマスターするための 4 つのヒント

インターネット上のさまざまなソフトウェア、アプリケーション、モバイル アプリが、人々の生活に毎日溢れ...

XcodeGhost事件は成人における最も深刻な情報セキュリティ事件かもしれない

商業セキュリティ評価機関やアプリケーションソフトウェア開発者は、iOS システムが XcodeGho...

Google vs. Baidu: Baidu

1. 百度はグーグルからトラフィックを借りることができるGoogleで神話、雷鋒、朱子清、劉亦菲、李...

売り手のクイックルック: SEO をうまく行うための 5 つのヒント

流行中、世界中でインターネットの利用が大幅に増加しました。モバイルトラフィックは、2019年第3四半...

fliphost-2周年記念-KVM+SSD+2Gメモリ/Gポート/月額7ドル

Fliphost は 2 周年を記念して、KVM VPS の特別価格を開始しました。これには SSD...

クラウドが登場した今、リスクをどのように排除できるでしょうか?

過去数年間、特に 2018 年の傾向から判断すると、マルチクラウドは概念から現実へと移行しつつあるよ...