公司有两个docker的registry,一个是在公司内网,一个是在hk的公网
那jenkins打镜像的时候,FROM底包是在hk,打出镜像后,又要推到公司的内网,这样jenkins的pipeline看起来就很痛苦
打包登录公网一次,打包的地址是内网的harbor,推包再登录内网一次,脚本如下:
docker.withRegistry("https://hk.rendoumi.com", "hk-user") {
image = docker.build("harbor.rendoumi.dev/${IMAGE_NAME}:${TAG}", "${PROJECT_PATH}")
}
docker.withRegistry("https://harbor.rendoumi.dev", "harbor-user") {
if (image) { image.push() }
}
流水线不多的话这么还行得通,流水线很多,就得改个一溜够
那就想如果登录hk的服务器使用白名单机制,公司的jenkins worknodes服务器去访问,就不用登录,直接访问,就好了
那公司私网的registry是用的harbor搭的,公网的registry用的caddy+zot搭建
问了下 Gemini, 结果非常的荒谬,居然出现幻觉,呓推出了zot根本不存在的ip白名单限制规则,简直了!!!
后来跑到 zot 的官网看了半天文档,发现不行,根本没有这种配置
那就只能从Caddy入手了,从公司jenkins worknode出来的ip先到Caddy
然后Caddy模拟登录信息,给后端的zot发请求,就可以通过了
做法如下:
首先把 hk registry 的用户名和密码生成base64字串,得到XXXXX的BASE64字符串
echo -n "user1:pass1" | base64
然后修改Caddyfile,原有的配置
hk.rendoumi.com {
reverse_proxy 127.0.0.1:5000 {
header_up X-Real-IP {remote_host}
transport http {
dial_timeout 15s
response_header_timeout 300s
}
}
}
改成如下:
hk.rendoumi.com {
@trusted {
remote_ip 111.222.333.444
}
handle @trusted {
reverse_proxy 127.0.0.1:5000 {
header_up Authorization "Basic XXXXXXXXXXXXXXXX"
header_up X-Real-IP {remote_host}
transport http {
dial_timeout 15s
response_header_timeout 300s
}
}
}
handle {
reverse_proxy 127.0.0.1:5000 {
header_up X-Real-IP {remote_host}
transport http {
dial_timeout 15s
response_header_timeout 300s
}
}
}
}
解释一下,上面如果是 111.222.333.444 的ip来访问,那就模拟登录的 Head 头信息,如果不是,就直接放行,由后端的zot进行验证
那相应的,后端的zot也必须采用httpasswd的认证方式,zot的config.json配置如下:
{
"distSpecVersion": "1.0.0-dev",
"http": {
"address": "127.0.0.1",
"port": "5000",
"compat": ["docker2s2"],
"auth": {
"htpasswd": {
"path": "/zot/htpasswd"
}
}
},
"storage": {
"rootDirectory": "/zot/registry"
}
}
这样就OK了