搭建私有Docker Registry

Docker官方提供了用於搭建私有registry的鏡像，並配有詳細文檔。
官方Registry鏡像：https://hub.docker.com/_/registry
官方文檔：https://docs.docker.com/registry

根據文檔快速搭建的私有registry，只支持http。可是目前docker客戶端的pull、push等命令，默認使用https的方式和registry進行交互，這將致使咱們搭建的私有registry沒法正常使用。

本文將從兩個方面入手解決此問題：

1. 讓客戶端以http方式和私有registry交互。
2. 讓私有registry支持https。

固然，第二種方式是本文的重點。此外，本文還介紹瞭如何使用用戶名密碼的方式，驗證客戶端身份。

這裏假設咱們的服務端的ip爲：192.168.0.1，沒有專用域名。你們在配置時，內網ip外網ip都可。若是有專用域名，處理方式也相似，只是要在生成證書時，注意命令的配置。

客戶端使用Http的方式和私有Registry進行交互

這是經常使用的一種處理方式，優勢是方便快捷，分分鐘搞定。只要修改客戶端docker守護進程的配置文件，將私有registry配置爲一個不安全的registry便可 。此後，客戶端都將使用http的方式和這個registry交互。主要步驟以下：

在服務端啓動私有registry：

docker run -d -p 5000:5000 --name docker-registry registry:2

這個命令只是做爲演示，真實環境下確定還會配置volume。

配置客戶端，和私有registry交互：

客戶端的daemon.json配置內容以下：

{
  "insecure-registries": ["192.168.0.1:5000"]
}

daemon.json的通常路徑爲：/etc/docker/daemon.json
配置參考官方文檔：https://docs.docker.com/engine/reference/commandline/dockerd

啓動（或重啓）客戶端docker，使用如下命令製做一個本身的busybox鏡像，並推送至私有registry：

# 製做本身的busybox鏡像
docker tag busybox 192.168.0.1:5000/busybox

# 將鏡像推送至私有registry
docker push 192.168.0.1:5000/busybox

docker會使用http的方式和registry進行交互，將鏡像推送至私有registry。

配置私有Registry，支持Https

下面介紹下如何配置私有Registry，使其支持https訪問。

準備證書

跟常見的https站點同樣，咱們先要弄到一份證書，才能讓咱們本身的registry支持https。證書都是由CA（數字證書管理機構）簽發的，咱們能夠向CA購買證書。根據CA的不一樣，證書類型的不一樣，證書的價格相差懸殊，你們能夠本身網上搜搜看。若是有興趣的話，你們還能夠經過瀏覽器的調試工具，看看各大支持https網站的證書，分別是哪些CA簽發的。

各個CA都有一份本身的證書（根證書），CA頒發給咱們的證書都是用這份根證書籤發出來的，操做系統會內置部分CA的根證書（好比受信任的根證書頒發機構下的證書）。這些內置CA簽發出來的證書都將會被操做系統認爲是安全的。好比某個網站使用了這些CA頒發的證書，那麼你在訪問這個網站時，瀏覽器地址欄就會變成綠色，提示你網站是安全的，不然，瀏覽器會用明顯的紅色提醒你正在訪問不安全的網站。

舉個例子，12306的網站：https://kyfw.12306.cn/otn，你在訪問時會提示不安全。經過瀏覽器調試工具查看其證書，發現是一個叫 SRCA 的CA頒發證書給它的。繼續百度，得知 SRCA 的全稱爲：Sinorail Certification Authority（可翻譯爲中鐵數字證書認證中心）。至關因而中鐵本身做爲CA，給本身旗下的一個網站簽發了一份證書。SRCA 的CA資質是確定不會被國際承認的，道理你懂的，因此 SRCA 也不會被操做系統收錄爲受信任的CA。結果就是你在訪問12306的網站時，瀏覽器會提示你正在訪問不安全的網站。

