Ubuntu14.04でプライベートDockerレジストリを設定する方法

投稿日: 2019-11-08 2022-04-20
タグ: Docker, nginx, ubuntu

序章

Docker は、サーバーをデプロイするための優れたツールです。 Dockerには、Dockerイメージを格納するためのDockerHubと呼ばれるパブリックレジストリもあります。 Dockerを使用すると、Dockerの作成物をDocker Hubに無料でアップロードできますが、アップロードしたものはすべて公開されます。これは、プロジェクトに最適なオプションではない場合があります。

このガイドでは、独自のプライベートDockerレジストリを設定して保護する方法を説明します。このチュートリアルを終了するまでに、カスタムDockerイメージをプライベートレジストリにプッシュし、別のホストからイメージを安全にプルできるようになります。

このチュートリアルでは、独自のアプリケーションのコンテナ化については説明していませんが、デプロイメントを保存できるレジストリを作成する方法についてのみ説明しています。（レジストリではなく）Docker自体を使い始める方法を学びたい場合は、 Dockerのインストールと使用方法：はじめにチュートリアルをお読みください。

このチュートリアルは、 Ubuntu 14.04 を実行しているレジストリサーバーとレジストリクライアントの両方でテストされていますが、他のDebianベースのディストリビューションでも機能する可能性があります。また、Dockerレジストリのバージョン2.0についても説明します。

Dockerの概念

これまでDockerを使用したことがない場合は、Dockerの主要な概念のいくつかを理解するのに少し時間がかかる価値があります。すでにDockerを使用していて、独自のレジストリの実行を開始する方法を知りたい場合は、次のセクションに進んでください。

Dockerの使用方法の復習については、優れたDockerチートシートをご覧ください。

Dockerのコアは、アプリケーションと、それを実行するために必要な依存関係をオペレーティングシステム自体から分離する方法です。これを可能にするために、Dockerはcontainerおよびimagesを使用します。 Dockerイメージは、基本的にファイルシステムのテンプレートです。 Dockerイメージを実行すると、このファイルシステムのインスタンスがライブになり、Dockerコンテナー内のシステムで実行されます。デフォルトでは、このコンテナーは元のイメージ自体またはDockerが実行されているホストのファイルシステムにアクセスできません。それは自己完結型の環境です。

コンテナに加えた変更はすべてそのコンテナ自体に保持され、元のイメージには影響しません。これらの変更を保持する場合は、コンテナーをDockerイメージに「コミット」できます（docker commitコマンドを使用）。つまり、元のコンテナ（またはイメージ）に影響を与えることなく、古いコンテナのコンテンツで始まる新しいコンテナを生成できます。 gitに精通している場合、ワークフローは非常に似ているように見えるはずです。任意のコンテナーから新しいブランチ（Docker用語ではイメージ）を作成できます。イメージの実行は、git checkoutの実行と少し似ています。

類推を続けると、プライベートDockerレジストリを実行することは、DockerイメージのプライベートGitリポジトリを実行することに似ています。

前提条件

このチュートリアルを完了するには、次のものが必要です。

2 Ubuntu 14.04ドロップレット：1つはプライベートDockerレジストリ用、もう1つはDockerクライアント用です
各Dropletでsudo権限を持つroot以外のユーザー（ Ubuntu 14.04 を使用した初期サーバーセットアップでは、これをセットアップする方法について説明しています）。
Ubuntu14.04にDockerComposeをインストールして使用する方法の手順に従ってインストールされたDockerとDockerCompose
プライベートDockerレジストリのドロップレットに解決されるドメイン名

ステップ1—セキュリティを強化するためのパッケージのインストール

Dockerレジストリのセキュリティを設定するには、 DockerComposeを使用するのが最適です。このようにして、あるコンテナでDockerレジストリを簡単に実行し、別のコンテナでNginxにセキュリティと外部との通信を処理させることができます。前提条件のセクションからすでにインストールされているはずです。

Nginxを使用してセキュリティを処理するため、レジストリにアクセスするユーザー名とパスワードの組み合わせのリストを保存する場所も必要になります。 Nginxが理解できるパスワードハッシュを簡単に生成できるhtpasswdユーティリティを含むapache2-utilsパッケージをインストールします。

sudo apt-get -y install apache2-utils

ステップ2—Dockerレジストリのインストールと構成

Dockerコマンドラインツールは、Dockerコンテナーを1つか2つ起動および管理するのに最適ですが、Dockerコンテナー内で実行されているほとんどのアプリは分離して存在しません。ほとんどのアプリを完全にデプロイするには、いくつかのコンポーネントを並行して実行する必要があります。たとえば、ほとんどのWebアプリケーションは、アプリのコードを提供するWebサーバー、PHPやRuby（Railsを使用）などの解釈されたスクリプト言語、およびMySQLなどのデータベースサーバーで構成されています。

