docker之仓库管理_docks 管理-CSDN博客

本次尝试使用registry/nginx两个容器实现，但后续发现无法实现原有目标。由于v2版本的registry在登录、push、pull均使用GET /v2/这个相同的url，而且首次连接时一定使用，用来确认registry是否需要认证，即如果返回为401则表示registry需要认证，否则表示不认证。由于有这一层限制导致对GET /v2/这个url无法做处理，如果让其不认证，则客户端就会认为不需要认证，会以不认证的方式继续后续操作，比如push，如此会在push时无法成功；如果让其认证，则会导致匿名用户无法pull，因为匿名用户pull时第一个url也是GET /v2/，由于需要认证且又是匿名，会导致无法pull。

虽然整个章节都是失败的尝试，但也记录下来，一方面加深了对nginx作http代理的了解，另一方面对于registry的1.0版本，使用此方法是有效的。

4.2 架构

使用registry:2和nginx两个镜像完成私有仓库的搭建，架构如下：

当用户使用pull下载镜像时，不过“认证”模块，故不需要用户登录；如果需要push上传镜像，则必须经过“认证”模块，故push镜像必须标准用户名、密码。详细研究registry后发现暂时找不到如何配置，故转而使用nginx配置规则实现此目标。

4.3 服务器配置

使用docker-compose统一配置，如下详细描述。

4.3.1 nginx compose配置

nginx:

restart: always

image: yourdomain.com:5000/nginx

ports:

- "5000:5000"

links:

- registry

volumes:

- ./auth:/etc/nginx/conf.d/

-./auth/nginx.conf:/etc/nginx/nginx.conf:ro

- ./log:/var/log/nginx

nginx容器会将数据转发到registry容器，故使用links指令。

对外开放5000端口。

有三个数据卷：

auth，其中存储ssl证书和push需要的用户名密码文件；在上一章节生成的证书也放置到此目录下，供nginx使用。

nginx.conf，nginx真正的配置文件

log，将nginx的日志输出到宿主机，方便查看日志。

4.3.2 nginx配置

l 用户名密码文件

使用htpasswd命令生成用户名密码文件，供nginx认证使用。

在镜像registry:2中包含了htpasswd程序，使用如下命令：

docker run --rm --entrypoint htpasswd registry:2 -bn user pass >auth/nginx.htpasswd

注意以上的user pass，正是在push镜像时需要认证的用户名、密码。

l nginx.conf

events {

worker_connections 1024;

}

http {

upstream docker-registry {

server registry:5000;

}

## Set a variable to help us decide if weneed to add the

## 'Docker-Distribution-Api-Version'header.

## The registry always sets this header.

## In the case of nginx performing auth,the header will be unset

## since nginx is auth-ing before proxying.

map$upstream_http_docker_distribution_api_version $docker_distribution_api_version{

'' 'registry/2.0';

}

server {

listen 5000;

server_name yourdomain.com;

ssl on;

ssl_certificate /etc/nginx/conf.d/domain.crt;

ssl_certificate_key /etc/nginx/conf.d/domain.key;

# Recommendations fromhttps://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

ssl_protocols TLSv1.1 TLSv1.2;

ssl_ciphers'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:10m;

# disable any limits to avoid HTTP 413for 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;

## If $docker_distribution_api_versionis empty, the header will not be added.

## See the map directive above wherethis variable is defined.

add_header 'Docker-Distribution-Api-Version'$docker_distribution_api_version always;

proxy_set_header Host $http_host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_read_timeout 900;

location ~ ^/v2/$ {

auth_basic "Restricted";

auth_basic_user_file /etc/nginx/conf.d/nginx.htpasswd;

proxy_pass https://docker-registry;

}

location / {

limit_except GET HEAD OPTIONS {

auth_basic "Restricted";

auth_basic_user_file /etc/nginx/conf.d/nginx.htpasswd;

}

proxy_pass https://docker-registry;

}

如下配置为nginx.conf的内容，其中大部分内容都取自于docker文档。

l 原理

(1) docker交互API

首先要详细分析docker客户端与v2版本的registry交互的流程，交互过程为HTTPS，可以通过nginx的access.log日志来分析。

a) 查询api

对应的URL是“GET /v2/_catalog HTTP/1.0”

b) pull镜像

对应的URL是"GET/v2/hello-world/manifests/latest HTTP/1.0"

c) push镜像

对应的URL是"POST/v2/hello-world/blobs/uploads/ HTTP/1.0"

d) dockerlogin

对应的URL是"GET /v2/ HTTP/1.0"

根据分析以上数据交互过程，确保pull时无需认证，push时必须认证，则需要对所有的非GET请求进行认证，同时对docker login也需要认证。

(2) location配置

使用两个location规则实现“不认证pull、认证才能push”的目的，location ~ ^/v2/$，此规则表示URL仅是’/v2/’，不包含后续的内容，恰好满足docker login的要求，即确保docker login时进入认证流程；location /此规则表示其他所有的URL都使用此配置，因为nginx中的location是最长匹配原则。其中limit_except GET HEADOPTIONS表示除了这三种HTTP方法：GET/HEAD/OPTIOINS，其他的方法都需要认证，因此对于push镜像就必须经过认证。认证所需要的文件就是htpasswd生成的用户名、密码文件。

4.4 客户端查询

只有push权限的客户端才有查询能力，即确保使用者的安全性，只告知可以下载哪些镜像，使用第三方的python脚本完成这个功能，文件名为registry.py，命令如下。

