コンテナ化への道: ビルド時間を盗んだのは誰ですか?

完全クラウド時代の到来により、多くの企業がコンテナ化の道を歩み始めており、Lao Liu 氏の会社も例外ではありません。新興インターネット企業として、コンテナ化は確かに多くの利便性をもたらし、会社のコストを削減しました。しかし、ラオ・リウには心配事があった。以前は毎日彼と一緒に仕事を終えていたシャオ・ワンさんは、会社がクラウドに移行してからは、毎日彼より1時間早く仕事を終えるようになりました。誰もが同じような仕事を抱えていますが、そうであるべきではありません。何度も試行錯誤し、追跡し、調査した結果、Lao Liu はついにその秘密を発見しました。

[[262139]]

開発者は、デバッグのために毎日 N 個のテスト バージョンをリリースする必要があります。コンテナ化後、各バージョンをイメージにコンパイルする必要があります。 Lao Liu 氏は画像を作成するのに 20 分かかりましたが、Xiao Wang 氏は 10 分しかかかりませんでした。比較してみると、これだけが違いました！

Storage-Dirver とは何ですか?なぜビルド時間に違いが生じるのでしょうか?では、見てみましょう。

この質問に答える前に、まず 3 つの質問に答える必要があります。画像とは何でしょうか?イメージ構築とは何ですか?ストレージドライバーとは何ですか?

鏡とは何ですか？

画像について話すとき、コンテナを避けることはできません。まず、画像とコンテナの公式説明にある画像を見てみましょう。

これを読んで、さらに混乱しましたか?単純かつ大まかに言えば、画像は読み取り専用レイヤーのスタックです。読み取り専用レイヤーには何がありますか?もう 1 つの単純かつ大まかな説明は、変更されたファイルが多数含まれているということです。この説明は、異なるストレージ ドライバーでは正確ではない可能性がありますが、現時点では次のように簡単に理解できます。

それは正しくありません。コンテナを実行すると、コンテナ内のファイルを変更したり削除したりできます。すべて読み取り専用の場合、どうすれば変更できますか?実際、コンテナを実行すると、読み取り専用レイヤーの上に読み取り/書き込みレイヤーが追加されます。すべての操作はこの読み取り/書き込み層で実行されます。ファイルを変更する必要がある場合は、変更するファイルを最下層から読み取り/書き込み層にコピーしてから変更します。削除したい場合はどうすればいいでしょうか?基になるファイルを削除する方法はありませんか?はい、確かに削除する方法はありませんが、削除効果を得るには、上位層のファイルを非表示にするだけで済みます。正式には、これが Docker のコピーオンライト戦略です。

イメージ レイヤーの理解を深めるために、例を挙げて次の Dockerfile を使用して etcd イメージを構築してみましょう。

ビルドが完了すると、次のレイヤー ファイルが生成されます。

コンテナに入るたびに、さまざまな Linux システム ディレクトリを含む仮想マシンに入ったように感じます。すべての Linux システム ディレクトリが含まれるディレクトリはありますか?

正解はビンゴです！最上位のディレクトリには、Linux のすべてのシステム ディレクトリ ファイルが含まれています。

上記のDockerfileにはこのような操作があります

./go/src/github.com/coreos/etcdを追加します。

外部ディレクトリ内のファイルがイメージにコピーされます。では、画像のこのレイヤーには何が保存されるのでしょうか?

開けてみると、

コピーされたファイルは /go/src/github.com/coreos/etcd ディレクトリに保存されます。

これで全体像が垣間見えるようになりました。次に、全体像を把握できるように、イメージ構築について学びましょう。

イメージ構築とは何ですか?

セクション *** の内容から、イメージは多数のレイヤー ディレクトリで構成されており、各レイヤー ディレクトリにはそのレイヤーの変更されたファイルが含まれていることがわかります。イメージ構築とは、イメージレイヤーを作成して生成するプロセスです。このプロセスはどのように実現されるのでしょうか?次のプロセスを例に挙げます。

Docker デーモンはまずベースイメージ ubuntu:14.04 を使用してコンテナ環境を作成します。セクション 1 の内容から、コンテナの最上位層は読み取り/書き込み層であり、書き込みと変更が可能であることがわかります。 Docker デーモンは最初に RUN apt-update get コマンドを実行します。実行が完了すると、この読み書きレイヤーの内容は、Docker のコミット操作によって読み取り専用のイメージ レイヤー ファイルとして保存されます。次に、このレイヤーに基づいて ADD run.sh コマンドを実行し続けます。実行が完了したら、ミラー レイヤー ファイルにコミットし続けます。すべての Dockerfile コマンドが送信され、イメージが準備されるまで、このプロセスを繰り返します。