Docker Composeを使用すると、各コンテナーの構成用に1つの.yml構成ファイルと、コンテナーが相互に通信する方法に関する情報を書き込むことができます。次に、docker-composeコマンドラインツールを使用して、アプリケーションを構成するすべてのコンポーネントにコマンドを発行します。

Dockerレジストリ自体は複数のコンポーネントを持つアプリケーションであるため、DockerComposeを使用して構成を管理します。

基本的なレジストリを開始するために必要な唯一の構成は、レジストリがデータを保存する場所を定義することです。レジストリの基本的なインスタンスを表示するために、基本的なDockerComposeYAMLファイルを設定しましょう。

まず、このチュートリアルのファイルが存在するフォルダーと、必要なサブフォルダーのいくつかを作成します。

mkdir ~/docker-registry && cd $_
mkdir data

お気に入りのテキストエディタを使用して、docker-compose.ymlファイルを作成します。

nano docker-compose.yml

次の内容をファイルに追加します。

docker-compose.yml

registry:
  image: registry:2
  ports:
    - 127.0.0.1:5000:5000
  environment:
    REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
  volumes:
    - ./data:/data

ここで興味深いのは最後です。 environmentセクションは、パス/dataを使用してDockerレジストリコンテナーに環境変数を設定します。 Dockerレジストリーアプリは、起動時にこの環境変数をチェックし、その結果、/dataフォルダーへのデータの保存を開始することを認識しています。

この場合のみ、volumes: - ./data:/dataビットは、そのコンテナー内の/dataディレクトリが実際にホストマシンの/dataにマップされる必要があることをDockerに通知します。その結果、Dockerレジストリのデータはすべてローカルマシンの~/docker-registry/dataに保存されます。

先に進んで起動し、すべてが正常であることを確認しましょう。

cd ~/docker-registry
docker-compose up

多数のダウンロードバーが画面上を移動するのがわかります（これは、DockerがDocker自身のDockerレジストリから実際のDockerレジストリイメージをダウンロードすることです）。すべてが1、2分でうまくいった場合、次のような出力が表示されるはずです（バージョンは異なる場合があります）。

Output of docker-compose upregistry_1 | time="2015-10-18T23:45:58Z" level=warning msg="No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable." instance.id=44c828de-c27a-401e-bb2e-38b17e6a4b7b version=v2.1.1
registry_1 | time="2015-10-18T23:45:58Z" level=info msg="redis not configured" instance.id=44c828de-c27a-401e-bb2e-38b17e6a4b7b version=v2.1.1
registry_1 | time="2015-10-18T23:45:58Z" level=info msg="using inmemory blob descriptor cache" instance.id=44c828de-c27a-401e-bb2e-38b17e6a4b7b version=v2.1.1
registry_1 | time="2015-10-18T23:45:58Z" level=info msg="listening on [::]:5000" instance.id=44c828de-c27a-401e-bb2e-38b17e6a4b7b version=v2.1.1
registry_1 | time="2015-10-18T23:45:58Z" level=info msg="Starting upload purge in 1m0s" instance.id=44c828de-c27a-401e-bb2e-38b17e6a4b7b version=v2.1.1

No HTTP secret providedメッセージについて心配する必要はありません。正常です。

素晴らしい！この時点で、ポート5000で完全なDockerレジストリが稼働し、リッスンしています（これは、docker-compose.ymlファイルのports:ビットによって設定されています）。この時点では、レジストリはまだそれほど有用ではありません。レジストリを手動で起動しない限り、レジストリは起動しません。また、Dockerレジストリには認証メカニズムが組み込まれていないため、現在は安全ではなく、完全に公開されています。

Docker Composeはデフォルトで入力を永久に待機し続けるので、先に進んでCTRL-Cを押してDockerレジストリコンテナーをシャットダウンします。

ステップ3—Nginxコンテナを設定する

これらのセキュリティ問題の修正に取り掛かりましょう。最初のステップは、別のDockerコンテナー内にNginxのコピーをセットアップし、それをDockerレジストリコンテナーにリンクすることです。

Nginx構成を保存するディレクトリを作成することから始めましょう：

mkdir ~/docker-registry/nginx

次に、~/docker-registryディレクトリにあるdocker-compose.ymlファイルを再度開きます。

nano docker-compose.yml

以下をファイルの先頭に貼り付けます。

docker-compose.yml

nginx:
  image: "nginx:1.9"
  ports:
    - 5043:443
  links:
    - registry:registry
  volumes:
    - ./nginx/:/etc/nginx/conf.d:ro

これにより、公式のNginxイメージに基づいて新しいDockerコンテナが作成されます。ここで興味深いのは、linksセクションです。あるDockerコンテナから別のDockerコンテナへの「リンク」を自動的に設定します。 Nginxコンテナが起動すると、registryコンテナの実際のIPアドレスに関係なく、ホスト名registryのregistryコンテナに到達できます。（舞台裏では、Dockerは実際にnginxコンテナの/etc/hostsファイルにエントリを挿入してregistryコンテナのIPを通知しています）。

