go1-12与1-14之私服使用的差异与变化
当私服搭建完成之后，在使用的姿势上，也有一些需要注意的地方，这里记录一下工作中使用的姿势以及坑点。
# 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/"
2
那么无论在什么地方构建，应该都是可以高效且迅速完成的，此时无论是拉取外网的，GitHub的包，都是可以通过私服来完成的，同样内网在gitlab中的包，也能够通过私服代理拉到。
# 2，go1.14。
后来一部分小伙伴升级了go的版本到了1.14，这个时候，因为官方引入了sumdb的校验，这个校验的概念是所有公共的包都会在官方的sumdb中存有一份校验值，以防止一些恶意劫持篡改的情况发生，这本是一个好事儿，然而老问题又来了，官方的sumdb地址为：sum.golang.org (opens new window)，当我们构建的时候，连到这个地址去校验包，往往都是超时的。
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"
2
3
4
5
此处更新的配置中，最后一项是针对于校验时的问题解决的，sum.golang.google.cn也是一个国内的库，可供使用，有一些文章建议说设置 export GOSUMDB=off，这里并不推荐这么做，毕竟这层校验对安全来说，还是比较重要的。
但上边的配置也给后边的工作埋了一个坑。
有一些问题往往都是在不同场景当中展现的，而我们又很难在一开始就把所有的情况都想到，这不，有小伙伴反馈说go版本升级之后，在测试环境(容器化环境，镜像为golang:1.14.1)发布的时候总是失败，失败的原因也很简单，就像下边所示：
[91mgo: 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
2
成功了总还算是让人心情舒畅的，但是却没有想明白是为什么，为此，结合了几个开发大佬研讨许久，过程甚是酣畅，这里不多赘述，直接解密。
原因：因为上边配置中有一项是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"
2
3
如上配置指明了我们所有的包都走私服代理进行拉取，但是内部域名下的包不走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"
2
3
4
5
GO111MODULE:Go语言提供了 GO111MODULE 这个环境变量来作为 Go modules 的开关，因为到1.14当中默认是on，因此可以不加了。GOPROXY：表示设置go模块儿代理，同node我们经常使用淘宝源一样的，这里地址指向我们的私服地址。GONOPROXY：用于配置不走代理的地址。GOPRIVATE：表示此项配置中的地址将会作为GONOPROXY 和 GONOSUMDB 的默认值。GOSUMDB：表示编译过程中go进行校验时的地址。GONOSUMDB：表示此项中配置中的地址不进行校验，因为私服当中的包是无法也不能进行公有校验的。
|