コンテナレジストリ自宅構築｜Harbor・registry運用

現代のソフトウェア開発において、コンテナイメージはデプロイメントの中核を担っていますが、そのライフサイクル管理とセキュリティ確保は依然として多くの現場にとって大きな課題です。特にパブリックなレジストリ（例：Docker Hub）に依存することは、データガバナンスや潜在的なセキュリティリスクの観点から懸念が生じています。企業が求めるコンプライアンスレベルを維持するためには、自社ネットワーク内に完全にコントロールされたイメージ保管場所を持つ「セルフホスト・レジストリ」が不可欠となっています。

単にイメージを保存するだけでなく、利用される前に脆弱性スキャン（例：TrivyによるCVEチェック）、適切な認証基盤との連携（LDAPやOIDCなど）、そしてストレージ容量の最適化（ガーベージコレクション：GC）といった高度な運用機能が求められます。これらの機能を個別に組み合わせて構築するのは非常に複雑であり、専門的な知識が必要です。

本稿では、エンタープライズレベルのセルフホスト・レジストリとして実績のあるHarborを主軸に、その構築から実運用までを徹底解説します。具体的には、単なるイメージ格納機能を超えた、脆弱性スキャンパイプライン（CI/CD統合）、マルチテナント対応のためのアクセス制御設計、そして長期的なストレージ管理における効率的なGC戦略について掘り下げます。

例えば、レジストリの運用において、数百GBから数TBに及ぶイメージデータが蓄積されると、不要なレイヤーや古いタグによる肥大化は避けられません。これを防ぐために、どのタイミングでどのようなポリシー（例：30日以上アクセスがないイメージを自動削除）に基づきGCを実行するのか、その設計ノウハウを提供します。また、複数のデータセンター間でのレジストリ同期を行うためのレプリケーション戦略や、堅牢な認証機構の実装方法など、実用的なスペックと具体的な設定手順を網羅し、読者が即座にPoC（概念実証）に着手できるレベルの知見を提供することを目指します。

セルフホストコンテナレジストリの全体像とアーキテクチャ設計思想

セルフホスト型のコンテナレジストリを自社環境に構築する目的は、単なるイメージの保管場所以上の価値を得ることにあります。特にセキュリティポリシーが厳格な金融機関や産業制御システム（ICS）関連の企業において、外部クラウドベンダーへのデータ送出を極力排除し、サプライチェーン全体でコントロールできる「信頼性の担保」を実現することが最大の動機となります。ここでは、レジストリがどのような役割を果たし、どのようなアーキテクチャ要素から構成されるのかという基礎的な理解から解説します。

コンテナレジストリとは、DockerやOCI（Open Container Initiative）規格に準拠したコンテナイメージの保管庫です。単なるファイルサーバーではなく、「どのレイヤー（層）が、どのハッシュ値で、誰によってプッシュされたか」というメタデータ管理と整合性検証を行うデータベース機能を持っています。例えば、my-app:v1.0 というタグが付与されていても、内部的には複数の不可変なイメージレイヤー（例：ベースOSのカーネル層、ライブラリ依存関係層、アプリケーションバイナリ層）がハッシュ値によって管理されています。クライアントがイメージをプルする際、レジストリはこれらのレイヤー群を一貫したセットとして提供します。

理想的なセルフホスト環境では、最低限以下のコンポーネントが必要となります。

1. レジストリエンジン: イメージの取り込み・配信を行うコアサービス（例: Docker Registry API v2）。
2. ストレージバックエンド: イメージレイヤーデータの実体を保持する高速な永続ストレージ層。ここでは、単なるローカルファイルシステムではなく、高耐久性を持つオブジェクトストレージ互換層（S3 API対応など）の利用が推奨されます。
3. 認証認可機構 (AuthN/AuthZ): レジストリへのアクセスを制御する仕組みです。LDAPやOAuth 2.0などの外部IDプロバイダと連携し、ロールベースアクセス制御（RBAC）を実装します。

アーキテクチャの選択肢は多岐にわたりますが、最も堅牢で機能的なバランスを持つのは「Harbor」を利用したスタック構築です。Harborは単なるレジストリの実装ではなく、認証、脆弱性スキャン、ポリシー管理、UI提供など、運用に必要な周辺機能を包括的にパッケージ化している点が最大の特徴です。

