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

推薦する

cloudcone: 1.6 ドル/KVM/512 メモリ/1T トラフィック/IP 変更 - 0.5 ドル/時間|Alipay

cloudcone は新しいプロモーションを実施しており、5 つの安価な VPS、KVM 仮想化、1...

ブランドの若返り:全国的なトレンドはどうやって生まれるのか?

月給5,000~50,000のこれらのプロジェクトはあなたの将来です老干馬のトレーナーが消えた直後に...

個人ウェブサイトはどうすればBaiduへの依存から抜け出せるのでしょうか?

数日前、1,000 を超える IP アドレスを持つ私の小さな Web サイトの 1 つが、不明な理由...

SEO の悪党たちの秘密を暴く

SEO 凶悪犯とは、対戦相手の Web サイトを攻撃して自分のランキングを向上させる SEO 担当者...

K8S ベースのクラウド ネイティブ アーキテクチャのコスト最適化ガイド

鄭漢ララムーブテクノロジーセンターコアインフラ部門建築家Huolala では、Kubernetes ...

JD.com、Suning、Gomeなどの電子商取引企業間の価格競争は、マーケティングの空都市戦略に他ならない

最近の価格戦争には誰もがうんざりしていると思います。JD.com CEOの一言が大きな騒動を引き起こ...

オンラインマーケティングを行う際は、「ジャンクトラフィック」を避けてください

Changsha Internet Marketing は、インターネット マーケティング担当者とし...

長くて薄い10,000語の記事でRedisson分散ロックのソースコードを説明します

[[382196]]序文前回の記事ではRedisの分散ロックの原理と欠点について書きましたが、それだ...

vpsdimeはどうですか?英国VPSの簡単なレビュー

vpsdime は英国で VPS サービスを展開しており、大容量メモリ、マルチコア、広帯域幅、Ope...

百度の新しいアルゴリズムフォグ:不正サイトを特定するための心理戦

ネットワーク セキュリティの分野では、技術面だけでなく、反ソーシャル エンジニアリング攻撃能力につい...

HeroicVPS-7ドル/KVM/2IP/512Mメモリ/30gハードディスク/1Tトラフィック/Phoenix/Windows

HeroicVPS の 10 月のプロモーションが始まりました。生涯 30% オフの割引コード: 8...

タオバオアフィリエイトステーションの百度の最新アルゴリズムへの対応戦略

幸せな春節を祝った後、多くのウェブマスターが百度によって大打撃を受けたと思います。1月下旬から2月上...