コンテナレジストリデータ転送の削減

コンテナレジストリからイメージやタグをダウンロードする頻度によっては、データ転送量がGitLab.comの制限を超えることがあります。このページでは、コンテナレジストリでのデータ転送量を減らすための推奨事項やヒントをいくつか紹介します。

データ転送の使用量をチェック

GitLabのUIでは転送の使用状況を確認することができません。GitLab-#350905は、この情報を表示するための作業を追跡しているエピックです。暫定的に、GitLabチームメンバーは転送量の上限を大幅に超えている顧客に連絡を取り、彼らのユースケースをよりよく理解し、データ転送の使用量を減らす方法を提案する可能性があります。

画像サイズの決定

これらのツールやテクニックを使って、画像のサイズを決めましょう：

  • スコペオ：スコペオinspect コマンドを使い、API コールを使ってレイヤー数とサイズを調べます。こ のため、docker pull IMAGEを実行する前にこのデータを調べることができます。

  • CIでのDocker：Dockerでイメージをプッシュする前に、GitLab CIを使用してイメージのサイズを調べて記録します。例えば

     docker inspect "$CI_REGISTRY_IMAGE:$IMAGE_TAG" \
       | awk '/"Size": ([0-9]+)[,]?/{ printf "Final Image Size: %d\n", $2 }'

  • DiveはDockerイメージやレイヤの内容を調査し、サイズを小さくする方法を発見するためのツールです。

イメージサイズの削減

より小さいベース画像を使用

Alpine Linux のような、より小さなベースイメージを使うことを検討してください。Alpineのイメージは約5MBで、Debianのような一般的なベースイメージよりも数倍小さくなっています。Goアプリケーションのように、アプリケーションが自己完結型の静的バイナリとしてディストリビューションされている場合は、Dockerscratchベースイメージの使用も検討できます。

特定のベースイメージOSを使用する必要がある場合は、-slim または-minimal を探してください。

また、ベースイメージの上にインストールするオペレーションシステムパッケー ジにも注意してください。これらは数百メガバ イトになることがあります。インストールするパッケージの数は最低限に抑えてください。

マルチステージビルドは、一時的なビルド依存関係をクリーンアップする強力な味方となります。

また、以下のようなツールの使用も検討してください：

  • DockerSlimはコンテナイメージのサイズを縮小するためのコマンド群を提供します。
  • Distrolessイメージには、アプリケーションとその実行時の依存関係のみが含まれています。パッケージマネージャやシェル、その他標準的なLinuxディストリビューションにあるようなプログラムは含まれていません。

レイヤーの最小化

Dockerfileのすべての命令は新しいレイヤにつながり、その命令中に適用されたファイルシステムの変更を記録します。一般的に、レイヤーが多ければ多いほど、イメージが大きくなります。Dockerfileのパッケージをインストールするレイヤの数を最小限にするようにしてください。そうしないと、ビルドプロセスの各ステップでイメージサイズが大きくなる可能性があります。

レイヤの数とサイズを減らす戦略は複数あります。例えば、RUN インストールしたいオペレーションシステムパッケージごとにコマンドを RUN使用する代わりにRUN （パッケージごとにレイヤーが発生します）、1つの RUNコマンドRUN ですべてのパッケージをインストール RUNすることで、ビルドプロセスのステップ数を減らし、イメージのサイズを小さくすることができます。

もうひとつの有効な戦略は、一時的なビルド依存関係をすべて削除し、パッケージのインストール前後にオペレーティングシステムのパッケージマネージャキャッシュを無効にするか空にすることです。

イメージをビルドする際には、関連するファイルのみをコピーするようにしてください。Dockerの場合、.dockerignore 、ビルドプロセスが無関係なファイルを無視するようにします。

DockerSlimのような、イメージを最小化するサードパーティツールを使用することもできます。このようなツールは不適切に使用すると、アプリケーションが特定の条件下で動作するために必要な依存関係を削除してしまう可能性があることに注意してください。したがって、ビルドプロセス中にイメージを小さくするように努力するのが望ましいです。

マルチステージビルドの使用

マルチステージビルドでは、FROM Dockerfileで FROM複数のFROM ステートメントを FROM使用します。FROM それぞれの FROM命令は異なるベースを使用することができ、それぞれが新しいビルドステージを開始します。あるステージから別のステージへアーティファクトを選択的にコピーし、最終イメージに不要なものをすべて残すことができます。これは特に、ビルドの依存関係をインストールする必要があるが、最終イメージに存在させる必要がない場合に便利です。

イメージのプルポリシー

docker またはdocker+machine Executorを使用する場合、Dockerイメージをプルする際のRunnerの動作を定義するconfig.toml 、Runnerにpull_policy パラメータを設定することができます。大きくてめったに更新されないイメージを使用するときにデータの転送を避けるには、リモートレジストリからイメージをプルするときにif-not-present プルポリシーを使用することを検討してください。

Dockerレイヤーキャッシングの使用

docker build を実行すると、Dockerfile の各コマンドがレイヤになります。これらのレイヤーはキャッシュとして保存され、変更がなければ再利用できます。--cache-from 引数を --cache-from使用すると、docker build コマンドのキャッシュソースとして使用するタグ付きイメージを指定できます。複数の引数を使用することで、--cache-from 複数の画像をキャッシュソースとして指定 --cache-fromできます。これにより、ビルドを高速化し、転送するデータ量を減らすことができます。詳細については、Dockerレイヤーキャッシングのドキュメントを参照してください。

自動化の頻度をチェック

コンテナイメージにバンドルされた自動化スクリプトを作成し、特定の間隔で定期的なタスクを実行することがよくあります。オートメーションがGitLabレジストリからGitLab.comの外のサービスにコンテナイメージをプルしているような場合には、それらの間隔の頻度を減らすことができます。

GitLabプレミアムまたはアルティメットへの移行

GitLab.comのデータ転送制限はティアレベルで設定されています。より高い制限が必要な場合は、GitLab PremiumまたはUltimateへのアップグレードをご検討ください。

追加データ転送の購入

データ転送量の上限管理について詳しくはこちらをご覧ください。

  • ベースとなるDockerイメージが更新された際に、イメージを再構築したいと思うかもしれません。しかし、この機能を利用するにはパイプラインのサブスクリプションの上限が低すぎます。回避策として、毎日または1日に複数回リビルドすることができます。GitLab-#225278では、このワークフローを支援するために上限を引き上げることを提案しています。