初期導入を考慮した場合でも、本番環境での利用を見据え、ストレージは最低限のRAID構成ではなく、分散型のオブジェクトストレージソリューション（例：CephやMinIOを利用したS3互換バケット）を採用することがパフォーマンスと耐久性の観点から必須となります。特にイメージプッシュ時のレイヤー書き込み速度がボトルネックになりやすいため、ディスクI/O性能を最優先で設計する必要があります。

主要製品の比較検討：Harbor vs. Docker Registry + 独自実装戦略

セルフホストレジストリの選択肢は大きく分けて「オールインワンパッケージを利用する」方法と、「コア機能のみを利用し、周辺機能を自力または組み込みサービスで補完する」方法があります。この観点から、代表的なHarborと標準Docker Registry API v2を比較検討します。

Harbor (JFrog) の優位性：運用機能のパッケージ化

Harborは、レジストリというコア機能に加えて、「セキュリティ」「可用性」「使いやすさ」という3つの側面で圧倒的な利点を提供しています。最大の強みは、脆弱性スキャン（TrivyやClair連携）、イメージポリシー管理（どのタグが本番環境にプッシュできるかなど）、そしてガベージコレクション（GC）の運用自動化までを一つのプラットフォーム上で完結できる点です。

具体的な構成要素として、Harborは以下のコンテナ群で動作します：

1. harbor-core: レジストリ本体とAPI提供。
2. harbor-redis: メタデータストア（キャッシュ）。高速な読み書きが求められます。
3. harbor-database: PostgreSQLやMySQLなど、永続的なメタ情報管理に使用されます。

初期構築の容易性、そして特にセキュリティスキャン機能の組み込み深度は非常に高く評価されています。例えば、HarborにTrivyを連携させる場合、イメージがプッシュされるたびに自動的にスキャンが走査され、CVE（Common Vulnerabilities and Exposures）情報に基づいてスコアリングが行われ、ポリシー違反の場合は「本番タグへの昇格」を阻止できます。このプロセスは、手動で複数のツール群をパイプライン化する手間とコストを大幅に削減します。

Docker Registry v2 + 独自実装戦略のメリット・デメリット

単にDocker Registry API v2のみを利用し、他の機能を自前で組み込むアプローチも理論上可能です。これは、極限まで軽量な環境を求めたり、非常にニッチなカスタム認証ロジックが必要な場合に検討されます。

しかし、この方法には重大な落とし穴が存在します。

1. 脆弱性スキャン: レジストリ自体はスキャナ機能を持たないため、Trivyなどの外部スクリプトを別途実行し、その結果をデータベースに手動で記録・管理する仕組み（カスタムDBレイヤー）を構築しなければなりません。この実装工数が非常に大きくなります。
2. ガベージコレクション (GC): レジストリは時間経過とともに不要な中間イメージや古いタグの参照が残存し、ストレージ容量を圧迫します。HarborのようなシステムではGCプロセスが組み込まれ、どのレイヤーが本当に参照されているかを正確に判断して削除しますが、独自実装の場合、この「参照カウンティング」ロジックを自前で完璧に組むのが極めて困難です。

結論として、技術的な複雑性や将来的な保守性を考慮すると、機能の網羅性と堅牢な運用の自動化を実現しているHarborのような統合プラットフォームを利用することが、コストパフォーマンスとリスク低減の両面から最も推奨されます。

実装における落とし穴：データ管理、認証、レプリケーション戦略の詳細解説

セルフホスト型レジストリの構築において、「動くこと」はゴールではありません。「堅牢で、拡張可能で、運用が容易であること」が真のゴールです。特に注意が必要なのが、ストレージの参照整合性（GC）、多拠点展開のためのレプリケーション、そして強固な認証機構の実装点です。

1. ガベージコレクション (Garbage Collection: GC) の落とし穴

