手当たり次第に書くんだ

飽きっぽいのは本能

Ubuntu 26.04 Docker registry の基本設定 – 内部コンテナレジストリを用意する

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 の扱いが曖昧になります。

Ubuntu 26.04 コンテナ基盤の関連記事

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.service

service 名は 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
待ち受け port5000/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
EOF

delete.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-registrydocker-registry.service を中心に OS service として管理できます。

最小構成でも、TLS、basic 認証、storage、client 側の CA 信頼、push / pull の確認は外せません。Harbor を使う場合でも、内部 registry が何を担い、どこに image を保存し、どの client が pull するのかという責務は同じです。

Ubuntu 26.04 コンテナ基盤の関連記事
Ubuntu 26.04 Docker registry の基本設定 – 内部コンテナレジストリを用意する

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

トップへ戻る