volumes:セクションは、registryコンテナーに対して行ったものと似ています。この場合、Dockerコンテナ内ではなく、ホストマシンにNginxに使用する構成ファイルを保存する方法が提供されます。最後の:roは、Nginxコンテナーがホストファイルシステムへの読み取り専用アクセスのみを持つ必要があることをDockerに通知するだけです。

完全なdocker-compose.ymlファイルは次のようになります。

docker-compose.yml

nginx:
  image: "nginx:1.9"
  ports:
    - 5043:443
  links:
    - registry:registry
  volumes:
    - ./nginx/:/etc/nginx/conf.d
registry:
  image: registry:2
  ports:
    - 127.0.0.1:5000:5000
  environment:
    REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
  volumes:
    - ./data:/data

docker-compose upを実行すると、2つのコンテナーが同時に開始されます。1つはDockerレジストリ用で、もう1つはNginx用です。

ただし、これが機能する前にNginxを構成する必要があるため、新しいNginx構成ファイルを作成しましょう。

registry.confファイルを作成します。

nano ~/docker-registry/nginx/registry.conf

以下をファイルにコピーします。

〜/ docker-registry / nginx / registerry.conf

upstream docker-registry {
  server registry:5000;
}

server {
  listen 443;
  server_name myregistrydomain.com;

  # SSL
  # ssl on;
  # ssl_certificate /etc/nginx/conf.d/domain.crt;
  # ssl_certificate_key /etc/nginx/conf.d/domain.key;

  # disable any limits to avoid HTTP 413 for large image uploads
  client_max_body_size 0;

  # required to avoid HTTP 411: see Issue #1486 (https://github.com/docker/docker/issues/1486)
  chunked_transfer_encoding on;

  location /v2/ {
    # Do not allow connections from docker 1.5 and earlier
    # docker pre-1.6.0 did not properly set the user agent on ping, catch "Go *" user agents
    if ($http_user_agent ~ "^(docker\/1\.(3|4|5(?!\.[0-9]-dev))|Go ).*$" ) {
      return 404;
    }

    # To add basic authentication to v2 use auth_basic setting plus add_header
    # auth_basic "registry.localhost";
    # auth_basic_user_file /etc/nginx/conf.d/registry.password;
    # add_header 'Docker-Distribution-Api-Version' 'registry/2.0' always;

    proxy_pass                          http://docker-registry;
    proxy_set_header  Host              $http_host;   # required for docker client's sake
    proxy_set_header  X-Real-IP         $remote_addr; # pass on real client's IP
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_read_timeout                  900;
  }
}

ファイルを保存して終了します。

これで、Nginxをインストールして、2つのDockerコンテナをすべて1つのコマンドで起動できます。

docker-compose up

Nginxは起動時に出力を出力しませんが、すべてがうまくいけば、registryコンテナーにプロキシするように設定されたNginxのコピーを実行しています。テストするには、curlを使用してDockerレジストリに直接HTTPリクエストを送信してから、Nginxポートに別のリクエストを送信します。すべてが正しく設定されている場合、NginxはリクエストをDockerレジストリにプロキシするため、出力はどちらの場合も同じになります（この記事の執筆時点では、Dockerは空のjsonオブジェクト「{}」を返します）。

まず、Dockerレジストリに直接HTTPリクエストを送信します。

curl http://localhost:5000/v2/

この記事の執筆時点では、Dockerは空のjsonオブジェクトを返すため、次のように表示されます。

Output{}

次に、HTTPリクエストをNginxポートに送信します。

curl http://localhost:5043/v2/

同じ出力が表示されるはずです。

Output{}

正常に動作している場合は、docker-composeターミナルに次のような出力が表示されます。

Output of docker-compose    registry_1 | time="2015-08-11T10:24:53.746529894Z" level=debug msg="authorizing request" environment=development http.request.host="localhost:5043" http.request.id=55c3e2a6-4f34-4b0b-bc57-11c814b4f4d3 http.request.method=GET http.request.remoteaddr=172.17.42.1 http.request.uri="/v2/" http.request.useragent="curl/7.35.0" instance.id=55634dfc-c9e0-4ec9-9872-6f4930c17759 service=registry version=v2.0.1
    registry_1 | time="2015-08-11T10:24:53.747650205Z" level=info msg="response completed" environment=development http.request.host="localhost:5043" http.request.id=55c3e2a6-4f34-4b0b-bc57-11c814b4f4d3 http.request.method=GET http.request.remoteaddr=172.17.42.1 http.request.uri="/v2/" http.request.useragent="curl/7.35.0" http.response.contenttype="application/json; charset=utf-8" http.response.duration=8.143193ms http.response.status=200 http.response.written=2 instance.id=55634dfc-c9e0-4ec9-9872-6f4930c17759 service=registry version=v2.0.1
    registry_1 | 172.17.0.21 - - [11/Aug/2015:10:24:53 +0000] "GET /v2/ HTTP/1.0" 200 2 "" "curl/7.35.0"
    nginx_1    | 172.17.42.1 - - [11/Aug/2015:10:24:53 +0000] "GET /v2/ HTTP/1.1" 200 2 "-" "curl/7.35.0" "-"