コンテナイメージはレイヤー構造を持つため、単に「タグ」を削除しただけでは、そのタグが参照していた巨大なデータブロック（レイヤーファイル）がすぐに消去されません。他のタグや別のサービスで利用されている可能性があります。GCの役割は、「現在どのタグも参照していない、孤立したイメージレイヤー」のみを安全にストレージから物理的に削除することです。

このプロセスにおいて最も難しいのが「真の参照カウンティング」です。Harborのような成熟したシステムでは、レジストリがメタデータを管理し、どのハッシュ値を持つ層が生きているかを正確に把握しています。もし自前で実装する場合、単なるファイルシステム上の最終アクセス時刻に基づく削除は誤動作を招きやすく、データ消失のリスクがあります。

GCのための推奨ストレージ設計:

• バックエンド: MinIOやCephFSといったS3互換のオブジェクトストレージを利用し、レイヤーファイルを「不可変（Immutable）」に書き込む運用ルールを徹底します。これにより、意図しない上書きや削除を防ぎます。
• 管理: ストレージ上のデータ構造とレジストリエンジン内のメタデータを同期させるための専用のバッチ処理ジョブ（例：Kubernetes CronJob）を定期実行し、参照カウントがゼロになったオブジェクト群のみをMark-and-Sweep方式で物理削除するのがベストプラクティスです。

2. 高可用性 (HA) とレプリケーション戦略

単一障害点（SPOF: Single Point of Failure）は絶対に避けるべきです。コンテナレジストリは、最低でも以下のレイヤーで高可用性を確保する必要があります。

• サービス層 (Web/API): N+1またはN+2の冗長構成とし、ロードバランサー（例：HAProxyやNGINX）を経由してトラフィックを分散します。各ノードはDocker SwarmやKubernetesクラスタ上でデプロイし、ヘルスチェックに基づいた自動フェイルオーバーが機能することが必須です。
• メタデータ層 (DB): PostgreSQLなどのリレーショナルデータベースを使用する場合、ストリーミングレプリケーション（例：PostgreSQLのWALベース）を用いて最低2台以上の同期ノードを構成します。RPO（目標復旧時点）をゼロに近づけるため、待機スタンバイ構成が必須です。
• データ層 (Object Storage): オブジェクトストレージ自体が耐障害性を持つことが求められます。Cephの場合、複数のアベイラビリティゾーン（AZ）にわたってデータを分散配置し、ノードの故障に備えた十分なレプリカ数（例：3レプリカ）を維持することが重要です。

3. 強固な認証・認可 (AuthN/AuthZ) の組み込み

単なるユーザー名とパスワードによる認証は不十分です。組織的な利用においては、IdP（Identity Provider）との連携が必須であり、OpenID Connect (OIDC) やSAMLといった業界標準のプロトコルを採用すべきです。

Harborなどのシステムは通常、Keycloakや自社LDAPサーバーをバックエンドとして組み込みます。これにより、「誰が」「どのリポジトリに対して」「どのような操作（プッシュ/プル/削除）」を行う権限があるかを厳密に制御できます。例えば、「開発チームAのユーザー」から「本番ブランチ用のイメージ」への直接プッシュは禁止し、必ずCI/CDパイプラインを経由させるといったポリシーを実装することがセキュリティ上非常に重要です。

認証・認可フロー（推奨）:

1. クライアントがKeycloakにOIDCトークンを提示。
2. Keycloakがユーザーのアイデンティティとロール情報を検証し、JWT (JSON Web Token) を発行。
3. レジストリエンジン（Harbor Core）はこのJWTを受け取り、内部のRBACポリシーに基づいてAPIアクセス可否を判断する。

パフォーマンスチューニングとコスト最適化：ハードウェア選定と運用設計指針

セルフホストレジストリは、単に動かすだけでなく、「どのくらいの負荷がかかっても安定して動作し、かつTCO（Total Cost of Ownership）が低い」ように設計する必要があります。パフォーマンスのボトルネックは、通常「I/O性能」「CPUのスケーラビリティ」「メモリ帯域幅」のいずれかに集中します。

1. ハードウェア選定：ストレージとネットワークを最優先に

レジストリのワークロードにおいて最もクリティカルなのはディスクI/Oです。イメージプッシュは大量の小〜中サイズのレイヤーファイルを連続的に書き込む（Write-heavy）操作であり、これは高いランダムIOPS性能を要求します。

