2026 リモート Mac CI：GHCR と私有 Registry の越境 pull

越境では429と再試行連鎖が先に来やすいです。共有 runner ではレイヤバーストが重なり、トークンTTL不足で後半に再ログインが要ります。TLS インタセプトとレイヤ展開で水位も跳ねます。

意思決定の早引き：同一組織・同一リージョン中心なら ghcr.io 直結＋ジョブ内同時イメージを絞る。監査ログ・固定出口 IP・VPC 近接が必須なら私有 Registry またはクラウド vendor Registryを主軸にし、GHCR はビルド成果物の公開配布面に限定するのが衝突が少ないです。

GHCR は GITHUB_TOKEN または read 相当の PAT。私有 Registry はロボット＋pull のみで監査 ID を残す。

レジストリ種別	推奨シークレット	最小スコープ	ローテーション
GHCR（同一リポ CI）	GITHUB_TOKEN	packages:read 等ワークフロー権限	ジョブ毎自動（TTLはホスト側セッションに依存）
GHCR（跨リポ／組織）	PAT / GitHub App	パッケージ読取のみ	30〜90 日＋期限前ローテ
Harbor／GitLab Registry 等	ロボットトークン	pull のみ・プロジェクト限定	7〜30 日、長いジョブは都度発行

三択は直結／ミラー／pull-through。職場〜runnerの組合せで遅延が支配的になり得ます。

経路	向き	利点	留意点	向くシナリオ
ghcr.io 直結	公式	運用が単純、ロックイン低い	429 に弱い／越境遅延	小〜中規模・単一リージョン
クラウド vendor Registry（ECR/GCR/ACR 等）	クラウド内	VPC 近接でレイテンシ良好	クロスクラウドで再度越境	ビルドとイメージが同一クラウド
自前 Harbor／distribution	社内／近傍リージョン	帯域・認証を自前制御	運用コスト・同期遅延	監査・固定出口 IP が必須
pull-through キャッシュ	オリジン手前	同一レイヤの再pull爆発を吸収	無効化・TTL設計が要る	多数 runner／モノレポ CI

早道：週次 429 なら並列＋キャッシュ、遅延のみなら近接 Registry／レプリカを先に比較。

表は初期値。P95 と 429/5xx で±1 段階。

実行パラメータ早見（コピー運用）

レバー	主な設定キー	推奨初期値	判断メモ
同時レイヤ取得階層	daemon.json の max-concurrent-downloads	越境 2〜3／同一リージョン 4〜6	429 やディスク await 悪化なら −1。ヒット率が高く平坦なら +1。
ジョブ内同時イメージ本数	ワークフロー内セマフォ／直列化	1〜2 本	IO 飽和・多段ビルドなら 1 に固定。
docker login トークン TTL	PAT／ロボットの発行ポリシー	GHCR PAT 30〜90 日、私有ロボット 7〜30 日（短め推奨）	長尺 E2E は ジョブ分割か pull 直前 login。
HTTP 429／5xx 退避階段（秒）	シェル sleep／オーケストレータ backoff	4 → 12 → 30 → 90（上限 120 でクリップ）	2 回目以降は並列を一段削るのがセット。
ディスク水位閾値	監視メトリクス＋キュー制御	警告 78〜80%／新規大容量 pull キュー 85%／停止・清掃 90%（空き絶対値は 25→12→6 GB 段階）	await >80ms が継続なら並列を半減。

並列レイヤー取得（デーモン／ジョブ）

シナリオ	パラメータ	推奨初期値	上げる条件	下げる条件
単一イメージ・越境	daemon.json の max-concurrent-downloads	2〜3	レイテンシ低・429 なし	429 またはディスク await 悪化
同一ジョブで複数 docker pull	ジョブ内直列化／セマフォ	同時 1〜2 イメージ	キャッシュヒット率が高い	レイヤ競合・IO 飽和
BuildKit ビルド中の取得	BUILDKIT_MAX_PARALLELISM（ビルド並列）	4〜6（8G 台）	CPU 余力・ディスク快調	プルとビルドが同一ディスクで競合

