项目目录，app1 和 2 均引用了 library 的包

• project
  • go.mod
  • go.sum
  • docker-compose.抗投诉服务器yml
  • app1
    • Dockerfile
  • app2
    • Dockerfile
  • library
    • tool1
    • tool2

Dockerfile 长这样

FROM golang:latest as build

COPY . /data/
WORKDIR /data/

RUN go build -o dist/main cmd/main.go

FROM scratch

WORKDIR /app

EXPOSE 80

CMD ["./main"]

这样 docker-compose 编辑 Dockerfile 的话会报找不到 library 的引用，因为没有 copy 进来。但是好像 Dockerfile 的 copy 不能 copy 上级目录的东西。

所以现在的问题是如何能够优雅地编译微服务？

COPY ../library/*

复制不了 Dockerfile 外层的文件，用*会打平目录结构

将 docker 编译上下文设置为根目录，指定 Dockerfile 路径就可以了
在 project 根目录运行编译命令
docker build -t myname:mytag -f ./app1/Dockerfile .

我选择 Dockerfile 全部放上级目录
Dockerfile.app1
Dockerfile.app2
疑似能少打几个字符....

其实 app 的数量和层级不定的。假设有 100 个 app，全放在根目录，想想都感人

太多还是分开吧...少的我感觉更直观, 多起来真是脑壳疼

每个会被独立编译的服务我们都有自己的 go.mod 来解决依赖问题。这样做好处很多，具体见 https://medium.com/@ckeyes88/go-modules-in-real-life-87a21fb4d8aa

我是把所有的自定义依赖包 功能包都弄成私有 git 仓库 mod 方式引进不同的项目里

-v

go mod vendor 生成 vendor 目录,打包时带上 -mod=vendor 选项

我看了一下，需要每个目录里面都有 go.mod 。和我想的不太一样

monorepo 最优雅的解决方案就是上 bazel 了.

是的。我是按 B 站开源项目学习的，bazel 的确还行，只是还不好学