Docker Hubの「429 Too Many Requests」に終止符を。GitLab Dependency ProxyでCIを鉄壁にする極意
CIパイプラインが「Docker Hubのレート制限」で落ちる。これは現代のDevOpsにおける「現代の石器時代」のような恥ずべき状況だ。数百のマイクロサービスを抱える環境で、ビルドが外部のプロバイダーの機嫌に左右されるなど言語道断。
今日は、GitLabの知る人ぞ知る強力な武器「Dependency Proxy」を使い、ビルドの安定性を極限まで高める方法を伝授する。これは単なる回避策ではない。アーキテクチャの冗長性を確保するための戦略だ。
—
1. なぜDependency Proxyなのか？
Docker Hubのプル制限は、IP単位でカウントされる。CI環境が共有NATゲートウェイを使っていれば、一つの巨大なリポジトリのビルドが、チーム全体のパイプラインを止めるトリガーになる。
GitLabのDependency Proxyを噛ませることで、以下の恩恵が得られる。
- Docker Hubのレート制限を回避: GitLabのキャッシュを叩くため、Docker Hubへのアクセスは初回のみ。
- ビルド時間の短縮: ネットワークの物理的な距離とHubの混雑を無視し、GitLab自身の高速なI/Oでイメージをプルできる。
- セキュリティの向上: 外部の不明なレジストリではなく、自社のGitLabを経由することで、トラフィックを制御下に置く。
—
2. 実践：.gitlab-ci.ymlで「脱Docker Hub」を果たす
Dependency Proxyを有効にすると、`gitlab.example.com/group-name/dependency_proxy/containers/` というパスが払い出される。これをビルドで活用する最適解がこれだ。
推奨の構成パターン
variables:
# Dependency ProxyのURLを変数化（メンテナンス性を向上）
DOCKER_PROXY: “${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}”
stages:
- build
build_image:
stage: build
image: “${DOCKER_PROXY}/docker:24.0.5” # ツール自体もキャッシュ経由にする
services:
- name: “${DOCKER_PROXY}/docker:24.0.5-dind”
alias: docker
script:
# Docker Hub直指定をやめ、プロキシ経由でプルする
- docker pull ${DOCKER_PROXY}/alpine:latest
- docker build -t my-app:latest .
before_script:
# GitLabのトークンで認証（自動で注入されるが明示的に書くことでデバッグしやすくする）
- echo “$CI_DEPENDENCY_PROXY_PASSWORD” | docker login “$CI_DEPENDENCY_PROXY_SERVER” -u “$CI_DEPENDENCY_PROXY_USER” –password-stdin
【極限のハック】イメージの正規化
プロジェクトごとに毎回URLを書くのはDRY原則に反する。`include` や `CI/CD Variables` を駆使し、「すべてのイメージパスを自動で置換するスクリプト」を `before_script` に埋め込むのがテックリードの流儀だ。
—
3. 生産性を爆上げする「隠れたテクニック」
① GitLab UIのキーボードショートカットをマスターせよ
GitLabの画面で `?` を押すだけで、全ショートカットが表示される。特に `g` → `i` で自分のIssueに飛ぶ、`g` → `m` でマージリクエストに飛ぶ習慣をつけるだけで、マウスを触る時間を年間数時間削減できる。
② VS Codeの神プラグイン「GitLab Workflow」
単なるGit拡張ではない。パイプラインのステータスを確認し、ビルドエラーが発生した瞬間にVS Code上でログを追跡できる。CIのためにブラウザとエディタを行き来するコンテキストスイッチは悪だ。これ一つで完結させろ。
③ プロジェクトを横断する「共有設定」
GitLabの 「Instance-level CI/CD variables」 や 「Group-level CI/CD variables」 を使え。特に `DOCKER_PROXY` 変数をグループルートに設定しておけば、配下の全リポジトリで同じ設定を使い回せる。新プロジェクトを立ち上げる際、設定漏れでパイプラインが死ぬ事故を防げる。
—
4. プロの現場で守るべきルール
- イメージのタグは必ず固定せよ: `:latest` を使うのは素人だ。必ず `:3.18.4` のようにバージョンを固定し、Dependency Proxyのキャッシュヒット率を安定させろ。
- クリーンアップポリシーを忘れるな: Dependency Proxyはストレージを食う。GitLabの「Dependency Proxyのキャッシュ」設定から、古いイメージの自動削除ポリシーを適切に設定しておくこと。
- 依存関係の可視化: `glab` CLI（GitLab公式CLI）を導入せよ。ターミナルから `glab api` を叩くことで、CIの実行状況やキャッシュの状態をスクリプトで監視・自動化できる。
—
最後に：なぜここまでやるのか
「CIが落ちたから直しておいて」と誰かに頼む時間は、エンジニアにとって最も非生産的な時間だ。
Dependency Proxyを導入することは、単に「エラーを消す」ことではない。「インフラの制約をコードで完全に制御下に置く」という、DevOpsの本質を実現することに他ならない。
ツールは、飼いならすものだ。Docker Hubの制限に泣くのは今日で最後にしよう。君のパイプラインを、誰よりも速く、誰よりも堅牢なものに仕上げてくれ。