プライベート Docker レジストリ

ProGet を使えば、プライベートな Docker レジストリを作成し、詳細なアクセスコントロールなど、サードパーティの Docker イメージと、自社製の Docker イメージの両方を同じように管理できます。Docker Hub などのリモート Docker リソースからダウンロードしたイメージでも、内部で作成したイメージでも、ProGet は Docker クライアントと透明に連携をします。

ProGet上で、Docker レジストリはフィードとして表示されます。そのため、以下が可能です。

• フィードの特権を Docker レジストリに適用できる
• AmazonS3 と AzureBlob ストレージを構成できる
• Docker レジストリの名前は別のフィード名と重複する名前を使用できない

複数の Docker レジストリ

ProGetでは無制限のDockerレジストリを定義できます。それぞれのプロジェクトを特定のレジストリで管理でき、Docker イメージに対するアクセスコントロールがよりスムーズになります。

ProGetでDockerレジストリを作成および使用する

ProGet で Docker レジストリを作成するには [Containers (コンテナ)] ＞ [Create New Docker Registry (新しいDockerレジストリを作成)] から新しいレジストリに名前を付けてください。

非セキュアなレジストリ (HTTP ではなく HTTPS もしくは自己署名証明書)の使用

Docker クライアントが localhost:<PORT> を URL に使っていない場合、有効な証明書で SSL を使用するには Docker レジストリが必要です。その場合、ProGet を有効な証明書と共に IIS 内で設定する必要があります。HTTP を使って（IIS内もしくは組み込まれたウェブサーバ内で）ProGetを設定している、もしくは IIS 内で自己署名証明書を使っている場合、ProGetをDockerクライアント内で非セキュアなレジストリ（リンク先英語）として設定してください。

HTTP レジストリ（IIS もしくは組み込みウェブサーバ）

HTTP を使用してレジストリを操作するように Docker クライアントを設定するには、レジストリのベース URL 名を Dockerdaemon.json ファイルに追加する必要があります。その際、レジストリ名は含まないでください。URL がポート 80 を使用していないか、「.」 （サーバー名のみを使用する場合のように）が含まれていない場合、URLにポートも含める必要があります。

例：

• "insecure-registries" : ["myregistrydomain.com:80"]

• "insecure-registries" : ["prodserver.inedo.local"]

• "insecure-registries" : ["prodserver:80"]

Docker daemon.jsonの例：

{
    "registry-mirrors": [],
    "insecure-registries": [
    "myregistrydomain.com:80"
],
    "debug": false,
    "experimental": false
}

自己署名証明書

自己署名証明書を使ってDockerクライアントが HTTPS のレジストリを使用するようにしたい場合は、証明書をローカルでインストールする必要があります。証明書の正しいインストール方法については、こちらの Docker の資料 using self-signed certificates （リンク先英語）をご覧ください。

Dockerクライアントの設定方法

ProGetはトークンベースの認証 (Docker 1.11.0 （リンク先英語）以上が必須) とHTTP の基本的な認証の両方に対応しています。

まずは、Docker にログインしてください。ログインをするには、以下のコマンドを使用します。このコマンドでは progetsv1 が ProGet サーバ名 となっています：

[~]$ docker login progetsv1:80

このコマンドでは、ProGet のウェブインターフェイスからログインできる全てのユーザー名やパスワードが使えます。さらに、ユーザーネームがapiなら、APIキーをパスワードとして使用することができます。

Docker は localhost 以外のどのようなドメインでも TLS が必要です。なので、ProGet のサーバーに HTTPS 経由で（有効な証明書を使って）アクセスができる状態してください。代わりに、ProGet のサーバを非セキュアなレジストリとして設定もできます。その場合は、HTTP か自己署名証明書のある HTTPS を使います。

例：

以下は間違った例です

• このURLはdockerにdocker hubから情報を引き出すことを要求します

docker pull prodserver/myimages/dotnet/aspnet:5

以下は正しい例です

• このURLはサーバprodserver.inedo.localを使います

docker pull prodserver.inedo.local/myimages/dotenet/aspnet:5

• このURLはポート80を経由しサーバprodserverを使います

docker push prodserver:80/myimages/dotnet/aspnet:5

• このURLはポート443を経由しサーバprodserverを使います

docker push prodserver:443/myimages/dotnet/aspnet:5

Dockerを利用するには、専用の権限が必要です。つまり Linux では、docker グループのメンバーであること、もしくは sudo や su を使って一時的に root ユーザへの切り替えをしていることが条件になります。Windowsの場合、cmd や PowerShell インスタンスを起動させるには管理者権限が必要です。

イメージを公開する

ProGet に Docker イメージを公開するには、まず特別なフォーマット内でDockerを使ってイメージをタグ付けします。例えば、ローカル名が ubuntu:trustyのイメージがある場合、以下のようにタグ付けし直します：

[~]$ docker tag ubuntu:trusty progetsv1:443/dmc/ubuntu:trusty

ざっくりまとめるとこのようなフォーマットになります：server/feed/image:tag

タグ付けをしたら、ProGetにイメージをプッシュすることができます：

