Docker プライベートレジストリは、コンテナイメージを内部で配布するための仕組みです。
単に registry コンテナを起動するだけなら簡単です。しかし、実運用では「どこからイメージを取得するのか」「誰が push できるのか」「TLS と認証をどう扱うのか」「閉域環境でどう配布するのか」を考える必要があります。
この記事では、Docker のプライベートレジストリを、外部接続を減らし、内部のイメージ配布基盤を作るための設計として整理します。
プライベートレジストリを置く意味
Docker Hub などの外部レジストリからイメージを取得できる環境では、最初は内部レジストリの必要性が見えにくいかもしれません。
しかし、サーバー台数が増えたり、閉域環境や proxy 制約のある環境を扱ったり、自作イメージを配布したりする場合、外部レジストリだけに依存する構成は扱いづらくなります。
| 目的 | 意味 |
|---|---|
| 内部配布 | 自作イメージを社内・検証環境・クラスタ内へ配布する |
| 外部接続の削減 | 各ノードが毎回 Docker Hub へ取りに行く構成を避ける |
| 閉域環境対応 | インターネット非接続環境でもイメージを配布する |
| 再現性 | 使用するイメージのバージョンと取得元を固定しやすくする |
| 運用管理 | push / pull、認証、削除、保管期間を管理する |
つまり、プライベートレジストリは単なる Docker の補助機能ではなく、コンテナ運用における配布基盤です。
registry コンテナで最小構成を確認する
最小構成であれば、Docker の公式 registry:2 イメージを使って動作を確認できます。
docker pull registry:2
docker run -d --name registry -p 5000:5000 registry:2
docker psこの構成では、ローカルホストの 5000 番ポートでレジストリが待ち受けます。検証用途としては分かりやすいですが、このまま本番運用に使うべきではありません。
理由は、TLS、認証、永続化、バックアップ、削除ポリシー、アクセス制御が不足しているためです。
push / pull の流れ
レジストリへイメージを登録するには、対象イメージに内部レジストリ向けの tag を付けて push します。
docker pull nginx:latest
docker tag nginx:latest localhost:5000/nginx:latest
docker push localhost:5000/nginx:latest
docker pull localhost:5000/nginx:latestここで重要なのは、イメージ名にレジストリの場所が含まれることです。localhost:5000/nginx:latest は、Docker Hub の nginx:latest とは別の参照です。
内部レジストリを使う場合、どのイメージをどの名前で配布するのか、名前付けのルールも設計対象になります。
本番利用で必要になる要素
検証用の registry コンテナと、本番で使う内部レジストリは分けて考えるべきです。
| 要素 | 考えること |
|---|---|
| TLS | レジストリの通信を HTTPS にする |
| 認証 | 誰が push / pull できるかを制御する |
| 永続化 | イメージデータを volume や外部ストレージに保存する |
| バックアップ | レジストリ破損時に復旧できるようにする |
| 削除・保管 | 古い tag や不要イメージをどう扱うか決める |
| ログ | 誰が push / pull したかを確認できるようにする |
| 脆弱性管理 | 必要に応じてスキャンや署名を検討する |
特に TLS と認証は重要です。検証用なら HTTP でも動作確認できますが、複数ホストから利用する内部レジストリでは、平文通信や無認証 push は避けるべきです。
閉域環境では内部レジストリが重要になる
インターネット非接続環境や proxy 制約のある環境では、内部レジストリの重要性が上がります。
各サーバーや Kubernetes node が外部レジストリへ直接 pull できない場合、必要なイメージをあらかじめ内部レジストリへ持ち込み、そこから配布する構成が必要になります。
この時、内部レジストリは単なるキャッシュではありません。閉域環境でコンテナ基盤を成立させるための配布元になります。
- 外部から取得するイメージを事前に選定する
- 取得したイメージを内部レジストリへ登録する
- 利用する tag を固定する
- 更新時の持ち込み手順を決める
- 不要イメージの削除方針を決める
ここを設計しないと、構築時は動いても、更新や再構築のたびに外部接続の問題で止まります。
Docker registry と Harbor の違い
単純な Docker registry は、イメージを保存して配布するための最小限の仕組みです。軽く、検証しやすく、内部レジストリの基本を理解するには向いています。
一方で、運用基盤として使うなら Harbor のようなレジストリ製品を検討する場面もあります。
| 項目 | Docker registry | Harbor |
|---|---|---|
| 用途 | 軽量なイメージ保存・配布 | 組織向けレジストリ運用 |
| 認証・権限 | 別途設計が必要 | プロジェクト、ユーザー、権限を管理しやすい |
| UI | 基本的になし | Web UI あり |
| 脆弱性管理 | 外部機能と組み合わせる | スキャン連携などを扱いやすい |
| 運用規模 | 小規模・検証向け | チーム・クラスタ・閉域運用向け |
最初に registry で仕組みを理解し、運用要件が増えたら Harbor を検討する、という整理が自然です。
イメージ名と tag の運用を決める
内部レジストリを使う場合、イメージ名と tag の運用も重要です。
latest を多用すると、再構築時に同じものが使われるとは限りません。検証環境なら許容できても、本番や閉域環境では再現性が落ちます。
少なくとも、次のようなルールを決めておくべきです。
- 本番で使う image tag は固定する
- 外部イメージを内部名へ mirror するルールを決める
- 自作イメージと外部 mirror イメージを namespace で分ける
- 古い tag をいつ消すか決める
- 更新前後で rollback できる状態にする
内部レジストリは、イメージを置く場所であると同時に、コンテナ運用の再現性を支える場所でもあります。
まとめ
Docker プライベートレジストリは、コンテナイメージを内部で配布するための基盤です。
検証だけなら registry:2 を起動するだけでも動作を確認できます。しかし、実運用では TLS、認証、永続化、バックアップ、tag 運用、削除方針、ログ、脆弱性管理まで考える必要があります。
特に閉域環境や Kubernetes 基盤では、内部レジストリは外部接続を減らすための補助ではなく、イメージ配布の中心になります。
Docker registry は仕組みを理解する入口として便利です。一方で、組織的な運用、権限管理、スキャン、Web UI、チーム利用まで考えるなら Harbor のような製品も検討対象になります。
重要なのは、レジストリを立てることではありません。どのイメージを、どこから取得し、誰が登録し、どの環境へ配布し、どう更新するのかを決めることです。
関連する記事
- GROWI の外部接続設計 – プロキシ、プラグイン、閉域運用を分けて考える
- Harbor プライベートコンテナレジストリ構築 – Kubernetes / Docker 向け内部レジストリを用意する
- Docker プロキシ設定 – systemd drop-in で daemon に proxy を設定する