推奨ハードウェア構成例（ミドルスケール：年間10TB以上のデータ増加を見込む場合）：

• サーバーCPU: AMD EPYC Genoa (96コア/128スレッド以上)。多数のコンテナサービスやバックグラウンドジョブが動くため、高いコア数とPCIeレーンの多さが有利です。TDP（熱設計電力）は300W〜500Wクラスを想定します。
• メモリ: 128GB DDR5-4800以上。メタデータ管理やキャッシュがメモリに乗りやすいため、十分な帯域幅が必要です。
• ストレージ (オブジェクト層): NVMe SSD（PCIe Gen4/Gen5）を最低でも8TB以上の容量で構成し、RAID 10または分散型アレイとして利用します。単なるSSDではなく、「ランダムライト性能」が極めて高い製品を選定してください。（例：Samsung PM1733やMicron 7xxxシリーズなど、エンタープライズ向けモデル）。
• ストレージ (DB層): 高速なNVMe SSDを搭載した専用の小容量アレイ（500GB〜1TB）で十分です。

2. パフォーマンスボトルネック解消のためのチューニングポイント

A. I/O性能の最適化

データ取り込みが遅い場合、最も疑うべきはストレージ層とファイルシステムのマッピングです。

• カーネル設定: vm.dirty_ratioやvm.dirty_background_ratioなどの仮想メモリパラメータを、利用するSSDのアレイサイズに合わせて適切にチューニングする必要があります。デフォルト値では書き込みバッファがすぐに飽和し、パフォーマンスが急激に低下することがあります。
• ファイルシステム: XFSやZFSなど、大規模なデータセットと高いI/O性能を持つファイルシステムを採用します。

B. キャッシュ機構の最適化

Harborなどのレジストリは、頻繁にアクセスされるメタデータ（どのタグがどのレイヤーを参照しているか）をRedisなどのインメモリキャッシュ層に保持します。このキャッシュが適切に機能することが体感速度に直結するため、Redisサーバー自体にも十分な搭載メモリ（最低32GB以上）と高速なCPUコアの割り当てが必要です。

3. TCO（総所有コスト）に基づく運用設計

自社でレジストリを構築する場合、初期ハードウェア費用だけでなく、「人件費」「電力消費」「ライセンス維持費」も含めたTCOでの比較が重要です。

本質的に、「最高のコントロール権」と「長期的なデータ主権」が求められる場合は、初期投資が高くてもセルフホスト型プラットフォーム（Harborなど）を選択するのが最も経済的です。適切なハードウェア選定（特にNVMeベースのストレージアレイ）を行うことで、サービス品質を維持しつつ、運用コストを最適化することが可能です。

総合比較表：レジストリ実装に必要な技術スタックと難易度

主要なレジストリ選択肢および周辺ツールの徹底比較

自宅環境でセルフホスト型コンテナレジストリを構築する場合、単にイメージを保存できる場所を選ぶだけでなく、「どのツールが」「どのような機能（脆弱性スキャン、認証、高可用性）を」「どれだけの負荷とコストで」提供してくれるのかという視点が極めて重要になります。市場にはDocker Registry APIに準拠したレジストリや、より包括的なプラットフォームを提供する製品群が存在します。本セクションでは、主要なソフトウェア選択肢、必須の周辺ツール（スキャナー、データベース）、およびそれらを稼働させるためのハードウェア要件について多角的に比較分析を行います。

まず注目すべきは、レジストリ自体の機能と規模です。単なる「保存庫」で満足できるか、あるいはCI/CDパイプラインに深く組み込む必要があるかで選択肢が大きく分かれます。Harborのようなオールインワンソリューションは設定の手間を減らしますが、その分動作するコンポーネントが増えるためリソース要求が高くなります。一方、Docker Registry単体での運用は軽量ですが、脆弱性スキャンやUI/UXの構築をすべて自前で行う工数が求められます。

1. コンテナレジストリソフトウェア機能・スペック比較（2026年版）