這個問題的一種處理方式（也是12306網站目前在用的方式），就是把 SRCA 這個CA的根證書安裝到系統中，操做系統就會認爲由這個CA簽發出的證書都是可信的，這樣，訪問12306的網站就不會再提示證書錯誤了。12306網站首頁上有安裝根證書的操做說明，你們能夠自行查看。

向知名CA購買證書無疑是最好的選擇，這裏咱們處於學習和我的使用的目的，將採用相似12306的方式，本身做爲CA，爲本身簽發一份證書。

首先，咱們本身把本身視爲CA，生成一份根證書

# 生成CA私鑰
openssl genrsa -out ca.key 2048

# 生成CA證書
openssl req -new -x509 -days 365 -key ca.key -out ca.crt -subj "/C=CN/CN=name"

參數說明：

• CN=name 指證書的頒發者和使用者均爲name（本身給本身簽發根證書，頒發者和使用者固然都是本身，沒毛病）。建議更改成你的姓名或公司名稱。嘗試了下中文，出現了亂碼，因此建議使用英文。

第二個命令生成的證書（ca.crt文件），就是所謂的CA根證書，到時候要交給客戶端安裝，不然客戶端默認會認爲，由這個CA簽發出來的證書是不安全的。

再用這份根證書，爲咱們的registry生成一份證書

# 生成私鑰文件
openssl genrsa -out server.key 2048

# 生成證書籤名請求文件
openssl req -new -key server.key -out server.csr -subj "/C=CN/CN=192.168.0.1"

# 生成證書
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -extfile <(printf "subjectAltName=IP:192.168.0.1") -out server.crt

參數說明：

• CN=192.168.0.1 指證書的使用者爲192.168.0.1，可更改成任意字符串。在私有registry沒有域名的狀況下，建議更改成私有registry的ip；有域名的狀況下，建議更改成域名。此配置不影響證書的正常使用。
• subjectAltName=IP:192.168.0.1 指明證書使用者的ip必須爲192.168.0.1。若是證書頒發給的是域名而非ip，則使用 subjectAltName=DNS:你的域名 做爲配置。固然也能夠二者使用，好比 subjectAltName=IP:192.168.0.1,DNS:你的域名 ，這種配置應該是同時限制使用者的ip和域名的做用，沒有深究。注意，此配置是X509 Version 3的新特性，配置後一份證書可供一個或多個ip（或域名）使用。此配置是必須有，而且是配置正確的，不然https請求會報錯。

啓動私有registry

命令以下：

docker run -d -p 5000:5000 --name docker-registry \
-v /home/docker-registry:/home/docker-registry \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/home/docker-registry/server.crt \
-e REGISTRY_HTTP_TLS_KEY=/home/docker-registry/server.key \
registry:2

參數說明以下：

• REGISTRY_HTTP_TLS_CERTIFICATE 證書文件路徑
• REGISTRY_HTTP_TLS_KEY 私鑰路徑

參考官方文檔中的http章節：https://docs.docker.com/registry/configuration/#http

注意，文檔中有說明，若是一個配置A是可選的，但它又存在必選的子配置B和C，你能夠整個A及其子配置B、C都不配置，不然B和C都必須配置。原文以下：
In some instances a configuration option is optional but it contains child options marked as required. In these cases, you can omit the parent with all its children. However, if the parent is included, you must also include all the children marked required.

配置客戶端，安裝CA根證書

如下指令用於將證書安裝至客戶端：

# 備份
cp /etc/pki/tls/certs/ca-bundle.crt{,.backup}

# 導入CA根證書
cat ca.crt >> /etc/pki/tls/certs/ca-bundle.crt

若是使用的是window系統，直接雙擊證書，導入至受信任的根證書頒發機構下的證書目錄下便可。運行certmgr.msc命令可打開證書管理器，刪除本證書。

客戶端和私有Registry交互

注意，若是以前在daemon.json文件中配置過insecure-registries，則必須去掉此配置並重啓docker，不然客戶端會使用http方式和registry交互，致使交互失敗。