docker login とトークン TTL

トークン種別	TTL 目安	ログイン位置	備考
GitHub Actions GITHUB_TOKEN	ジョブと同一寿命	ワークフロー内の pull 直前	ホスト runner では別途 PAT が必要な場合あり
GHCR 用 PAT（人間／サービス）	発行ポリシー 30〜90 日	セッション開始時 1 回	長い E2E はジョブ分割で timeout 内に収める
私有 Registry ロボット	7〜30 日（短め推奨）	各ジョブの最初の step	期限 6h など短 TTL なら login を pull 直前に限定

HTTP 429／5xx 退避（ジョブオーケストレータ／シェル）

試行回数	待機秒（目安）	対象	打ち切り後
1 回目失敗直後	2〜5 s	5xx／ネットワーク瞬断	同一トークンで再試行可
2 回目	8〜15 s	429／502／503	並列プルを 1 段階削る
3 回目	20〜40 s	429 継続	キュー待ちまたは別ミラー経路
4 回目以降	60〜120 s（上限クリップ）	依然 429	アラート＋手動で帯域／認証を点検

ディスク水位（Docker レイヤ）

指標	警告	スロットル	停止・清掃
データボリューム使用率	≥ 78〜80%	≥ 85% で新規大容量 pull キュー	≥ 90%：ジョブ延期＋docker system prune 方針実行
空き容量（絶対）	< 25 GB	< 12 GB	< 6 GB：イメージ LRU 削除
ディスク await	> 15 ms が 5 分継続	> 40 ms	> 80 ms：並列取得を半減

コマンドはプレースホルダのまま Runbook 化し、実値はシークレット注入。

# 1) 認証（GHCR 例）
printf '%s' "${GITHUB_TOKEN_PLACEHOLDER}" | docker login ghcr.io -u "${GITHUB_ACTOR_PLACEHOLDER}" --password-stdin

# 2) 私有 Registry 例
printf '%s' "${REGISTRY_TOKEN_PLACEHOLDER}" | docker login "${REGISTRY_HOST_PLACEHOLDER}" -u "${REGISTRY_USER_PLACEHOLDER}" --password-stdin

# 3) 取得（ダイジェスト固定推奨）
docker pull "ghcr.io/${ORG_PLACEHOLDER}/${IMAGE_PLACEHOLDER}@${DIGEST_PLACEHOLDER}"

# 4) 失敗時の擬似リトライ（シェル／CI step 用プレースホルダ）
for i in 1 2 3 4; do
  docker pull "${IMAGE_REF_PLACEHOLDER}" && break
  case "$i" in 1) sleep "${BACKOFF_SEC_1_PLACEHOLDER:-4}";; 2) sleep "${BACKOFF_SEC_2_PLACEHOLDER:-12}";; 3) sleep "${BACKOFF_SEC_3_PLACEHOLDER:-30}";; *) sleep "${BACKOFF_SEC_4_PLACEHOLDER:-90}";; esac
done

Q. レイヤ停滞／認証切れ
A. 並列取得を下げ、docker login を pull 直前へ。プロキシ idle timeout も確認。

Q. 証明書とプロキシ
A. x509 は社内 TLS 検査が多い→ルート CA 配布。プロキシのみ失敗は HTTP(S)_PROXY／NO_PROXY と daemon／CI の二重指定を点検。

Q. 401 と digest 不一致
A. 401 はスコープ不足か期限切れ。read:packages 相当とローテ時刻を再確認。digest 不一致はタグ側の更新に追随し、再現性が要るなら解決済み digest 固定を CI に記録。

安定は並列・TTL・退避・ディスクの同時設計。主軸は認証境界と429 頻度で表に寄せるのが実務的です。