この表から分かる通り、単にレジストリ機能を提供するという点ではDocker Registryが最も軽量ですが、運用負荷は最大です。一方、HarborやJFrog Artifactoryといった統合プラットフォームは、初期投資（特にメモリとCPU）は大きいものの、その分必要な機能をパッケージ化しており、開発工数を大幅に削減できます。自宅環境でのPoC段階であれば、リソース効率の良いGitLabやNexusも検討に値しますが、フル機能を目指すならばHarborの導入が最もバランスが良い結果となることが多いです。

2. コンテナ脆弱性スキャナー性能・対応言語比較

自宅環境で運用する場合、リソース効率と検出のバランスから、TrivyやGrypeのような軽量かつ高速なオープンソースツールをレジストリに組み込むのが最も現実的です。特にTrivyは、Docker CLI経由でのシームレスな実行が可能であり、メモリ使用量も抑えられるため、自宅サーバー（例：Intel N100搭載の小型PCなど）でも安定して運用できます。

3. ストレージバックアップとレプリケーション方式比較

自宅での高可用性を実現する場合、「Raft Consensus」を利用したクラスタ構成が最も堅牢ですが、複数のノード（例：Raspberry Pi 4またはNUCなど）を構築し、それらの間で安定したネットワーク接続と適切なストレージ同期を設定する知識が必要です。予算や電力消費を考慮すると、まず「Object Storage Sync」（MinIOなどを利用してバックアップ先を用意する）から始めるのが最もコストパフォーマンスに優れていると言えます。

4. ハードウェア要件と初期構築コスト比較（自宅サーバー向け目安）

自宅環境で最もバランスが取れ、かつ十分なスペックを持つのは、「個人開発・小規模チーム」レベルのNUCや小型タワー型PCを利用する構成です。特にストレージはSSDのみに頼らず、OS領域とデータレジストリ領域を物理的に分離し、RAIDまたはZFSなどのファイルシステム機能でデータの信頼性を高めることが重要となります。

5. 認証・認可機能の複雑性比較（導入工数視点）

自宅環境で最も現実的かつセキュリティを担保しやすいのは、「OAuth 2.0」を経由したSSO（Single Sign-On）または「LDAP同期」です。特に、開発者が増加する見込みがある場合は、Keycloakのような独立したIdPを用意し、そこからHarborや他のサービスに認証を委譲する形が最も管理工数がかさまず、セキュリティレベルも最高になります。

これらの比較を通じて、単なるレジストリの選択ではなく、「どの機能（スキャン、高可用性、認証）を」「どのコストと労力で」実現するかという視点での意思決定を行うことが重要です。PoC段階ではHarborを利用しつつ、Trivyによるスキャンを組み込み、ストレージはMinIOなどのオブジェクトストレージをバックエンドとして利用するハイブリッド構成が、自宅環境における機能性と運用コストのバランスが最も取れた理想的な選択肢となります。

よくある質問

Q1. セルフホスト型レジストリの初期導入コストはどのくらいを見積もれば良いですか？（価格・コスト系）

初期構築に必要なハードウェアとソフトウェアライセンス費を考慮すると、最低でも20万円〜50万円程度の予算が必要です。特にデータ保存容量が重要で、数テラバイト規模のイメージを保持する場合、32GB以上のECCメモリを持つサーバー（例：Dell PowerEdge R650）を推奨します。ストレージ面では、Redundant Array of Independent Disks (RAID) 構成のHDD/SSD群を用意し、最低でも10TBクラスの容量確保が望ましいです。ソフトウェアはHarbor Community Editionを利用すればライセンス費用はかかりませんが、高性能な脆弱性スキャン（Trivyなど）を頻繁に行うためのCPUリソース確保と、ネットワーク帯域の考慮が必要です。

Q2. レジストリ運用における最適なストレージ構成は何でしょうか？（価格・コスト系）

レジストリデータは読み書きが非常に多くなり、特にイメージプルやプッシュの際のI/O性能がボトルネックになりやすいです。単なる大容量HDDではなく、高速なNVM Express (NVMe) SSDをメインのメタデータストアおよびキャッシュ層に組み込むことが必須です。具体的には、PCIe Gen4対応の1TB NVMe M.2 SSDを複数のノードに分散配置し、総容量の少なくとも30%をSSDで賄う設計が理想的です。これにより、平均リード/ライト速度を最低でも500MB/s以上維持できます。

