adtech studio

Portus で素敵な Private Docker Registry を用意してみる

masaya By masaya

Container 検証

こんにちは。
Central Infrastracture Agency の青山です。

今回は Portus についてお話させていただきたいと思います。
一言で言うならば、Portus とは Docker Registry (Distribution) に対して認証・認可の機能とリッチな Web UI を提供するソフトウェアです。
開発元は SUSE で、Apache License 2.0 で提供される OSS ということもあり安心して利用できます。

 

以前は docker-registry-web や docker_auth なども利用していたのですが、

  • UI が簡素
  • 認証、認可周りが弱い
  • audit の履歴がない
  • イメージの検索、イメージのグループ化ができない

などの問題点があり、共用で使うには難しかったため、別のソリューションを採用することとなりました。

 

今回検証したバージョンは Portus 2.2 です。

 

Portus のアーキテクチャ

Portus を動作させるためには、 5 つのコンポーネントが必要です。

  • portus
  • crono
  • mysql
  • docker-registry (docker distribution)
  • portus-proxy (nginx)

 

基本的にどれも冗長化できるため、今回弊社ではそれぞれを コンテナ上で動作させています。
一つだけ問題となってくるのは Docker Registry のバックエンドですが、この部分に関しては S3, OpenStack Swift, PersistentVolume, DRBD, バックアップなどで安全性を保てば大丈夫かと思います。

 

 

Portus

Portus は WebUI, 認証・認可などを行なう Rails のアプリケーションとなっています。

 

Crono

Portus では Docker Registry の notification endpoint を使って、Portus に対して Docker Registry のイメージリストなどのメタデータを同期しています。
Docker Registry でも notification の際に retry 機能がついているため、あまり問題にはなりにくいのですが、notification に失敗した場合は次の notification まで Portus 側のイメージリストが更新されなくなってしまうため、デフォルトで 600 sec 毎に同期処理を行うのが Cronoとなっています。
notification は使わず、データを取得してきて同期する仕組みのようなので、Portus を動かしていてイメージリストの更新が遅いようであれば Docker Registry の notification 周りの設定が間違っていることが多そうです。

 

MySQL

Portus のイメージリストや、ユーザ・チーム・Registry・Namespace の情報などが保持されています。

 

Docker Registry

Portus は WebUI, 認証・認可などを行なう Rails のアプリケーションとなっています。

 

Portus-Proxy (Nginx)

Portus では、下記の理由から Nginx を使った構成を推奨しています。

  • 静的コンテンツを Rails ではなく Nginx で返す
  • リクエストパスに応じて Docker Registry と Portus への通信を分ける
  • SSL 通信をさばく

 

Portus の構築

基本的には Docker Compose の example を見ながら、必要に応じてKubernetes に落とし込んだり、Docker Registry や DB のデータ領域を冗長化したりしながら構築するのが一番良さそうです。
この記事を書いている時点では Kubernetes の config は WIP のようでした。
更新はそこそこ活発な分、少し問題を抱えてたりすることもあるので、Issue などを確認すると良いかと思います。

 

認証と認可

Portus では、各 User を束ねるグループ機能として Team が存在します。
そのため、各ユーザ毎に認証情報を付けながらも、認可の際には一括での指定も可能となっています。

 

 

Team が Namespace を保持し、Repository (いわゆる Docker Image 名)が Namespace 内で管理されます。
この Team と Namespace を使い分けることにより、認可の機能を実現することが可能となっています。

Namespace についてはわかりにくいので、Docker コマンドを見ていただいたほうが早いと思います。
Namespace を使った Docker image の操作は下記の様な形となります。

 

また、Namespace の部分を使わずに root 直下に push した場合にはデフォルトのネームスペースが利用されます。

Namespace に対する認可には、3 種類の選択肢があり下記のいずれかが選択できるようになっています。

  • Viewer
    • Pull のみ可能
  • Contributor
    • Push / Pull が可能
  • Owner
    • Push / Pull が可能、その Namespace に対するユーザの管理が可能

また、NameSpace には Anonymous ユーザからの pull 許可、ログインしていれば許可などの柔軟な設定も可能となっています。

 

Audit

監査ログのなども管理されています。
大人数で利用するレジストリサーバとしては必要な機能です。

 

 

脆弱性診断

OSS にもかかわらず、CoreOS Clair や zypper-docker を用いたコンテナイメージの脆弱性診断機能までついているようです。
現状では Portus 2.3 以降で実装予定のため、master branch から pull してくる必要があります。
参考: http://port.us.org/features/6_security_scanning.html

 

設定の変更

Portus の設定ファイルは /srv/Portus/config/config.yml にあります。
デフォルトではイメージの削除ができなかったり、誰でも Sign up できる状態のため、必要に応じて明示的に下記のような変更を加える必要があります。

delete.enable = true に関しては、仕組みを理解してからご利用下さい。
また LDAP への切り替え、gravatar の利用などの設定もここから設定することが可能です。

より詳細な情報は公式ページを参照して下さい。

 

その他

今回詳細は触れませんでしたが、その他にも

  • イメージの検索
  • イメージのお気に入り
  • LDAP 連携による認証
  • イメージなどへのコメント機能

などもあるため、OSS ながらも十分な機能を有していると思います。

ぜひ素敵な Private Docker Registry 環境、1 project に 1 台いかがでしょうか。