registry_プレフィックスが付いた行が表示された場合（_の後の数字はマシンによって異なる場合があります）、すべて正常であり、NginxはHTTPリクエストをDockerレジストリに正常にプロキシしました。

先に進み、docker-composeターミナルでCTRL-Cをもう一度押して、Dockerコンテナーをシャットダウンします。

ステップ4—認証の設定

Nginxがリクエストを適切にプロキシしているので、Dockerレジストリにアクセスできるユーザーを制御できるようにHTTP認証を設定しましょう。これを行うには、以前にインストールしたhtpasswdユーティリティを使用して、Apache形式の認証ファイル（Nginxも読み取ることができます）を作成し、それにユーザーを追加します。

次のように最初のユーザーを作成し、USERNAMEを使用するユーザー名に置き換えます。

cd ~/docker-registry/nginx
htpasswd -c registry.password USERNAME

プロンプトが表示されたら、このユーザーの新しいパスワードを作成します。

将来さらにユーザーを追加したい場合は、-cオプションを指定せずに上記のコマンドを再実行してください（cは作成用です）。

htpasswd registry.password USERNAME

この時点で、ユーザーが設定されたregistry.passwordファイルがあり、Dockerレジストリが利用可能です。ユーザーを表示したい場合はいつでもファイルを確認できます（アクセスを取り消したい場合はユーザーを削除できます）。

次に、その認証ファイルを使用するようにNginxに指示する必要があります。

お気に入りのテキストエディタで~/docker-registry/nginx/registry.confを開きます。

nano ~/docker-registry/nginx/registry.conf

ファイルの中央までスクロールすると、次のような行が表示されます。

〜/ docker-registry / nginx / registerry.conf

# To add basic authentication to v2 use auth_basic setting plus add_header
# auth_basic "registry.localhost";
# auth_basic_user_file /etc/nginx/conf.d/registry.password;
# add_header 'Docker-Distribution-Api-Version' 'registry/2.0' always;

auth_basicで始まる2行と、add_headerで始まる行のコメントを解除するには、行の先頭にある＃文字を削除します。この場合、次のようになります。

〜/ docker-registry / nginx / registerry.conf

# To add basic authentication to v2 use auth_basic setting plus add_header
auth_basic "registry.localhost";
auth_basic_user_file /etc/nginx/conf.d/registry.password;
add_header 'Docker-Distribution-Api-Version' 'registry/2.0' always;

これで、Dockerレジストリにプロキシされるすべてのリクエストに対してHTTP基本認証を有効にするようにNginxに指示し、作成したばかりのパスワードファイルを使用するように指示しました。

コンテナを元に戻して、認証が機能しているかどうかを確認しましょう。

cd ~/docker-registry
docker-compose up

前のカールテストを繰り返します。

curl http://localhost:5043/v2/

許可されていないことを訴えるメッセージが表示されるはずです。

Output of curl<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.9.7</center>
</body>
</html>

次に、前に作成したユーザー名とパスワードをcurlリクエストに追加してみてください。

curl http://USERNAME:PASSWORD@localhost:5043/v2/

以前と同じ出力、つまり空のjsonオブジェクト{}が得られるはずです。 docker-compose端子にも同じregistry_出力が表示されます。

先に進み、docker-composeターミナルでCTRL-Cを使用して、Dockerコンテナーをシャットダウンします。

ステップ5—SSLを設定する

この時点で、HTTP基本認証が機能しているNginxの背後でレジストリが稼働しています。ただし、接続が暗号化されていないため、セットアップはまだあまり安全ではありません。以前に作成したNginx構成ファイルのコメントアウトされたSSL行に気付いたかもしれません。

それらを有効にしましょう。まず、編集のためにNginx構成ファイルを開きます。

nano ~/docker-registry/nginx/registry.conf

矢印キーを使用して移動し、次の行を探します。

〜/ docker-registry / nginx / registerry.conf