registry.py -r https://yourdomain.com:5000

如下显示内容是一个样例：

Image: django

tag: latest

Image: mysql

tag: latest

Image: nginx

tag: latest

Image: redis

tag: latest

4.5 镜像删除

镜像删除工作比较复杂，目前docker没有提供方便的接口完成registry中镜像的删除工作，不过可以使用上一章节中的registry.py脚本配合完成，步骤如下：

(1) 删除tags

registry.py -r https://yourdomain.com:5000 -d -i imagename -n numberoftags

imagename，要清理的镜像名称

numberoftags，保留版本的个数，默认是10个。

(2) 停止仓库registry

使用docker-compose down停止服务

(3) 垃圾回收

使用如下命令：

docker-compose run registry bin/registry garbage-collect /etc/docker/registry/config.yml

(4) 启动仓库registry

docker-compose up

5 用户认证

引入docker_auth这个新的认证镜像，其中包含了一个静态认证的服务器，同时此认证服务器还有多种功能，支持google、github、ldap、mongo等多种动态认证方式，在搭建私有仓库时极其有用，比如要控制不同镜像的不同人员访问权限，php人员只能下载php镜像，java人员只可以下载、上传java相关镜像，有非常良好的用户认证机制。但由于此镜像隐藏得非常深，找了很久才发现，而且中文世界中对其描述很少，以下所有配置均可参见网站：

https://github.com/cesanta/docker_auth

也可以下载对应的github源码深度学习，其中有详细的配置，还有认证服务器的go语言源代码，非常有价值。

5.1 认证原理

docker认证完全遵循oauth2.0标准，标准流程如下：

1. docker client 尝试到registry中进行push/pull操作；

2. registry会返回401未认证信息给client(未认证的前提下)，同时返回的信息中还包含了到哪里去认证的信息；

3. client发送认证请求到认证服务器(authorization service)；

4. 认证服务器(authorization service)返回token；

5. client携带这附有token的请求，尝试请求registry；

6. registry接受了认证的token并且使得client继续操作；

5.2 实现

使用两个官方镜像袜，registry:2镜像实现仓库功能，cesanta/docker_auth实现认证功能。docker_auth镜像使用go语言实现认证功能，包括静态用户、google、github、mongo、外部认证等方式，总共代码行数才2600行。

5.2.1 registry配置

覆盖默认的config.yml文件，如下：

version: 0.1

log:

fields:

service: registry

storage:

delete:

enabled: true

cache:

blobdescriptor: inmemory

filesystem:

rootdirectory: '/var/lib/registry'

auth:

token:

realm: 'https://dockerreg.maxnetsys.com:5001/auth'

service: 'Docker registry'

issuer: 'maxnet auth server'

rootcertbundle: '/certs/domain.crt'

http:

addr::5000

tls:

certificate: '/certs/domain.crt'

key:'/certs/domain.key'

headers:

X-Content-Type-Options: [nosniff]

health:

storagedriver:

enabled: true

interval: 10s

threshold: 3

在部分配置是默认配置，关注auth块，其中使用了token认证，填充四个参数，realm表示为docker_auth镜像启动时的路径，docker_auth监听5001端口；issuer值必须与docker_auth中的配置完全一致；rootcertbundle就是公钥；service随便填。

5.2.2 docker_auth配置

覆盖默认配置。

server:

addr:"0.0.0.0:5001"

certificate: "/ssl/domain.crt"

key:"/ssl/domain.key"

token:

issuer: "maxnet auth server"

expiration: 900

users:

"admin":

password:"$2y$05$Hr7we48EODPWnzRRmBJEfucuBc.RM9FJZHFe6aZk3gPKU67U3.9P2"

"": {}

acl:

-match: {account: ""}

actions:["pull"]

comment: "Anonymous users can pull everything."

-match: {account: "admin"}

actions: ["*"]

comment: "Allow everything for dockerreg users."

server块中指定监听端口，还需要写明ssl的公钥和私钥；token中的issuer与registry保持一致；users块为用户配置，其中有两个用户，一个是admin，另一个是匿名用户；acl配置用户的权限，匿名用户只能pull，admin用户有所有权限。

用户的密码请使用htpasswd生成，命令格式如下：

htpasswd –nb -B username password

注意忽略输出的内容中的用户名和冒号，即只复制冒号后面的内容到password。

docker_auth的配置详细可以参考github中的reference.yml，其中有所有项的详细说明。在实际生产环境中如果期望更细粒度的配置权限，可以扩展users和acl，非常方便。

5.2.3 compose内容

使用docker-compose部署。

version: "2"

services:

registry:

restart: always

image: registry:2

ports:

-"5000:5000"

volumes:

-./certs:/certs:ro

-./registry_config.yml:/etc/docker/registry/config.yml

-./data:/var/lib/registry

dockerauth:

restart: always

image: cesanta/docker_auth

ports:

-"5001:5001"

command: --v=2 --alsologtostderr /config/auth_config.yml

volumes:

-./auth_config.yml:/config/auth_config.yml:ro

-./certs:/ssl:ro

- ./log:/logs

registry和docker_auth分别监听5000、5001端口，均使用https。registry需要将镜像存储的volumes，docker_auth启动命令将日志输出到终端，方便运维人员查看日志。

6 web管理

web化的仓库管理客户端，目前个人尚未找到，如果能找到将极大的降低运维人员的使用复杂度。尝试了hyper/docker-registry-web这个镜像，发现其对oauth2.0的认证方式不支持，故放弃。