推送鏡像至私有registry：

# 製做本身的busybox鏡像
docker tag busybox 192.168.0.1:5000/busybox

# 將鏡像推送至私有registry
docker push 192.168.0.1:5000/busybox

docker會使用https的方式和registry進行交互，將鏡像推送至私有registry。

配置Registry，使用用戶名密碼的方式，驗證客戶端身份

私有registry支持經過使用htpasswd工具生成的用戶名密碼配置文件，來驗證客戶端身份。
不一樣linux發行版的中的htpasswd工具安裝方式可能存在不一樣，這裏以CentOS爲例：

yum install -y httpd-tools

生成用戶名密碼配置文件

# 建立用戶名密碼配置文件.passwd，並新增用戶user1，密碼手工輸入
htpasswd -cB .passwd user1

htpasswd工具的參考文檔：https://httpd.apache.org/docs/2.4/programs/htpasswd.html

注意命令中的-B參數，配置後，htpasswd將以bcrypt加密方式加密密碼，安全性更高。bcrypt也是docker指定的惟一一種加密方式，其餘加密方式均不被支持，詳見官方文檔中的htpasswd章節：https://docs.docker.com/registry/configuration/#htpasswd。

這裏再列幾個命令用於維護用戶：

# 新增用戶user2：
htpasswd -B .passwd user2

# 刪除用戶user2：
htpasswd -D .passwd user2

注意：htpasswd工具並未提供修改密碼功能，如需修改密碼，能夠先刪除用戶，再新增用戶實現。

啓動私有registry：

docker run -d -p 5000:5000 --name docker-registry \
-v /home/docker-registry:/home/docker-registry \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/home/docker-registry/server.crt \
-e REGISTRY_HTTP_TLS_KEY=/home/docker-registry/server.key \
-e REGISTRY_AUTH=htpasswd \
-e REGISTRY_AUTH_HTPASSWD_REALM=basic-realm \
-e REGISTRY_AUTH_HTPASSWD_PATH=/home/docker-registry/.passwd \
registry:2

文檔中沒有對REGISTRY_AUTH_HTPASSWD_REALM這個必選配置有比較詳細的說明，本身百度了些資料，大概是用於和silly、token這兩種身份驗證方式配合使用，沒作深究。由於咱們這裏只用到了htpasswd這種身份驗證方式，因此就用文檔裏的默認配置了。哪位若是比較瞭解這部份內容，但願不吝賜教。

此後，咱們就可使用用戶名密碼登陸私有registry了，沒有登陸的客戶端將被拒絕訪問：

# 登陸私有registry
docker login 192.168.0.1:5000 -u user1 -p 你的密碼

# 將鏡像推送至私有registry
docker push 192.168.0.1:5000/busybox

注意：用戶名密碼的驗證方式只建議在https的方式下使用，由於用戶名密碼是經過http請求頭髮送的，若是使用http的方式會很不安全，原文以下：
Only use the htpasswd authentication scheme with TLS configured, since basic authentication sends passwords as part of the HTTP header.

戶名密碼的驗證方式還有個缺點，私有registry只在啓動的時候讀取htpasswd生成的用戶名密碼配置文件，因此任何對該配置文件的修改，必須重啓registry才能生效，原文以下：
The htpasswd file is loaded once, at startup.

其餘私有Registry搭建方式

網上也有不少資料介紹其餘私有registry搭建方式，其中一種是在registry前端架設nginx服務器。這種方式也是很值得推薦的，不少公共的registry提供商應該也是擴展這種方式提供服務。

這種方式的其優勢有：

1. nginx會處理https相關內容。
2. 可使用nginx配置負載均衡，搭建registry集羣，提升registry服務的可靠性。

固然缺點也有：

1. 配置較繁瑣，須要對nginx和registry有比較深刻的瞭解，特別是在涉及到負載均衡和集羣時。
2. 若是涉及到負載均衡和集羣，registry的運維工做量也不可小覷。