Docker Executor での "環境のスピンアップ" ステップにおけるキャッシュの働き

注: この記事では、ジョブに含まれる、メイン コンテナ用の "環境のスピンアップ" ステップの観点から Docker Executor のキャッシュの働きについて説明します。 本記事の内容は、リモート Docker 環境の機能である Docker レイヤー キャッシュには適用できません

Docker コンテナのスピンアップからジョブの実行までに要する時間は、複数の要因により変わることがあります。要因としては、イメージのサイズのほか、レイヤーの一部または全部が基盤となる Docker ホスト マシンに既にキャッシュされているかどうかも影響します。

一般的に、CircleCI コンビニエンス イメージのような広く利用されているイメージほど、多くのレイヤーがキャッシュでヒットする可能性が高くなります。 よく利用される CircleCI イメージの大部分では同じベース イメージが使用されているので、基本レイヤーのほとんどもイメージ間で違いがないために、キャッシュがヒットする確率が高くなっているわけです。

環境のスピンアップは新しいジョブごとに必要です。新規ジョブが同じワークフロー内にある場合でも、ジョブの再実行や 2 回目以降の実行の場合でも、セキュリティ上の理由から、コンテナを再利用することはありません。 ジョブが終了すると、コンテナは破棄されます。 同じワークフロー内にある場合であっても、ジョブが同じ Docker ホスト マシンで実行されることは保証できません。また、異なる Docker ホスト マシンで実行される可能性があるため、キャッシュの状態も変わる場合があります。

いかなる場合でも、キャッシュのヒットは保証されるものではなく、ヒットすればラッキーな景品のようなものと言えるでしょう。 そのため、すべてのジョブでキャッシュがまったくヒットしないケースも想定しておいてください。

Docker レイヤー キャッシュのメリットは、リモート Docker 環境を使用して CircleCI でイメージをビルドする場合にのみ得られます。ジョブの実行に使用される実際の Docker コンテナのスピンアップ時間には影響しません。 Docker レイヤー キャッシュの詳細については、こちらを参照してください。

要約すると、キャッシュのヒット率は設定や構成で制御することはできません。CircleCI コンビニエンス イメージなど、広く利用されているイメージを選択すれば、"環境のスピンアップ" ステップでレイヤーがキャッシュでヒットする可能性が高まるでしょう。

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています