• 对于注定会优秀的人来说,他所需要的,只是时间!
  • 手懒得,必受贫穷,手勤的,必得富足----《圣经》
  • 帮助别人,成就自己。愿君在本站能真正有所收获!
  • 如果你在本站中发现任何问题,欢迎留言指正!
  • 宝剑锋从磨砺出,梅花香自苦寒来!

<十一>企业级开源仓库nexus3实战应用–go1.12与1.14之私服使用的差异与变化

nexus eryajf 1个月前 (05-28) 458°C 已收录 0个评论
本文预计阅读时间 8 分钟
文章目录[隐藏]

当私服搭建完成之后,在使用的姿势上,也有一些需要注意的地方,这里记录一下工作中使用的姿势以及坑点。

1,go1.12。

一开始大家使用的golang版本是1.12,在这个版本中,go mod还不是一个官方默认的选项,不过也没有像新版本中引入sumdb的验证,因此在配置私服的时候,反而会比较纯粹简单了。

这里假设如下两个地址:

  • 私服:nexus.eryajf.net
  • 内网包:gitlab.eryajf.net

在go1.12中,通过如下配置可以进行连接:

export GO111MODULE=on
export GOPROXY="http://nexus.eryajf.net/repository/go-group/"

那么无论在什么地方构建,应该都是可以高效且迅速完成的,此时无论是拉取外网的,GitHub的包,都是可以通过私服来完成的,同样内网在gitlab中的包,也能够通过私服代理拉到。

2,go1.14。

后来一部分小伙伴升级了go的版本到了1.14,这个时候,因为官方引入了sumdb的校验,这个校验的概念是所有公共的包都会在官方的sumdb中存有一份校验值,以防止一些恶意劫持篡改的情况发生,这本是一个好事儿,然而老问题又来了,官方的sumdb地址为:sum.golang.org,当我们构建的时候,连到这个地址去校验包,往往都是超时的。

Get https://sum.golang.org/lookup/xxxxxx: dial tcp 216.58.200.49:443: i/o timeout

因此,我们得到第一步更新的配置(如下配置似乎也是许多地方推荐使用的配置方式,包括诸如goproxy.io官方文档):

export GOPROXY="http://nexus.eryajf.net/repository/go-group/"
export GONOPROXY="gitlab.eryajf.net"
export GONOSUMDB="gitlab.eryajf.net"
export GOPRIVATE="gitlab.eryajf.net"
export GOSUMDB="sum.golang.google.cn"

此处更新的配置中,最后一项是针对于校验时的问题解决的,sum.golang.google.cn也是一个国内的库,可供使用,有一些文章建议说设置 export GOSUMDB=off,这里并不推荐这么做,毕竟这层校验对安全来说,还是比较重要的。

但上边的配置也给后边的工作埋了一个坑。

有一些问题往往都是在不同场景当中展现的,而我们又很难在一开始就把所有的情况都想到,这不,有小伙伴反馈说go版本升级之后,在测试环境(容器化环境,镜像为golang:1.14.1)发布的时候总是失败,失败的原因也很简单,就像下边所示:

go: gitlab.eryajf.net/test/admin-go@v1.0.3: reading gitlab.eryajf.net/test/admin-go/go.mod at revision v1.0.3: unknown revision v1.0.3

看得出是在从本地拉包的时候失败了,这个时候没有其他错误,我一般都是先到私服当中搜索一下,发现这个包是在的,那就没有道理拉不下来呀,这个时候思绪也沉溺在环境的不一致上了,做了不少测试验证都没有得到答案,因为在外边构建非常顺利,而测试环境就是发不成功。

后来一个同学把代理配置改成如下样子,发现构建成功了:

export GOPROXY="http://nexus.eryajf.net/repository/go-group/"
export GOSUMDB=off

成功了总还算是让人心情舒畅的,但是却没有想明白是为什么,为此,结合了几个开发大佬研讨许久,过程甚是酣畅,这里不多赘述,直接解密。

  • 原因:因为上边配置中有一项是 export GONOPROXY="gitlab.eryajf.net",那么编译的时候拉 gitlab.eryajf.net/test/admin-go@v1.0.3这个包的时候,就不再走私服,而是从容器直接去gitlab中拉包,而对应项目又是 Private 类型的,这两者之间未做任何认证,自然是无法拉到,这一点解释了上边的报错。

而本地之所以无法复现那个报错的原因应该是:当我拉包不通过代理,直接去gitlab拉包的时候,因为开发者本地都针对gitlab做过了认证,因此即便是直接去gitlab拉包也不会有问题,所以本地无法复现在容器中的那个错误。

于是有人提到说 GONOPROXY这个选项有了,是不是也就代表着不需要我们内部的私服了,直接将代理设置为公共的,然后将GONOPROXY设置为本地gitlab,不就完美解决了,这种方案的不科学性与上边一致,要想实现,恐怕需要如下条件才行:

  • 除非是所有内网的包都设置为 Public类型,当然,出于安全性考虑,这种配置几乎不可能会采纳
  • 或者是任何需要构建的地方,都加入一个基于所有私服包认证的key,这或许是一个可行的方案,却不是一个优雅的方案,事实上nexus的go私服也是基于key来拉取内部的包的,只不过是把认证的工作统一交给 athens来做了。

因此,最终我们在go1.14版本中,采用了如下的代理配置:

export GOPROXY="http://nexus.eryajf.net/repository/go-group/"
export GONOSUMDB="gitlab.eryajf.net"
export GOSUMDB="sum.golang.google.cn"

如上配置指明了我们所有的包都走私服代理进行拉取,但是内部域名下的包不走sumdb的校验,如果外部包需要校验,那么使用国内的地址 sum.golang.google.cn。

现在问题似乎都已经明朗了,或许可以再回头来审视一下上边添加的配置中几个选项的含义:

export GOPROXY="http://nexus.eryajf.net/repository/go-group/"
export GONOPROXY="gitlab.eryajf.net"
export GONOSUMDB="gitlab.eryajf.net"
export GOPRIVATE="gitlab.eryajf.net"
export GOSUMDB="sum.golang.google.cn"
  • GO111MODULE:Go语言提供了 GO111MODULE 这个环境变量来作为 Go modules 的开关,因为到1.14当中默认是on,因此可以不加了。
  • GOPROXY:表示设置go模块儿代理,同node我们经常使用淘宝源一样的,这里地址指向我们的私服地址。
  • GONOPROXY:用于配置不走代理的地址。
  • GOPRIVATE:表示此项配置中的地址将会作为GONOPROXY 和 GONOSUMDB 的默认值。
  • GOSUMDB:表示编译过程中go进行校验时的地址。
  • GONOSUMDB:表示此项中配置中的地址不进行校验,因为私服当中的包是无法也不能进行公有校验的。

weinxin
扫码订阅本站,第一时间获得更新
微信扫描二维码,订阅我们网站的动态,另外不定时发送WordPress小技巧,你可以随时退订,欢迎订阅哦~

二丫讲梵 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明<十一>企业级开源仓库nexus3实战应用–go1.12与1.14之私服使用的差异与变化
喜欢 (0)
[如果想支持本站,可支付宝赞助]
分享 (0)
eryajf
关于作者:
学无止境,我愿意无止境学。书山有路,我愿意举身投火,淬炼成金!永远不要忘记,激情的奋进,就是美好的未来!

您必须 登录 才能发表评论!