こんにちは！日々の開発やインフラの構築、本当にお疲れ様です。
今回は、GitLabが標準で持っている「コンテナレジストリ（GitLab Container Registry）」について、徹底的に解説していきます。
「Dockerイメージの管理、どこにしようか悩んでる…」
「AWSのECRやDocker Hubを使っているけど、権限管理や課金周りでちょっとモヤモヤする…」
「CI/CDパイプラインとイメージのビルドをもっとシームレスにつなげたい！」
そんな風に思ったことはありませんか？これをマスターすれば、コードの管理からコンテナのビルド・デプロイまでがGitLab上で綺麗に完結し、毎日の作業が劇的に楽になりますよ。
今回は、まだあまり触ったことがない初心者の方に向けて、基本概念から「これ通りやれば絶対に動く」という実践的なセットアップ、そして現場で役立つちょっとした裏技まで、優しく丁寧にガイドしていきますね。
—
1. なぜ「GitLabコンテナレジストリ」を使うのか？（ツールの役割）
コンテナレジストリとは、一言で言えば「Dockerイメージの倉庫」です。ソースコードをGitで管理するように、ビルドしたコンテナイメージを安全に保管・共有するための場所ですね。
世の中にはDocker Hubや各種クラウドのレジストリサービスがありますが、あえて「GitLab内蔵のレジストリ」を使う最大のメリットは、「コードとイメージの完全な一元化と、CI/CDとの圧倒的な親和性」にあります。
- 認証の自動化: GitLab CI/CDを実行する際、追加のパスワード設定なしで、そのパイプラインからレジストリへ安全にイメージをプッシュ（アップロード）できます。
- 権限の継承: 「このリポジトリのメンバーだけがイメージをダウンロードできる」といったアクセス権が、GitLabのプロジェクト権限と完全に連動します。
- コストと手間の削減: 別途外部サービスのアカウントや課金ルートを用意する必要がありません。
それでは早速、実際に手を動かしてその便利さを体感してみましょう！
—
2. 基礎セットアップ：プロジェクトでレジストリを有効化する
まずは、GitLab上でコンテナレジストリを使えるように設定します。と言っても、クリック数回で終わる非常に簡単な作業です。
ステップ1: レジストリ機能の有効化
1. あなたのGitLabプロジェクトのページを開きます。
2. 左側サイドメニューの [設定 (Settings)] ＞ [一般 (General)] を開きます。
3. [可視性、機能の有効化、権限 (Visibility, project features, permissions)] のセクションを展開します。
4. [コンテナレジストリ (Container registry)] のスイッチを [有効 (Enabled)] にします。
5. 画面下部の [変更を保存 (Changes save)] をクリックします。
これだけで、プロジェクトの左メニューに [Deploy] ＞ [コンテナレジストリ (Container Registry)] という項目が出現します。ここがあなたのイメージの保管庫になります。
—
3. 実践！CI/CD連携と「Hello World」動作確認
ここからが本番です。GitLab CI/CDを使って、簡単なWebアプリのDockerイメージをビルドし、自動でレジストリにプッシュするパイプラインを構築します。
プロジェクトのルートディレクトリに、以下の2つのファイルを作成してください。
① テスト用のDockerfile
超シンプルなNginxコンテナをベースにした、挨拶代わりのHTMLを表示するアプリです。
軽量なAlpine Linux版Nginxを使用
FROM nginx:alpine
独自の「Hello World」ページを配置
RUN echo “Hello from GitLab Container Registry! 🚀” > /usr/share/nginx/html/index.html
ポート80番をオープン
EXPOSE 80
② CI/CD設定ファイル：`.gitlab-ci.yml`
GitLab CI/CDの魔法の呪文です。GitLabが用意してあらかじめ設定してくれている環境変数（`$CI_REGISTRY` など）を使うことで、面倒なパスワードのハードコーディングをせずに安全にログイン＆プッシュができます。
パイプラインで使用するステージを定義
stages:
- build
Dockerイメージをビルドしてレジストリにプッシュするジョブ
build_image:
stage: build
image: docker:24.0.5 # Dockerコマンドを実行するためのコンテナ環境
services:
- docker:24.0.5-dind # Docker in Docker (dind): コンテナ内でDockerを使うためのお供
script:
# 1. GitLabの内蔵レジストリにログイン
# $CI_REGISTRY_USER と $CI_REGISTRY_PASSWORD はGitLabが自動で用意してくれます
- echo “Logging in to GitLab Container Registry…”
- docker login -u “$CI_REGISTRY_USER” -p “$CI_REGISTRY_PASSWORD” $CI_REGISTRY
# 2. Dockerイメージのビルド
# $CI_REGISTRY_IMAGE は「registry.gitlab.com/ユーザー名/プロジェクト名」の自動変数です
- echo “Building Docker image…”
- docker build -t $CI_REGISTRY_IMAGE:latest .
# 3. ビルドしたイメージをGitLabコンテナレジストリへプッシュ
- echo “Pushing image to registry…”
- docker push $CI_REGISTRY_IMAGE:latest
# このジョブを実行する条件（mainブランチへのプッシュ時のみ）
rules:
- if: ‘$CI_COMMIT_BRANCH == “main”‘
動作確認の手順
1. 上記の `Dockerfile` と `.gitlab-ci.yml` をプロジェクトの `main` ブランチにコミット＆プッシュします。
2. GitLabの画面に戻り、左メニューの [ビルド (Build)] ＞ [パイプライン (Pipelines)] を開きます。
3. パイプラインが「Running」になり、やがて「Passed（緑色）」になるのを確認します。
4. 左メニューの [デプロイ (Deploy)] ＞ [コンテナレジストリ (Container Registry)] を覗いてみてください。
✨ おめでとうございます！ そこに `latest` タグのついたあなただけのDockerイメージが鎮座しているはずです。これが、GitLab CI/CDとレジストリの最も美しくセキュアな連携フローです。
—
4. 現場で役立つ！知っておくべき「2つの裏技・重要設定」
さて、基本ができるようになったところで、現場の運用で絶対に直面する「容量枯渇問題」と「セキュリティ」に関する極意を伝授します。
① イメージの自動クリーンアップポリシー（ストレージ肥大化を防ぐ）
CI/CDを回しまくると、あっという間にレジストリが何百GBもの古いイメージで埋め尽くされ、GitLabのストレージ容量制限を圧迫します。「手動で消す」なんてナンセンスな作業は自動化しましょう。
設定方法:
1. プロジェクトの [設定 (Settings)] ＞ [パッケージとレジストリ (Packages and registries)] を開きます。
2. [クリーンアップポリシー (Cleanup image XXXXXXXXX)] のセクションを展開します。
3. 以下のようにルールを設定します：
- 保持するタグの数 (Keep n tags): 例として `10`（常に最新の10個だけ残す）
- 保持するタグの正規表現 (Match tag regex): 例として `.` （すべてのタグ対象、または `v.` など）
- 古いタグの削除 (Remove tags older than): 例として `30 days`（30日以上前のものを削除）
4. [変更を保存] を押します。
これで、裏側で定期的に不要なイメージが掃除され、常にクリーンな状態が保たれます。ストレージ料金の無駄な爆発を防ぐ必須の知見です。
② 外部からのアクセス制限とセキュアな共有
「このイメージ、社外のパートナー企業や他のプライベートプロジェクトからも使いたい（あるいは絶対に隠したい）」という場合のアクセス制御です。
- プロジェクトの可視性による制御:
プロジェクト自体の設定（[設定] ＞ [一般] ＞ [可視性とアクセス制御]）で、プロジェクトを `Private` にしておけば、レジストリへのアクセスも厳格に制限され、プロジェクトメンバー（または許可されたロール）しかプル（ダウンロード）できなくなります。
- デプロイトークン (Deploy Tokens) の活用:
外部のKubernetesクラスターや別のサーバーからイメージをダウンロードしたいけれど、個人のアカウント権限を渡したくない……そんな時は [設定] ＞ [リポジトリ] ＞ [デプロイトークン] を使います。レジストリの読み取り（`read_registry`）権限だけに絞った専用の使い捨てトークンを発行できるため、セキュリティ面で非常に安全です。
—
おわりに
いかがでしたでしょうか？
GitLabコンテナレジストリは、単なる「置き場所」にとどまらず、CI/CDパイプラインと密に連携することで、開発体験を劇的に向上させる強力な武器となります。
「コードを書く ➔ プッシュする ➔ 自動でビルドされ、安全なレジストリに格納される」
このスムーズな流れを手に入れたあなたの開発チームは、インフラの面倒な手間から解放され、本当に価値のある機能開発に集中できるようになります。
ぜひ、今日のプロジェクトから導入してみてくださいね。あなたの開発ライフがより快適になることを応援しています！