本文永久链接 – 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核心技术，并继续加强与星友的互动。欢迎大家加入！

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商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

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2023, bigwhite. 版权所有.

Related posts:

  1. 小厂内部私有Go module拉取方案（续）
  2. 小厂内部私有Go module拉取方案
  3. Go是如何缓解供应链攻击的[译]
  4. Hello，Go module proxy
  5. Go语言包管理简史