Q3. Docker RegistryとHarborのような専用ソリューションでは、機能的な違いは何ですか？（選び方・比較系）

Docker Registryは基本的なOCI仕様に基づいた単一のレジストリ機能を提供します。一方、Harborはこれをコアとしつつ、その上に高度な管理レイヤーを積み重ねたプラットフォームです。Harbor最大の強みは、「イメージ管理」「認証認可（RBAC）」「脆弱性スキャン（Trivy連携）」「ポリシーエンジン」といった多角的なセキュリティ・運用機能を統合的に提供している点にあります。単なる保管庫ではなく、CI/CDパイプラインのゲートウェイとして機能させたい場合は、Harborのような統合プラットフォームを選ぶべきです。

Q4. レジストリ間のデータレプリケーションはどのように実現するのが最も効率的ですか？（選び方・比較系）

複数のリージョンやデータセンター間でレジストリを冗長化する場合、単なる同期ではなく、レイヤードなレプリケーション戦略が必要です。Harborではネイティブにレプリカ機能がありますが、より高度な運用を目指すなら、Gitベースのレジストリバックアップと、rsyncやクラウドベンダーが提供する専用データ転送サービス（例：AWS DataSync）を組み合わせるのが堅牢です。また、レプリケーション先の帯域幅を考慮し、圧縮率の高い転送プロトコル（例：zstdによるイメージ層の差分圧縮）を利用すると、データ転送量を20%以上削減できます。

Q5. レジストリに格納された古いイメージやタグの削除（GC）はどのようなタイミングで行うべきですか？（互換性・規格系）

ガーベージコレクション（GC）はレジストリの健全性を保つために必須ですが、過度な実行は運用中のデータアクセス障害を引き起こすリスクがあります。推奨されるのは、一定期間（例：90日）にアクセス記録がないタグやレイヤーを対象とするポリシーベースの削除です。具体的には、「last-accessed」日時をトリガーとし、メモリ使用率が閾値（例：85%）を超えた際、かつ直近3週間でどのイメージへのプル/プッシュもないものから優先的に削除を実行するのが安全です。

Q6. 異なるバージョンのコンテナランタイム（Docker Engineとcontainerdなど）間で互換性の問題はありますか？（互換性・規格系）

OCI (Open Container Initiative) 仕様に準拠している限り、基本的に互換性は保たれますが、古いクライアントや特定のマイナーバージョンではレジストリのAPIエンドポイントへのアクセスで認証エラーが発生する可能性があります。例えば、Docker Engine 19.03以前のクライアントを最新版のHarbor v2.x環境から操作する場合、[OAuth 2](/glossary/oauth-2).0などの最新の認証フローに対応していないため、一時的にクレデンシャルファイルベースのアプローチに戻す必要があります。

Q7. レジストリに格納されたイメージに含まれる脆弱性スキャンはどの程度の深度が求められますか？（トラブル・運用系）

単なるパッケージ管理レベルの既知のCVEチェック（CVSS Scoreに基づくもの）では不十分です。セキュリティ要件が高い場合は、OSカーネルレベルやライブラリ間の依存関係を深堀りする「SBOM (Software Bill of Materials)」生成と、その脆弱性情報との照合が必要です。Trivyなどのスキャナーを利用する場合、最低限--severity HIGH --exit-code 1といったオプションを設定し、CVSS v3.1以上のスコアリングを行うことが必須です。

Q8. レジストリの運用負荷が高まった場合、どのコンポーネントを最初にスケールアウトすべきですか？（トラブル・運用系）

アクセスが増加するにつれてボトルネックになるのは、まず「メタデータ検索層」と「ネットワークI/O」です。物理的なストレージ容量よりも、APIコール処理を行うWebサーバーやデータベースノードのCPUコア数、およびメモリ帯域を増強することが先決です。具体的な対策として、Kubernetesクラスタ上でレジストリサービスをデプロイしている場合、Horizontal Pod Autoscaler (HPA) を設定し、CPU使用率が70%に達した時点でPod数を自動的に2〜3個増やせるように設計を見直す必要があります。

