DockerコンテナをGitLabに統合するGitLab Container Registry

GitLabが先頃，Dockerコンテナレジストリをシステムに導入した。DockerコンテナイメージをGitLabの継続的統合ツールに統合することが目的だと，GitLabのエンジニアであるMark Pundsack氏が書いている。

GitLab CIの使用により，GitLab Container RegistryへのDockerコンテナイメージのビルド，テスト，デプロイが完全に自動化されると同時に，開発者からのアクセスも容易になる。以下に示すのはGitLab CIの設定ファイルの一例だ。イメージをビルドしてテストを実行し，成功すればビルドタグを作成した上で，そのイメージをGitLabの統合レジストリにプッシュする。

 build_image:
   image: docker:git
   services:
     - docker:dind
   script:
     - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN gitlab.com:5005
     - docker build -t my-group/my-project .
     - docker run my-group/my-project /script/to/run/tests
     - docker tag my-group/my-project
       gitlab.com:5005/my-group/my-project:latest
     - docker push gitlab.com:5005/my-group/my-project:latest
   only:
     - master

Pundsack氏によれば，GitLab Container Registryを使用する最大のメリットは，利用するにあたって，外部のサービスあるいはパブリックレジストリのセットアップや管理が不要であることだ。これはつまり，

• GitLabの認証情報を使用するので，そのユーザやグループの定義が流用可能である。
• すべてセットアップ済みなので，レジストリ内にリポジトリを作成する必要がない。
• 追加ソフトウェアのインストールが不要。

GitLab Container Registryには，新たに設けられたタブを経由してアクセスする。このタブには，現在のプロジェクトに関連するすべてのイメージが一覧表示される。コンテナレジストリは，デフォルトではプロジェクト単位で用意されるので，開発者は個々のプライベートプロジェクトを利用することが可能だ。この設定は，プロジェクト単位でオフにすることもできる。GitLab.comでは，無制限のプライベートプロジェクトに対して，無償で使用することができる。オンプレミスのインストールでも利用可能だ。

InfoQは，GitLabのプロダクト責任者であるMark Pundsack氏から，DockerとGitLab Container Registryが開発者にどのように役立つのかを詳しく聞いた。

GitLab Container Registryが開発者をどのように支援するのか，説明して頂けますか？

２つの側面があります。1) コンテナレジストリという概念自体，そして 2) GitLabに統合されたコンテナレジストリであること，です。

コンテナレジストリは，あらゆる開発者のワークフローを自動化する上で有用です。例えば，イメージをコンテナレジストリにプッシュすれば，チームの他のメンバ – 公開レジストリならば必要とする人すべて – がそれをダウンロードできるようになります。そうでなければ，すべてのソフトウェアを自分自身でビルドしなくてはなりません。ソースコードをダウンロードして自分でコンパイルしなくても，完全なイメージが手に入るのです。コンパイルされたコードだけではありません。特定のバージョンのオペレーティングシステムや必要なツーリングなど，ソフトウェアを実行するために必要なものはすべてイメージに含まれています。ですからラップトップでも，あるいはクラウドのインスタンスでも，ソフトウェアの動作にはわずかな違いもありません。

GitLabはコンテナレジストリをGitLabワークフロー全体に統合することで，すべてをシームレスにします。管理が必要なのはひとつのユーザセットと，ひとつの標準的なプロジェクトだけです。レジストリに接続すれば，権限を持つすべてのイメージにアクセスすることができます。オンプレミスの企業ユーザにとって重要なことですが，他にインストールや管理の必要なものは何もないのです。

Dockerをワークフローに統合するためのプラクティスがいくつも現れていますが，代表的なものは 1) すべてのビルドとテストを外部で実行し，その結果からDockerイメージを生成する，2) Dockerイメージを構築してテストする，3) Dockerイメージを構築してそれだけでテストし，docker-composeを使ったインテグレーションテストで複数のイメージを同時実行し，相互のインタラクションを確認する，という３つの方法です。最後の方法は，マイクロサービスを標榜する企業には最適でしょう。

GitLab Container Registryのメリットが最も期待できるのは，どのようなシナリオだと思われますか？

Dockerの強みのひとつは，開発，テスト，デプロイメントを通じて同じイメージを使用できることです。これによって，運用段階で基盤となるオペレーティングシステムやツールの些細な差異あるいは非互換性から発生する，予期しない事態を防止することができます。開発者がMacで書いたコードをLinux上の運用環境に投入するような場合，こういったことがよくあります。これが問題になることはほとんどないのですが，皆無ではありません。一般的に，開発/本番一致(dev-prod parity)と言われる値で信頼性の測定を行なっているようなサイトでは，開発環境を可能な限り運用環境に近いものにしています。

複数のサービス間のコーディネーションを処理するように設計されたマイクロサービスも，Dockerがそのメリットを発揮するケースのひとつです。Dockerのなかった頃は，５つのコンポーネントを使用するようなシステムを開発者のラップトップ上でテストするのは，非常に煩雑な作業でしたが，Docker – 特にdocker-compose – によって，とても簡単になりました。

こういった作業を行なう上で，コンテナレジストリは中心的な役割を果たすのです。

コンテナレジストリを統合する方法は，Docker HubなどサードパーティのDockerレジストリを使用する場合と比較して，どのようなメリットがあるのでしょうか？

最も明確なメリットはコストと利便性です。コンテナレジストリの利用は(個人ないしビジネスユースのプライベートプロジェクトに対しても無制限に)まったく課金されません。GitLabに予めインストールされているのです。統合が重要な意味を持つのは，GitLab上のプロジェクトにアサインされたグループやメンバに割り当てられたGitLabの認証や権限定義を適用したければ，レジストリに格納されたプライベートコンテナリポジトリでそれが簡単に実現できる点です。

Docker Hubなどを使用する場合は，そのプロジェクトを公開するか，有償のプライベートプロジェクトにするか，いずれかが必要です。多くの企業のようにオンプレミスにしたいのならば，Docker Trusted Registryの使用料を支払う必要があります。さらに，どちらの場合でも，イメージを手作業で管理する担当者も手配しなくてはなりません。

GitLab Container RegistryにはGitLab 8.8以降が必要だ。GitLab.comでは，すでに無償で利用できる。