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 つのノードの環境情報は次のとおりです。
上記の表の環境情報を比較すると、これら 2 つの異なる参照ノード上の唯一の異なる部分は、最終コードと構成ファイルであることがわかります。その他の同一部分については、Docker イメージ レイヤーの概念を通じて再利用することを検討できます。これにより、Docker の機能が最大限に活用されます。上記の表の環境情報の2つの部分は、ノード名に分類され、図6に示すようにツリー構造に再構成されます。 図6. 環境構成ツリー図1 頻繁に変更されないコマンドや同じタイプのコマンドを同じレイヤーにマージすることをお勧めします。図7に示すように: 図7. 環境構成ツリー図2 最後に、図の 2 つのツリー構造を重ね合わせて繰り返しノードをマージし、最終的に次のツリー構造が得られます。 図8. 環境構成ツリー図3 これで、Docker イメージの階層型ストレージ メカニズムに基づいた予備的な Docker イメージの計画が完了しました。次に、上図の構造に従って画像を作成します。最終的には、コードが追加された 3 つのベース イメージとビジネス イメージが作成されます。同時に、これに基づいて、Dockerfile も次のようになります。4 つの GitLab リポジトリによって作成された 4 つのイメージがあります。画像の再利用関係をわかりやすく示すために、コード ブロックを使用して表示します。 # f1 :運用保守セキュリティチームが基本的なセキュリティコンポーネントを追加し、最適化します 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 は新しいプロモーションを実施しており、5 つの安価な VPS、KVM 仮想化、1...
月給5,000~50,000のこれらのプロジェクトはあなたの将来です老干馬のトレーナーが消えた直後に...
数日前、1,000 を超える IP アドレスを持つ私の小さな Web サイトの 1 つが、不明な理由...
SEO 凶悪犯とは、対戦相手の Web サイトを攻撃して自分のランキングを向上させる SEO 担当者...
鄭漢ララムーブテクノロジーセンターコアインフラ部門建築家Huolala では、Kubernetes ...
最近の価格戦争には誰もがうんざりしていると思います。JD.com CEOの一言が大きな騒動を引き起こ...
Changsha Internet Marketing は、インターネット マーケティング担当者とし...
[[382196]]序文前回の記事ではRedisの分散ロックの原理と欠点について書きましたが、それだ...
gcorelabs さん、皆さんはご存知だと思いますので、これ以上無駄な言葉は使いませんよね? !今...
vpsdime は英国で VPS サービスを展開しており、大容量メモリ、マルチコア、広帯域幅、Ope...
ネットワーク セキュリティの分野では、技術面だけでなく、反ソーシャル エンジニアリング攻撃能力につい...
HeroicVPS の 10 月のプロモーションが始まりました。生涯 30% オフの割引コード: 8...
最近、MediaTemple が月額 10 米ドルでトラフィック制限のない安価な VPS を開始した...
2022 年 5 月 11 日、Amazon Web Services は、サーバーレス データベー...
幸せな春節を祝った後、多くのウェブマスターが百度によって大打撃を受けたと思います。1月下旬から2月上...