小厂内部私有Go module拉取方案3
本文永久链接 – https://tonybai.com/2023/03/03/the-approach-to-go-get-private-go-module-in-house-part3
1. 缘起
我们的Go团队这两年完全是按照之前写的《小厂内部私有Go module拉取方案》和《小厂内部私有Go module拉取方案(续)》中的方案搭建的内部拉取私有仓库的基础设施,总体感觉不错,目前也没有什么大问题。
唯一麻烦一点的,就像《小厂内部私有Go module拉取方案》中提到的,当新增一些用作私有依赖包的repo时,govanityurls的vanity.yml需要手动更新或通过工具自动更新。维护这样一套设施,开发人员肯定不喜欢去做。
月初一位同事的主机发现无法通过内部的GOPROXY server拉取私有module,虽然事后证明这很是网络层面的问题,但也引发我的思考,在统一代理之外是否有拉取私有module的补充方案?恰好前些天,组内一童鞋分享了Rust直接用内部自建的gitlab上的一个repo作为依赖的方法,只需要在cargo.toml中做简单配置:
foo-rs = {git = "http://192.168.10.10/ard/foo-rs", branch = "master"}
基于go module目前的机制是否可以支持类似Rust这种相对优雅的方案呢?本着当时对go.mod配置与go get的认知一时没有想出来:(。不过心中也大致给这样的方案画出了一个框框:
- 基于现有go.mod语法
- 改动最小
- 用go.mod而非go.work,这样可提交到代码库做版本管理,所有组员均可使用
我想到了基于go mod replace来做,当然需要对replace做一些扩展,于是我向go官方项目提交了proposal!
2. 提案(proposal)
提案的核心就是扩展go mod的replace语法,让replace的target支持一个remote的vcs仓库,下面是一个例子:
module github.com/bigwhite/demo
go 1.20
require (
mycompany.com/go/common v1.1.0
)
replace mycompany.com/go/common v1.1.0 => 192.168.10.159/ard/go/common v1.1.0
//或 replace mycompany.com/go/common => 192.168.10.159/ard/go/common
//或 replace mycompany.com/go/common => 192.168.10.159/ard/go/common v1.1.0
//或 replace mycompany.com/go/common v1.1.0 => 192.168.10.159/ard/go/common
这样我们既可保留我们为私有module自定义的cannoical import paths(如mycompany.com/go/common),又可以方便基于自建vcs server拉取私有module。
3. 反转
我的提案提出没两个小时就被close了,我去看了一下详情,seankhliao回复:Go现在已经支持这种用法,并给出一个例子:
192.168.10.159/ard/go/common.git
我不确定seankhliao是否完全理解了我的提案,但他的回复还是让我开始怀疑我是否遗漏了什么。于是我又去重新学习了一下go module的reference以及go cmd的reference,之后脑子中形成了一个待确认的方案。
当前go.mod的replace指示符语法如下:
replace module-path [module-version] => replacement-path [replacement-version]
其中的replacement-path [replacement-version]构成target部分,目前支持两种target:
一种是module path,如:
replace example.com/othermodule => example.com/othermodule v1.2.3
另外一种是本地文件系统中的路径:
replace example.com/othermodule => ../othermodule
需要注意的是当replacement-path使用module path时必须带有replacement-version,下面的例子会导致go编译或运行命令报错:
replace example.com/othermodule v1.2.3 => example.com/othermodule
以前我总以为当replacement-path使用module path时,这个module path必须是那种带有域名的repo地址,根据seankhliao的例子,这块似乎也可以是一个诸如:“192.168.10.159/ard/go/common.git”的remote repo,如果是这样,那么即便不使用统一的内部go proxy,我们也可以直接从内部的自建vcs server上拉取private module了,下面我们就来验证一下这个方案。
4. 方案的确认试验
下面是试验环境的拓扑:
这个拓扑与带有统一go proxy代理的方案完全不同:
- 对于外部的public module,我们采用外部public go proxy(比如:goproxy.io或goproxy.cn等)去拉取;
- 对于托管在内部vcs server的private module,我们采用直连(direct)方式拉取;
- 对于托管在github上的private module(使用private repo),我们也采用直连(direct)方式拉取。
显然我们的新方案需要解决的是后面两种情况。
为了更直观地说明新方案,我们假设我们的一个go应用依赖了三个private包,他们的情况分别是:
- privatemodule1
repo放在内部gitlab上,其自定义cannoical import path为:mycompany.com/go/privatemodule1,实际地址为http://10.10.30.30/ard/incubators/privatemodule1.git
$tree -L 1 -F privatemodule1
privatemodule1
├── go.mod
├── privatemodule1.go
└── README.md
$cat privatemodule1/go.mod
module mycompany.com/go/privatemodule1
go 1.19
$cat privatemodule1/privatemodule1.go
package privatemodule1
import "fmt"
func F() {
fmt.Println("invoke F of mycompany.com/go/privatemodule1")
}
- privatemodule2
repo放在github的private repo中,其自定义cannoical import path为:mycompany.com/go/privatemodule2,实际地址为https://github.com/bigwhite/privatemodule2
$tree -L 1 -F privatemodule2
privatemodule2
├── go.mod
├── privatemodule2.go
└── README.md
$cat privatemodule2/go.mod
module mycompany.com/go/privatemodule2
go 1.19
$cat privatemodule2/privatemodule2.go
package privatemodule2
import "fmt"
func F() {
fmt.Println("invoke F of mycompany.com/go/privatemodule2")
}
- privatemodule3
repo放在github的private repo中,如:github.com/bigwhite/privatemodule3,但无自定义cannoical import path。
$tree -L 1 -F privatemodule3
privatemodule3
├── go.mod
├── privatemodule3.go
└── README.md
$cat privatemodule3/go.mod
module github.com/bigwhite/privatemodule3
go 1.19
$cat privatemodule3/privatemodule3.go
package privatemodule3
import "fmt"
func F() {
fmt.Println("invoke F of github.com/bigwhite/privatemodule3")
}
这三种情况应该可以覆盖日常Go开发的绝大多数private module依赖的情况了。下面我们分别看看如何获取这三类private module,我们先从最简单的privatemodule3开始。
1) 拉取github.com/bigwhite/privatemodule3
我们先建立依赖privatemodule3的go app:
$cat go.mod
module app
go 1.19
$cat app.go
import (
"github.com/bigwhite/privatemodule3"
)
func main() {
privatemodule3.F()
}
此时GOPROXY和GOPRIVATE的设置为:
$echo $GOPROXY
https://goproxy.io|direct
$echo $GOPRIVATE
github.com/bigwhite/privatemodule3
这样可以保证go工具链通过直连方式去拉取privatemodule3。
当我们试图用go mod tidy命令去拉取privatemodule3时,你可能会遇到如下错误:
$go mod tidy
go: finding module for package github.com/bigwhite/privatemodule3
app imports
github.com/bigwhite/privatemodule3: module github.com/bigwhite/privatemodule3: git ls-remote -q origin in /home/tonybai/go/pkg/mod/cache/vcs/2caadc923a575b0b63719d0d8b47b67a3559b4dbae40951b750f317880784ada: exit status 128:
fatal: unable to access 'https://github.com/bigwhite/privatemodule3/': GnuTLS recv error (-54): Error in the pull function.
这是因为go get默认使用https方式拉取repo。如果你没有配置.netrc的方式访问github.com或没有将https请求转换为git+ssh请求,那么即便你在github的personal profile下配置了SSH key,你仍然会遇到上述错误!
解决方法有两种:
- 如果你已经在github personal profile中配置了SSH key,那么你可以通过.gitconfig将https请求替换为git+ssh请求
配置方式为在~/.gitconfig中添加如下内容:
[url "git@github.com:"]
insteadOf = https://github.com/
- 如果你操作github仓库时想使用的personal access token,那么你可以通过配置~/.netrc通过github对go get https请求的鉴权
配置方式为在~/.netrc中添加如下内容:
machine github.com
login user
password your_personal_access_token
上面两种方式二选一即可,无论是哪种方式,配置ok后,再执行go mod tidy,你将成功拉取github.com上面的私有module,就像下面示例中输出的结果那样:
$go mod tidy
go: finding module for package github.com/bigwhite/privatemodule3
go: downloading github.com/bigwhite/privatemodule3 v0.0.0-20230227061700-3762215e798f
go: found github.com/bigwhite/privatemodule3 in github.com/bigwhite/privatemodule3 v0.0.0-20230227061700-3762215e798f
$go run app.go
invoke F of github.com/bigwhite/privatemodule3
在下面的示例中,我们针对github.com上的私有module将使用.gitconfig将https请求替换为git+ssh的方式,之后就不赘述了。
注:在国内通过https请求访问github.com时,连通率较低。而git+ssh的方式,则一般都能拉取成功。
2) 拉取位于github.com上的私有module:mycompany.com/go/privatemodule2
接下来,我们来拉取位于github.com上的私有module:privatemodule2,与第一种情况不同的是,这次privatemodule2有了自己的cannoical import path,即mycompany.com/go/privatemodule2。我们来看看app.go的变化:
// app.go
package main
import (
"github.com/bigwhite/privatemodule3"
"mycompany.com/go/privatemodule2"
)
func main() {
privatemodule3.F()
privatemodule2.F()
}
我们将mycompany.com/go和privatemodule2加入到GOPRIVATE中:
$echo $GOPRIVATE
github.com/bigwhite/privatemodule3,mycompany.com/go,github.com/bigwhite/privatemodule2
此时,由于mycompany.com这个域名并不存在(假设不存在),所以你执行go mod tidy拉取privatemodule2时势必会出现类似下面的错误:
$go mod tidy
go: finding module for package mycompany.com/go/privatemodule2
app imports
mycompany.com/go/privatemodule2: cannot find module providing package mycompany.com/go/privatemodule2: unrecognized import path "mycompany.com/go/privatemodule2": https fetch: Get "https://mycompany.com/go/privatemodule2?go-get=1": dial tcp 52.5.196.34:443: i/o timeout
我们的方案是使用replace指示符将mycompany.com/go/privatemodule2替换为私有repo:github.com/bigwhite/privatemodule2:
//go.mod
module app
go 1.19
require (
github.com/bigwhite/privatemodule3 v0.0.0-20230227061700-3762215e798f
mycompany.com/go/privatemodule2 v1.0.0
)
replace mycompany.com/go/privatemodule2 v1.0.0 => github.com/bigwhite/privatemodule2 v0.0.0-20230227061454-a2de3aaa7b27
前面提到过replace的target如果使用module path,其必须带上replacement version,那么这里的v0.0.0-20230227061454-a2de3aaa7b27是从何而来的呢?这个的确是一个比较烦的事情,不过我们可以通过go list来获取:
$go list -m github.com/bigwhite/privatemodule2@latest
github.com/bigwhite/privatemodule2 v0.0.0-20230227061454-a2de3aaa7b27
注:如果将来privatemodule2有了tag,那么我们就不需使用伪版本号来作为replacement version了。另外这里require中的privatemodule2使用的v1.0.0是一个虚拟的版本号,只是为了满足go.mod的语法要求,真正的版本是replacement version。
接下来的事情就与预期的一致了:
$go mod tidy
go: downloading github.com/bigwhite/privatemodule2 v0.0.0-20230227061454-a2de3aaa7b27
$go run app.go
invoke F of github.com/bigwhite/privatemodule3
invoke F of mycompany.com/go/privatemodule2
3) 拉取位于内部gitlab上的私有module:mycompany.com/go/privatemodule1
最后,我们来拉取位于内部gitlab上的私有module:privatemodule1,与第两种情况相同的是,这次privatemodule1也有自己的cannoical import path,即mycompany.com/go/privatemodule1。我们来看看app.go的变化:
// app.go
package main
import (
"github.com/bigwhite/privatemodule3"
"mycompany.com/go/privatemodule2"
"mycompany.com/go/privatemodule1"
)
func main() {
privatemodule3.F()
privatemodule2.F()
privatemodule1.F()
}
针对内部的gitlab vcs server,我们可以简单的使用.netrc中配置personal access token的方式来使用https请求,配置方法见上面。
go.mod变为:
module app
go 1.19
require (
github.com/bigwhite/privatemodule3 v0.0.0-20230227061700-3762215e798f
mycompany.com/go/privatemodule1 v1.0.0
mycompany.com/go/privatemodule2 v1.0.0
)
replace (
mycompany.com/go/privatemodule1 v1.0.0 => 10.10.30.30/ard/incubators/privatemodule1.git v0.0.0-20230227061032-c4a6ea813d1a
mycompany.com/go/privatemodule2 v1.0.0 => github.com/bigwhite/privatemodule2 v0.0.0-20230227061454-a2de3aaa7b27
)
我们需要将10.10.30.30加入到GOPRIVATE中,这样可以提高获取效率(否则go get会先尝试通过go proxy server获取):
$echo $GOPRIVATE
github.com/bigwhite/privatemodule3,mycompany.com/go,10.10.30.30,github.com/bigwhite/privatemodule2
这里还需要明确一下privatemodule1的伪版本号(v0.0.0-20230227061032-c4a6ea813d1a)的获取方法:
$go list -m 10.10.30.30/ard/incubators/privatemodule1.git@latest
10.10.30.30/ard/incubators/privatemodule1.git v0.0.0-20230227061032-c4a6ea813d1a
注:如果你的gitlab server没有开启https,那么需要设置export GOINSECURE=10.10.30.30。
接下来的事情就也与预期的一致了:
$go mod tidy
go: downloading 10.10.30.30/ard/incubators/privatemodule1.git v0.0.0-20230227061032-c4a6ea813d1a
$go run app.go
invoke F of github.com/bigwhite/privatemodule3
invoke F of mycompany.com/go/privatemodule2
invoke F of mycompany.com/go/privatemodule1
5. 小结
综上,基于当前的go.mod的语法,我们可以实现各种情况下的private module拉取,而无需使用统一的内部go proxy服务。不过,从整个过程来看,这个方案仍然不完美,主要是因为replacement部分使用的是module path,这要求必须搭配replacement version,而这个replacement version的获得方式比较麻烦,尤其是在没有目标repo尚没有tag的情况下。
不过该方案可作为统一go proxy服务方案之外的补充方案。
Go官方也还会继续改进对private module拉取的支持,目前有两个issue可继续跟踪:
- proposal: cmd/go: allow GOPRIVATE to provide source repository URI – https://github.com/golang/go/issues/45611
- proposal: cmd/go: extend syntax go.mod to allow overriding fetch protocol – https://github.com/golang/go/issues/39536
本文涉及代码可以在这里下载 – https://github.com/bigwhite/experiments/blob/master/private-modules
6. 参考资料
- https://go.dev/ref/mod#private-module-proxy-direct
- https://pkg.go.dev/cmd/go#hdr-Remote_import_paths
- https://go.dev/doc/faq#git_https
“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!
著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。
Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily
我的联系方式:
- 微博(暂不可用):https://weibo.com/bigwhite20xx
- 微博2:https://weibo.com/u/6484441286
- 博客:tonybai.com
- github: https://github.com/bigwhite
商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。
评论