ここで、etcd の特定のレイヤー ディレクトリに go ディレクトリが 1 つしかない理由を説明できます。これは、構築プロセスがレイヤーごとに送信され、各レイヤーには、このレイヤーの操作によって変更されたファイルのみが保存されるためです。

イメージビルドは、Dockerfile に従ってコンテナを繰り返し起動してコマンドを実行し、読み取り専用ファイルとして保存するプロセスのようです。ではなぜ速度が違うのでしょうか?次に、ストレージ ドライバーについて説明します。

ストレージドライバーとは何ですか?

この写真をもう一度見てみましょう。

画像がレイヤーディレクトリごとに積み重ねられていることはすでにわかっています。コンテナ ランタイムは、読み取り/書き込みレイヤーを上に追加するだけです。最下位レベルのファイル コンテンツを最上位レベルで変更できるようにするコピーオンライト戦略もあります。では、これらの原則はどのように実行されるのでしょうか?ストレージ ドライバーに依存します。

よく使用される 3 つのストレージ ドライバーを簡単に紹介します。

オーストラリア

AUFS は、ジョイントマウントによって複数のレイヤーのファイルを積み重ね、統一された全体を形成し、統一されたビューを提供します。読み書きレイヤーで読み書きを行う場合、まず現在のレイヤーにファイルが存在するかどうかを検索します。そうでない場合は、レイヤーごとに下方向に検索します。 aufs のすべての操作はファイルベースです。ファイルを変更する必要がある場合、ファイルサイズに関係なく、ファイル全体が読み取り専用レイヤーから読み取り/書き込みレイヤーにコピーされます。そのため、変更するファイルが大きすぎると、コンテナの実行速度が低下します。 Docker による公式の提案は、大きなファイルをイメージ レイヤーに配置するのではなくマウントすることです。

オーバーレイFS

OverlayFS は AUFS のアップグレード版と考えることができます。コンテナが実行されている場合、イメージ レイヤー内のファイルはハードリンクされて下位ディレクトリを形成し、コンテナ レイヤーは上位ディレクトリで動作します。上位ディレクトリは読み取りおよび書き込み可能で、下位ディレクトリは読み取り専用です。使用されるハードリンクの数が多いため、OverlayFS では inode が不足する可能性があります。その後、Overlay2 はこの問題を最適化し、大幅なパフォーマンスの向上を達成しました。ただし、Overlay2 にも AUFS と同じ欠点があり、大きなファイルの操作速度が比較的遅くなります。

デバイスマッパー

DeviceMapper と最初の 2 つのストレージ ドライバーの実装には大きな違いがあります。まず、DeviceMapper の各レイヤーは、前のレイヤーのスナップショットを保存します。 2 番目に、DeviceMapper のデータ操作はファイルベースではなくブロックベースになりました。

次の図は、コンテナ層でデバイスマッパーがファイルを読み取るプロセスを示しています。

1. まず、コンテナ層のスナップショットで、下位層ファイルへのファイルのポインタを見つけます。
2. 次に、下位層0xf33のポインタが指すデータブロックからデータをコンテナの記憶領域に読み込みます。
3. ***データをアプリに返します。

データを書き込む際には、コピーされたブロックデータを保存するために、データのサイズに基づいて 1 ～ N 個の 64K コンテナ スナップショットも適用する必要があります。

DeviceMapper のブロック操作は見た目は美しいですが、実際には多くの問題があります。例えば、小さなファイルを頻繁に操作する場合、リソースプールからデータベースを常に割り当ててコンテナにマッピングする必要があり、効率が非常に悪くなります。さらに、DeviceMapper は、イメージが実行されるたびに、すべてのイメージ レイヤー情報をメモリにコピーする必要があります。複数の画像を起動すると、多くのメモリ領域を消費します。

上記のetcd dockerfileを使用して、さまざまなストレージドライバーのビルドテストを実行しました。

注: Dockerfile、オペレーティング システム、ファイル システム、ネットワーク環境のテスト結果が異なるため、データが大きく異なる場合があります。

この実験シナリオでは、DeviceMapper は時間の点で AUFS や Overlay2 より明らかに劣っていますが、AUFS と Overlay2 は基本的に同等であることがわかりました。もちろん、このデータは参考としてのみ使用できます。実際の構築は、具体的な Dockerfile の内容、オペレーティング システム、ファイル システム、ネットワーク環境などの要因によっても影響を受けます。では、どうすれば施工時間を最小限に抑え、作業効率を向上させることができるのでしょうか?

次の分析をご覧ください!