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

推薦する

メイン、セカンダリ、ボトムナビゲーションリンクを設定してスマートなスパイダーウェブを形成する方法について説明します。

今日のスパイダーは敏感です。注意を払わないと、ウェブサイトが破滅する可能性があります。著者にはウェブ...

インターネットマーケティングは自社のウェブサイトへの依存を適切に減らすべきである

インターネット マーケティングとは、簡単に言えばインターネットを介したマーケティングです。 WEB2...

Baidu に新しいサイトを追加して一定のランキングを獲得する方法

百度が新しいサイトを開設する問題は、よく話題になる。さまざまな声があちこちで聞かれ、さまざまな記事が...

ハイブリッドクラウドにおけるDevOpsのベストプラクティス

近年、柔軟性、パフォーマンス、スケーラビリティの向上を目的としたさまざまなツール、テクニック、フレー...

簡単な分析: マーケティングプロモーションの3つの基本ルール

AAA Xiaomi のハングリー戦略の下では、他のすべてのプロモーション マーケティング手法は影を...

#中秋/国庆# dogyun: 香港/日本/韓国/米国/ロシア/オーストラリア、VPS/クラウドサーバーは年間80元から、帯域幅は100M~1Gbps

現在、dogyunは中秋節と国慶節を祝うスーパープロモーションを開催しています。すべてのエラスティッ...

テンセントクラウドTDSQL-A、第7回国勢調査な​​どの大規模データシナリオをサポートするパブリッククラウドバージョンをリリース

テンセントクラウドは5月18日、大量データのリアルタイム分析のニーズに応えるため、初の完全自社開発分...

hncloud: 年末プロモーション、米国/香港、CN2回線クラウドサーバーは年間328元から、専用サーバーは688元から

hncloud(ワーナークラウド)の年末感謝祭特別プロモーションがしばらく続いています。人気の海外ク...

アリババクラウド社長張建鋒氏:新たなコンピューティングアーキテクチャが形になりつつある

10月19日、2021年雲奇カンファレンスで、アリババクラウドインテリジェンス社長の張建鋒氏が「クラ...

VaiCDN: 広帯域+高防御CDN、攻撃によるレイテンシへの影響なし、ファイリング不要、実名登録不要

VaiCDNは、個人や企業の高速化とセキュリティ防御の問題を解決するCDN会社です。主に実名登録や申...

マルチクラウド戦略から学んだ教訓

Intrado の CTO である Thomas Squeo 氏は最近、複数のクラウドの使用と社内の...

テクノロジーが次世代のRTCを生み出し、RongCloud SDKがあらゆる通信シナリオを解決

最近、RongCloud はリアルタイムオーディオとビデオの全面的なアップグレードを正式に発表し、イ...

Namecheap - .co ドメインを 0.99 ドルで登録

Namecheap はドメイン名移管のプロモーションを終了しました。.co ドメイン名用の新しい N...