Ubuntu 26.04 で内部向けの Docker registry を用意するための基本設定を整理します。ここでは Harbor のような統合レジストリ基盤ではなく、Ubuntu package の docker-registry を使い、TLS と basic 認証を有効にした最小構成を扱います。
内部 registry は、検証用 image、社内向け base image、Kubernetes や Docker ホストへ配布する image を置くための土台です。ただし、単に registry:2 を動かすだけでは、認証、TLS、保存先、backup、削除と garbage collection の扱いが曖昧になります。
書籍
Docker の基本操作、イメージ、コンテナ、開発環境構築を確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
Docker registry と Harbor の違い
docker-registry は、Docker Distribution を使ったシンプルなコンテナレジストリです。image の push / pull を受け付ける最小機能に近く、構成を把握しやすい一方で、UI、project 管理、脆弱性 scan、replication、細かい権限管理などは持ちません。
| 項目 | docker-registry | Harbor |
|---|---|---|
| 位置づけ | 軽量な registry 本体 | 統合型の private registry 基盤 |
| UI | 基本なし | あり |
| 認証・権限 | basic 認証などを自分で構成 | project / user / robot account などを管理 |
| 脆弱性 scan | 別途設計 | 機能として統合しやすい |
| 用途 | 小規模・内部配布・検証用 | 組織的な image 管理、Kubernetes 基盤 |
最初から Harbor を入れると構成要素が増えます。まず registry の基本を理解し、image を保存する場所、TLS、認証、client 側の信頼設定を確認しておくと、Harbor を使う場合にも責務が見えやすくなります。
package をインストールする
Ubuntu 26.04 では docker-registry package を導入できます。container として registry:2 を起動する方法もありますが、ここでは OS service として管理する形にします。
sudo apt update
sudo apt install -y docker-registry
systemctl status docker-registry.serviceservice 名は docker-registry.service です。package 管理に寄せると、systemd、設定ファイル、保存先 directory の位置が Ubuntu 側の標準に沿います。
保存先と設定ファイルを確認する
Ubuntu の docker-registry では、設定ファイルと保存先を分けて管理します。まず現在の配置を確認します。
sudo ls -ld /etc/docker/registry
sudo ls -ld /var/lib/docker-registry
sudo sed -n '1,220p' /etc/docker/registry/config.yml| 項目 | 標準的な場所 |
|---|---|
| 設定 directory | /etc/docker/registry |
| 設定ファイル | /etc/docker/registry/config.yml |
| htpasswd | /etc/docker/registry/.htpasswd |
| storage | /var/lib/docker-registry |
| 待ち受け port | 5000/tcp |
保存先の /var/lib/docker-registry は、image layer と metadata を持つ重要な領域です。registry の backup を考える場合は、この directory と設定ファイル、認証情報、証明書をまとめて扱う必要があります。
TLS 証明書を用意する
内部 registry であっても、Docker client から利用するなら TLS を前提にした方が扱いやすくなります。内部 CA で発行した証明書を使う場合は、Docker client 側にも CA 証明書を信頼させます。
sudo install -d -m 0755 /etc/docker/registry/tls
sudo install -m 0644 registry.example.internal.crt /etc/docker/registry/tls/server.crt
sudo install -m 0640 registry.example.internal.key /etc/docker/registry/tls/server.key
sudo chgrp docker-registry /etc/docker/registry/tls/server.key証明書の CN / SAN は、client がアクセスする registry の FQDN と一致させます。IP address でアクセスする運用にすると、証明書検証、名前解決、将来の移設が面倒になりやすいため、内部 DNS 名を決めておく方が自然です。
basic 認証を用意する
最小構成では、htpasswd を使って basic 認証を設定できます。次は管理用ユーザーを作る例です。
sudo apt install -y apache2-utils
sudo htpasswd -Bbc /etc/docker/registry/.htpasswd admin
sudo chown root:root /etc/docker/registry/.htpasswd
sudo chmod 0644 /etc/docker/registry/.htpasswd公開記事では例として admin を使っていますが、実運用では用途別のアカウントに分けた方がよいです。CI/CD 用、管理者用、検証用を同じ認証情報にすると、漏えい時の切り分けが難しくなります。
config.yml を設定する
/etc/docker/registry/config.yml で、storage、HTTP 待ち受け、TLS、basic 認証、health check を設定します。次は内部向け registry の最小例です。
sudo tee /etc/docker/registry/config.yml >/dev/null <<'EOF'
version: 0.1
log:
fields:
service: registry
storage:
cache:
blobdescriptor: inmemory
filesystem:
rootdirectory: /var/lib/docker-registry
delete:
enabled: true
http:
addr: :5000
headers:
X-Content-Type-Options:
- nosniff
tls:
certificate: /etc/docker/registry/tls/server.crt
key: /etc/docker/registry/tls/server.key
auth:
htpasswd:
realm: basic-realm
path: /etc/docker/registry/.htpasswd
health:
storagedriver:
enabled: true
interval: 10s
threshold: 3
EOFdelete.enabled を有効にしても、不要 layer が即座に消えるわけではありません。tag 削除、manifest 削除、garbage collection の扱いは別途確認が必要です。registry は「置き場」ですが、放置すると storage が増え続けるため、保存期間と削除方針を決めておきます。
service を起動する
設定ファイルと証明書、認証ファイルを配置したら、service を再起動して有効化します。
sudo systemctl restart docker-registry.service
sudo systemctl enable docker-registry.service
systemctl status docker-registry.service
ss -ltnp | grep ':5000'5000/tcp が待ち受けていることを確認します。外部公開するものではなく、Docker host、Kubernetes node、CI/CD runner など、必要な network からだけ到達できるようにします。
login / push / pull を確認する
client 側で内部 CA を信頼できている前提で、registry へ login し、image の tag 付け、push、pull を確認します。
docker login registry.example.internal:5000
docker pull alpine:latest
docker tag alpine:latest registry.example.internal:5000/library/alpine:latest
docker push registry.example.internal:5000/library/alpine:latest
docker pull registry.example.internal:5000/library/alpine:latestここで重要なのは、registry サーバー側だけでなく、client 側の証明書信頼と名前解決も含めて確認することです。registry の TLS 証明書が正しくても、client が内部 CA を信頼していなければ push / pull は失敗します。
運用で確認すること
内部 registry は一度作ると、CI/CD や Kubernetes の image 配布経路に入ります。止まると build や deploy に影響するため、単なる検証用 container ではなく、運用対象として扱う必要があります。
- storage 使用量を監視する
- 証明書の期限を管理する
- basic 認証のアカウントを用途別に分ける
- push できる network を制限する
- backup と restore の手順を用意する
- 不要 image の削除と garbage collection を設計する
- Kubernetes node や CI/CD runner から pull できることを確認する
registry は「動けばよい」ではなく、image の配布経路です。アプリケーションや Kubernetes の復旧時に必要になるため、backup、証明書、認証、到達性をまとめて確認できる状態にしておく方が安全です。
まとめ
Ubuntu 26.04 で内部向け Docker registry を作る場合、docker-registry package を使うと、/etc/docker/registry/config.yml、/var/lib/docker-registry、docker-registry.service を中心に OS service として管理できます。
最小構成でも、TLS、basic 認証、storage、client 側の CA 信頼、push / pull の確認は外せません。Harbor を使う場合でも、内部 registry が何を担い、どこに image を保存し、どの client が pull するのかという責務は同じです。