[~]$ docker push progetsv1:443/dmc/ubuntu:trusty

イメージをプルする

イメージをプルするのもほとんど同じフォーマットです：

[~]$ docker pull progetsv1:443/dmc/ubuntu:trusty

イメージの削除

イメージを削除するには、DockerのDelete Image API（イメージAPIの削除：リンク先英語）から以下の通りに HTTP DELETE リクエストを実行します：

DELETE /v2/-name>/manifests/

reference はダイジェストである必要があるのでご注意ください。このAPIからはタグを削除できませんが、マニフェストを削除することによって直接関連しているタグも同時に外されます。

ProGet では、特定のタグに関連した image details（イメージの詳細）の上にダイジェストが表示されます。

API を通して、タグ付けされたイメージのマニフェストダイジェストを確認できます：

• リポジトリのリストにアクセスしたい場合は、 https://proget.example.com/v2/_catalog をリクエストしてください。

• https://proget.example.com/v2/main/library/node/tags/list からリポジトリごとのタグのリストを入手できます

• そこから、https://proget.example.com/v2/main/library/node/manifests/latest を通してタグ付けされたマニフェストにアクセスできます

• ハッシュは、レスポンスの Docker-Content-Digest ヘッダーにあります

ローカルで保持しているイメージのダイジェストは、docker inspect -f '{{.Id}}' proget.example.com/main/library/node:latest からも入手できます

イメージをビルド、プッシュ、またはプルをする場合の全てにおいて、ダイジェストはコマンドアウトプットの最後の方にプリントされます。ビルドコマンドは--iidfileを使ってダイジェストをテキストファイルに保存する機能にも対応しています。

プロキシサーバでProGetのDockerレジストリを使う

SSL サポートを追加したり、受信される接続を管理したりするためにプロキシサーバ（nginx や Apache など）を使って ProGet との接続をプロキシするユーザは多くいます。Docker ベースの ProGet を利用している場合も、プロキシサーバの使用をおすすめします。しかし、Docker のログイン時にトラブルが起こり、ユーザがログインできなくなってしまう場合があります。プロキシを使用する時には、ProGet の [Advanced Settings (詳細設定)] からプロキシサーバの URL を Web.BaseUrl に設定する必要があります。

Docker クライアントが ProGet を使って認証を行おうとした場合、/v2/ のURL（https://proget.server.com/v2/ など）にリクエストが送信されます。そうすると、ProGet は Docker に対して認証の手順を示す WWW-Authenticate: に似たようなヘッダーを表示します：Bearer realm="https://proget.server.com/v2/_auth",service="proget.server.com"。プロキシサーバがURLを含めたヘッダーをクライアントに正しく送信されること確認してください。

高度なコンセプト

チャンク化・モノリシックアップロード

一度の HTTP リクエストで大容量のファイルをアップロードするには、Dockerクライアントがチャンク化アップロードプロセス（リンク先英語）を使う場合がほとんどです。このプロセスでは、アップロードの開始、いくつかのチャンク（断片的なBlobファイル）、そしてアップロードの完了情報を送信します。ProGet は DockerAPI が指定したチャンクを作成することによって、このプロセスをサポートします。

また、「フィードクリーンアップ」では、ProGet が未完了のアップロードを消去します（例：アップロード完了情報なしでチャンクが送信された場合など）。

不要な blob の収集

パッケージとは違い、Docker イメージは独立したファイルではありません。Docker イメージはマニフェスト blob の参照用ファイルであり、代わりにいくつかのレイヤーblob を提供します。これらのレイヤー blob はレジストリ内の他のマニフェストが参照できます。つまり、マニフェスト blob を消去しても、参照されたレイヤー blob は消去されません。

ここで garbage collection（不要 blob の収集）の機能が役立ってきます。garbage collection は、蓄積されたパッケージの中から、マニフェストに参照されなくなったblob を消去してくれます。この機能は ProGet が「フィードクリーンアップ」のジョブスケジュールを通して、Docker レジストリに対して garbage collection を行います。

コネクタ

ProGet v5.1 以降の Docker フィードは、他の Docker レジストリに対するコネクタ（リンク先英語）に対応しています。これらのコネクタは、ProGet の他のコネクタとは少し違った動きをします。詳細は Docker connectors についての記事（リンク先英語）をご覧ください。

プライベートレジストリの制約

統合 Windows 認証

Docker クライアントは統合 Windows 認証に対応していません。なので、この機能が有効な ProGet インスタンスに「匿名」アクセスを確立することはできません。対策としては、統合 Windows 認証が無効の状態で、IIS 内にディスク上の同じパスを指す二つ目のサイトを構成する方法があります。

その他の制約

Docker は、パブリックにホストされている hub.docker.com と密接に統合するように設計されています。プライベートレジストリもある程度までは対応しています。しかし、Docker クライアントや関連ツールは主にパブリックレジストリ、もしくは Docker クライアントが構築した、認証済みのプライベート Docker レジストリ（リンク先英語）の使用を前提としています。結論として、プライベートレジストリの使用はやや複雑になってしまう傾向がありますが、このようなケースに対する Docker クライアントの対応の質も徐々に向上しています。