Q9. レジストリの管理・運用をクラウドネイティブな環境で行うメリットは何ですか？（将来性・トレンド系）

オンプレミス型のレジストリは初期構築コストが高く、スケーラビリティに限界があります。Kubernetes上にHarborをデプロイすることで、必要な時に即座にノードを追加し、トラフィックに応じて水平スケールアウトが可能です。これにより、年間運用費用の予測精度が上がり、ピーク時でもサービス品質（SLO）を維持できます。特に、自動スケーリングによるリソースの柔軟性は、従来の固定スペックのマシンでは実現が困難です。

Q10. レジストリ運用において、認証認可（RBAC）はどのように設計すべきですか？（将来性・トレンド系）

単に「管理者」「一般ユーザー」といったロール分けではなく、「プロジェクト単位での権限分離」を徹底することが重要です。例えば、開発チームAにはpushとpullのみを許可し、セキュリティチームBには脆弱性スキャン結果の確認とタグ付け（例：stable-v2.6）のみを許可する、といった粒度の細かい設定が求められます。Harborの場合、プロジェクトごとにメンバーを招待し、各権限を最小権限の原則に基づいて割り当てる運用設計が必要です。

まとめ

本記事を通じて解説したように、コンテナレジストリを自前で構築・運用することは、単なる「イメージの保管場所」以上の価値を持ちます。企業や研究機関といった高度なセキュリティが求められる環境において、外部サービスへの依存度を下げるとともに、組織独自のガバナンスとポリシーを適用することが最大のメリットです。

セルフホスト型のレジストリ（Harborなど）を構築し運用する上での主要な要点を改めてまとめます。

• セキュリティの確保: 独自の認証基盤（LDAPやOAuth連携など）を用いることで、アクセス権限を細かく制御できます。機密性の高いアプリケーションイメージを外部に流出させるリスクを最小限に抑えることが可能です。
• 脆弱性管理の実装: イメージプッシュ時または定期的にTrivyのような専用スキャナーを組み込むことで、OSライブラリや依存パッケージに含まれるCVE（Common Vulnerabilities and Exposures）を自動検出できます。例えば、glibcの特定のマイナーバージョンが抱える既知の脆弱性（例：CVE-2024-XXXXなど）に対し、プッシュ前に警告を発することが必須です。
• ガベージコレクション（GC）戦略: レジストリは時間とともに大量のタグやレイヤーデータが蓄積します。無制限に運用するとストレージ容量を圧迫するため、どの期間のイメージ（例：過去90日間のlatestタグ付けされたもののみ保持）を削除するかという明確なポリシーとGCジョブの設定（例えば、MinIOなどのオブジェクトストレージ層でのライフサイクル管理ルール設定）が不可欠です。
• 高い可用性とレプリケーション: 自社データセンター内で運用する場合、単一障害点（SPOF）を避けるため、複数のノードにわたるクラスター構成と、異なるリージョンやアベイラビリティゾーンへの同期（レプリケーション）設定が極めて重要です。
• ストレージ要件の計画: イメージデータはレイヤー単位で保存されるため、単なるファイル容量だけでなく、メタデータやインデックス情報も考慮する必要があります。例えば、1TBのイメージを50種類管理する場合、実際の消費ストレージは2TBを超える可能性があるため、十分な空き容量（最低でも総必要量の30%以上）を持つNASまたはオブジェクトストレージ（Ceph, MinIOなど）を選定してください。

セルフホストレジストリの構築と運用は初期投資や設定工数がかかりますが、その分得られる高い制御性とセキュリティレベルは、ミッションクリティカルなシステムを扱う上で不可欠です。まずは小規模なPoC（概念実証）環境として、2ノード構成でHarborを立ち上げ、Trivy連携とGCジョブの自動実行から試みることを推奨します。

次のステップとしては、実際に運用するイメージ群のライフサイクルに基づいたストレージ容量見積もりを行い、適切なバックエンドストレージシステム（例：NFSマウントかMinIO互換オブジェクトストレージか）を選定することに注力してください。