这样的微服务目录结构该如何优雅地编译

[wunonglin]

项目目录，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 上级目录的东西。

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

[xuanbg]

COPY ../library/*

[wunonglin]

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

[ttyn]

将 docker 编译上下文设置为根目录，指定 Dockerfile 路径就可以了

# 在 project 根目录运行编译命令
docker build -t myname:mytag -f ./app1/Dockerfile .

[MengQuadra]

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

[wunonglin]

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

[MengQuadra]

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

[hallDrawnel]

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

[waising]

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

[cvl]

-v

[actar]

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

[actar]

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

[joesonw]

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

[wunonglin]

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