server {
  listen 443;
  server_name myregistrydomain.com;

  # SSL
  # ssl on;
  # ssl_certificate /etc/nginx/conf.d/domain.crt;
  # ssl_certificate_key /etc/nginx/conf.d/domain.key;

SSLコメントの下の行の前にある#文字を削除して、コメントを解除します。サーバーにドメイン名を設定している場合は、server_nameの値をドメイン名に変更します。完了すると、ファイルの先頭は次のようになります。

〜/ docker-registry / nginx / registerry.conf

server {
  listen 443;
  server_name myregistrydomain.com;

  # SSL
  ssl on;
  ssl_certificate /etc/nginx/conf.d/domain.crt;
  ssl_certificate_key /etc/nginx/conf.d/domain.key;

ファイルを保存します。 NginxはSSLを使用するように構成され、SSL証明書とキーファイルをそれぞれ/etc/nginx/conf.d/domain.crtと/etc/nginx/conf.d/domain.keyで検索します。 docker-compose.ymlファイルで以前に設定したマッピングにより、Nginxコンテナの/etc/nginx/conf.d/パスは、ホストマシンのフォルダ~/docker-registry/nginx/に対応するため、そこに証明書ファイル。

すでにSSL証明書を設定している場合、またはSSL証明書を購入する予定の場合は、証明書とキーファイルをregistry.conf（ssl_certificateおよびssl_certificate_keyにリストされているパスにコピーするだけです。 ]）。

無料の署名付きSSL証明書を取得することもできます。

それ以外の場合は、自己署名SSL証明書を使用する必要があります。

自分の証明書に署名する

Dockerは現在、自己署名SSL証明書の使用を許可していないため、これは通常よりも少し複雑です。また、独自の認証局として機能するようにシステムを設定する必要があります。

まず、~/docker-registry/nginxフォルダーに移動して、証明書を作成する準備をします。

cd ~/docker-registry/nginx

新しいルートキーを生成します。

openssl genrsa -out devdockerCA.key 2048

ルート証明書を生成します（プロンプトで必要なものを入力します）：

openssl req -x509 -new -nodes -key devdockerCA.key -days 10000 -out devdockerCA.crt

次に、サーバーのキーを生成します（これは、Nginx構成でssl_certificate_keyによって参照されるファイルです）。

openssl genrsa -out domain.key 2048

次に、証明書署名要求を行う必要があります。

このコマンドを入力すると、OpenSSLはいくつかの質問に答えるように促します。最初のいくつかは好きなように書いてください。ただし、OpenSSLで「共通名」の入力を求められたら、必ずサーバーのドメインまたはIPを入力してください。

openssl req -new -key domain.key -out dev-docker-registry.com.csr

たとえば、Dockerレジストリがドメイン www.ilovedocker.com で実行される場合、入力は次のようになります。

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:www.ilovedocker.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

チャレンジパスワードは入力しないでください。

次に、証明書要求に署名する必要があります。

openssl x509 -req -in dev-docker-registry.com.csr -CA devdockerCA.crt -CAkey devdockerCA.key -CAcreateserial -out domain.crt -days 10000

生成したばかりの証明書は既知の認証局（VeriSignなど）によって検証されていないため、このDockerレジストリを使用する予定のすべてのクライアントに、これが正当な証明書であることを通知する必要があります。 Dockerレジストリサーバー自体からDockerを使用できるように、ホストマシンでローカルにこれを実行しましょう。

sudo mkdir /usr/local/share/ca-certificates/docker-dev-cert
sudo cp devdockerCA.crt /usr/local/share/ca-certificates/docker-dev-cert
sudo update-ca-certificates

Dockerデーモンを再起動して、証明書ストアへの変更を取得します。

sudo service docker restart

警告：このDockerレジストリに接続するすべてのマシンに対して、この手順を繰り返す必要があります。 Ubuntu 14.04クライアントでこれを行う方法の説明は、ステップ9 —クライアントマシンからのDockerレジストリへのアクセスにリストされています。

ステップ6—SSLのテスト

今ではおなじみのdocker-compose upを介してDockerコンテナを起動します。

cd ~/docker-registry
docker-compose up

別の端末から別のcurlテストを実行して（今回はhttpsを使用のみ）、SSLセットアップが正しく機能していることを確認します。 SSLが正しく機能するには、SSL証明書の作成時にCommon Nameフィールドに入力したものと同じドメイン名を使用する必要があることに注意してください。

curl https://USERNAME:PASSWORD@[YOUR-DOMAIN]:5043/v2/

注：自己署名証明書を使用している場合、curlから次のエラーが表示されます。

curl: (60) SSL certificate problem: self signed certificate

-kオプションを使用して、curl notにピアで確認するように指示します。

curl -k https://USERNAME:PASSWORD@[YOUR-DOMAIN]:5043/v2/

たとえば、設定したユーザーとパスワードがsammyとtestで、SSL証明書がwww.example.comの場合、次のように入力します。

curl https://sammy:test@www.example.com:5043/v2/

すべてがうまくいけば、curlは空のjsonオブジェクト{}を出力し、docker-compose端末は通常のregistry_出力を出力します。

そうでない場合は、SSL手順とNginx構成ファイルを再確認して、すべてが正しいことを確認してください。

この時点で、SSLを介して認証と暗号化を提供しているNginxサーバーの背後で機能するDockerレジストリ2.0が稼働しています。外部からのポート5043へのアクセスを許可するようにファイアウォールが構成されている場合は、任意のマシンdocker login https://<YOURDOMAIN>からこのDockerレジストリにログインし、設定したユーザー名とパスワードを入力できるはずです。前のセクション。

手順7—SSLポートを443に設定する

完了する前に、さらにいくつかの手順を実行します。ポートを443（オプション）の標準SSLポートを使用するように変更し、docker-composeを設定して、起動時にこのコンテナーのセットを開始します。

これまで使用してきた非標準のポート5043ではなく、ポート443（SSLの標準ポート）でリッスンするようにドッキングされたNginxコンテナーを設定することから始めましょう。ただし、1024未満のポートは、Linuxの「特権」ポートです。つまり、rootとしてdocker-composeコンテナーを実行する必要があります。

まず、テキストエディタでdocker-compose.ymlを開きます。

nano ~/docker-registry/docker-compose.yml

Nginxセクションの下にports:セクションが表示され、- 5043:443行（ホストマシンのポート5043をNginxコンテナ内のポート443にマップします）を- 443:443に変更します。 Nginxコンテナのポート443がホストマシンのポート443にマップされるようにします。終了すると、docker-compose.ymlは次のようになります。

〜/ docker-registry / docker-compose.yml

nginx:
  image: "nginx:1.9"
  ports:
    - 443:443
  links:
    - registry:registry
  volumes:
    - ./nginx/:/etc/nginx/conf.d:ro
registry:
  image: registry:2
  ports:
    - 127.0.0.1:5000:5000
  environment:
    REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
  volumes:
    - ./data:/data

docker-composeセッションがまだ実行中の場合は、 CTRL-C を介して強制終了し、ポート443で再起動します。

sudo docker-compose up

注：1024未満のポートをリッスンできるのはrootユーザーのみです。 NginxがデフォルトのSSLポート443で実行できるように、今回はdocker-composeコマンドでsudoを使用する必要があることに注意してください。

docker-composeが通常どおり起動するはずです。

ドメイン名を使用して別のcurlテストを試してみましょう。今回は、URLで:5043を指定しません。

curl https://<YOURUSERNAME>:<YOURPASSWORD>@YOUR-DOMAIN/v2/

すべてがうまくいけば、docker-compose端末に通常のregistry_出力が表示されるはずです。また、別のマシンからこれと同じcurlコマンドを実行して、ポート443が外部に公開されていることを確認することもできます。

次の手順に進む前に、docker-composeターミナルでCTRL-Cを使用してDockerコンテナーをシャットダウンします。

ステップ8—サービスとしてのDockerレジストリの開始

すべてが順調に進んでいる場合は、 Upstart スクリプトを作成して、システムが起動するたびにDockerレジストリが起動するようにします。

まず、既存のコンテナをすべて削除し、Dockerレジストリをシステム全体の場所に移動して、その権限をrootに変更しましょう。

cd ~/docker-registry
docker-compose rm   # this removes the existing containers 
sudo mv ~/docker-registry /docker-registry
sudo chown -R root: /docker-registry

次に、お気に入りのテキストエディタを使用して、Upstartスクリプトを作成します。

sudo nano /etc/init/docker-registry.conf

次のコンテンツを追加して、Upstartスクリプトを作成します（UpstartでDockerコンテナーを適切に監視するのは少し注意が必要です。このUpstartスクリプトの機能について詳しく知りたい場合は、このブログ投稿を確認してください）。

/etc/init/docker-registry.conf

description "Docker Registry"

start on runlevel [2345]
stop on runlevel [016]

respawn
respawn limit 10 5

chdir /docker-registry

exec /usr/local/bin/docker-compose up

Upstartスクリプトの詳細については、このチュートリアルをお読みください。

次のコマンドを実行して、新しいUpstartスクリプトをテストしてみましょう。

sudo service docker-registry start

次のように表示されます。

docker-registry start/running, process 25303

次のコマンドを実行して、サーバーが実行されていることを確認できます。

docker ps

出力は次のようになります（名前はすべてdockerregistry_で始まることに注意してください）。

CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                          NAMES
d4b6fef0b4d1        nginx:1.9           "nginx -g 'daemon of   2 minutes ago       Up 2 minutes        80/tcp, 0.0.0.0:443->443/tcp   dockerregistry_nginx_1
77668352bd39        registry:2          "registry cmd/regist   2 minutes ago       Up 2 minutes        127.0.0.1:5000->5000/tcp       dockerregistry_registry_1

Upstartは、docker-composeコマンドの出力を/var/log/upstart/docker-registry.logに記録します。最後のテストでは、tailを使用してログファイルを「ライブウォッチ」します（起動ログはrootユーザーとして書き込まれるため、sudoが必要です）。

sudo tail -f /var/log/upstart/docker-registry.log

通常のregistry_出力が表示されます。別の端末またはマシンから、今ではおなじみのcurlテストを実行します。

curl https://<YOUR_USERNAME>:<YOURPASSWORD>@[YOUR-DOMAIN]/v2/

すべてが正常に機能している場合、curlは{}を端末に出力し、通常のように表示されます。

registry_1 | time="2015-08-12T08:01:12.241887501Z" level=debug msg="authorizing request" environment=development http.request.host=docker.meatflavoredbeer.com http.request.id=e8d69e16-9448-4c48-afd8-57b1f1302742 http.request.method=GET http.request.remoteaddr=106.1.247.4 http.request.uri="/v2/" http.request.useragent="curl/7.37.1" instance.id=14d4727b-fda1-463f-8d0e-181f4c70cb17 service=registry version=v2.0.1
registry_1 | time="2015-08-12T08:01:12.242206499Z" level=info msg="response completed" environment=development http.request.host=docker.meatflavoredbeer.com http.request.id=e8d69e16-9448-4c48-afd8-57b1f1302742 http.request.method=GET http.request.remoteaddr=106.1.247.4 http.request.uri="/v2/" http.request.useragent="curl/7.37.1" http.response.contenttype="application/json; charset=utf-8" http.response.duration=3.359883ms http.response.status=200 http.response.written=2 instance.id=14d4727b-fda1-463f-8d0e-181f4c70cb17 service=registry version=v2.0.1
registry_1 | 172.17.0.4 - - [12/Aug/2015:08:01:12 +0000] "GET /v2/ HTTP/1.0" 200 2 "" "curl/7.37.1"
nginx_1    | 106.1.247.4 - nik [12/Aug/2015:08:01:12 +0000] "GET /v2/ HTTP/1.1" 200 2 "-" "curl/7.37.1" "-"

ステップ9—クライアントマシンからDockerレジストリにアクセスする

別のマシンからDockerレジストリにアクセスするには、最初に、前に作成したSSL証明書を新しいクライアントマシンに追加します。必要なファイルは~/docker-registry/nginx/devdockerCA.crtにあります。

新しいマシンに直接コピーするか、以下の手順を使用してコピーして貼り付けることができます。

レジストリサーバーで、証明書を表示します。

sudo cat /docker-registry/nginx/devdockerCA.crt

次のような出力が得られます。

Output of sudo cat /docker-registry/nginx/devdockerCA.crt-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJANiXy7fHSPrmMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTQwOTIxMDYwODE2WhcNNDIwMjA2MDYwODE2WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuK4kNFaY3k/0RdKRK1XLj9+IrpR7WW5lrNaFB0OIiItHV9FjyuSWK2mj
ObR1IWJNrVSqWvfZ/CLGay6Lp9DJvBbpT68dhuS5xbVw3bs3ghB24TntDYhHMAc8
GWor/ZQTzjccHUd1SJxt5mGXalNHUharkLd8mv4fAb7Mh/7AFP32W4X+scPE2bVH
OJ1qH8ACo7pSVl1Ohcri6sMp01GoELyykpXu5azhuCnfXLRyuOvQb7llV5WyKhq+
SjcE3c2C+hCCC5g6IzRcMEg336Ktn5su+kK6c0hoD0PR/W0PtwgH4XlNdpVFqMST
vthEG+Hv6xVGGH+nTszN7F9ugVMxewIDAQABo1AwTjAdBgNVHQ4EFgQULek+WVyK
dJk3JIHoI4iVi0FPtdwwHwYDVR0jBBgwFoAULek+WVyKdJk3JIHoI4iVi0FPtdww
DAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEAkignESZcgr4dBmVZqDwh
YsrKeWSkj+5p9eW5hCHJ5Eg2X8oGTgItuLaLfyFWPS3MYWWMzggxgKMOQM+9o3+k
oH5sUmraNzI3TmAtkqd/8isXzBUV661BbSV0obAgF/ul5v3Tl5uBbCXObC+NUikM
O0C3fDmmeK799AM/hP5CTDehNaFXABGoVRMSlGYe8hZqap/Jm6AaKThV4g6n4F7M
u5wYtI9YDMsxeVW6OP9ZfvpGZW/n/88MSFjMlBjFfFsorfRd6P5WADhdfA6CBECG
LP83r7/MhqO06EOpsv4n2CJ3yoyqIr1L1+6C7Erl2em/jfOb/24y63dj/ATytt2H
6g==
-----END CERTIFICATE-----

その出力をクリップボードにコピーし、クライアントマシンに接続します。

クライアントマシンで、証明書ディレクトリを作成します。

sudo mkdir /usr/local/share/ca-certificates/docker-dev-cert

編集のために証明書ファイルを開きます。

sudo nano /usr/local/share/ca-certificates/docker-dev-cert/devdockerCA.crt

証明書の内容を貼り付けます。

ファイルを表示して、クライアントマシンにファイルが正しく保存されていることを確認します。

cat /usr/local/share/ca-certificates/docker-dev-cert/devdockerCA.crt

すべてが正常に機能した場合は、以前と同じテキストが表示されます。

Output of cat /usr/local/share/ca-certificates/docker-dev-cert/devdockerCA.crt-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJANiXy7fHSPrmMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
...
...
LP83r7/MhqO06EOpsv4n2CJ3yoyqIr1L1+6C7Erl2em/jfOb/24y63dj/ATytt2H
6g==
-----END CERTIFICATE-----

次に、証明書を更新します。

sudo update-ca-certificates

次のような出力が得られるはずです（1 addedに注意してください）。

Output of sudo update-ca-certificatesUpdating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.

クライアントにDockerをまだインストールしていない場合は、ここでインストールします（「前提条件」セクションを参照）。

Dockerを再起動して、システムのCA証明書が再ロードされることを確認します。

sudo service docker restart

これで、クライアントマシンからDockerレジストリにログインできるようになります。

docker login https://YOUR-DOMAIN

https：//を使用していることに注意してください。以前に設定したユーザー名とパスワードを入力します（プロンプトが表示されたら、電子メールに必要なものを入力します）。

Output of docker login
Username: USERNAME
Password: PASSWORD
Email: 
Account created. Please see the documentation of the registry http://localhost:5000/v1/ for instructions how to activate it.

次のメッセージが表示されます。

Output of docker loginLogin Succeeded

この時点で、Dockerレジストリが稼働しています。レジストリにプッシュするテストイメージを作成しましょう。

ステップ10—プライベートDockerレジストリに公開する

これで、プライベートDockerレジストリにイメージを公開する準備が整いましたが、最初にイメージを作成する必要があります。 DockerHubのubuntuイメージに基づいて単純なイメージを作成します。

クライアントマシンから、小さな空のイメージを作成して、新しいレジストリにプッシュします。

docker run -t -i ubuntu /bin/bash

ダウンロードが完了すると、Dockerプロンプトが表示されます。 SUCCESSというファイルを作成して、ファイルシステムに簡単な変更を加えましょう。

touch /SUCCESS

Dockerコンテナを終了します。

exit

変更をコミットします。

docker commit $(docker ps -lq) test-image

このコマンドは、すでに実行されているイメージと行った変更に基づいて、test-imageという新しいイメージを作成します。この場合、/SUCCESSファイルの追加が新しいイメージに含まれています。

このイメージは現在ローカルにのみ存在するため、作成した新しいレジストリにプッシュしてみましょう。

前の手順では、プライベートDockerレジストリにログインしました。まだログインしていない場合は、もう一度ログインしましょう（ https：// を使用することに注意してください）。

docker login https://YOUR-DOMAIN

以前に設定したユーザー名とパスワードを入力します。

Username: USERNAME
Password: PASSWORD
Email: 
Account created. Please see the documentation of the registry http://localhost:5000/v1/ for instructions how to activate it.

Dockerには、プッシュ先のレジストリを指定するための通常とは異なるメカニズムがあります。イメージをプッシュするには、プライベートレジストリの場所でイメージにタグを付ける必要があります。画像をプライベートレジストリにタグ付けしましょう。

docker tag test-image [YOUR-DOMAIN]/test-image

最初に画像のローカル名を使用し、次に画像に追加するタグを使用していることに注意してください。タグはではなくhttps://を使用し、ドメイン、ポート、およびイメージ名のみを使用します。

これで、そのイメージをレジストリにプッシュできます。今回はタグ名のみを使用しています。

docker push [YOUR-DOMAIN]/test-image

これは、レジストリサーバーにアップロードするのに少し時間がかかります。次のようなもので終わる出力が表示されます。

Output of docker pushlatest: digest: sha256:5ea1cfb425544011a3198757f9c6b283fa209a928caabe56063f85f3402363b4 size: 8008

ステップ11—Dockerレジストリからプルする

すべてが機能することを確認するために、元のサーバー（Dockerレジストリをインストールした場所）に戻り、クライアントからプッシュしたばかりのイメージをプルします。これを3番目のサーバーからテストすることもできます。

Dockerがテストプルサーバーにインストールされていない場合は、戻って手順6のインストール手順（および3番目のサーバーの場合はSSL手順）に従います。

以前に設定したユーザー名とパスワードでログインします。

docker login https://[YOUR-DOMAIN]

そして今、画像を引っ張ってください。ドメイン名、ポート、およびイメージ名を含む「タグ」イメージ名のみが必要です（https://は含まれません）。

docker pull [YOUR-DOMAIN]/test-image

Dockerはダウンロードを実行し、プロンプトに戻ります。新しいマシンでイメージを実行すると、前に作成したSUCCESSファイルがそこにあることがわかります。

docker run -t -i [YOUR-DOMAIN]/test-image /bin/bash

bashシェル内にファイルをリストします。

ls

このイメージ用に以前に作成したSUCCESSファイルが表示されます。

SUCCESS  bin  boot  dev  etc  home  lib  lib64  media   mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

結論

おめでとう！独自のプライベートDockerレジストリを使用して、最初のDockerコンテナをプッシュおよびプルしました。

ハッピードッカー！

getdocs

13036