如何使用 docker 和 monorepo 组织共享库答案

【问题标题】：How to organize shared libraries with docker and monorepo如何使用 docker 和 monorepo 组织共享库
【发布时间】：2020-02-25 19:01:00
【问题描述】：

我有什么

我有 2 个 python 应用程序共享一些代码，足以让我尝试将共享部分隔离到模块/包/库中（我故意使术语含糊不清，因为我不确定解决方案是）。我所有的代码都在一个 monorepo 中，因为我希望克服管理比团队成员更多的 repo 的一些烦恼。

目前我的文件布局如下：

+ myproject
  + appA
  | + python backend A
  | + js frontend
  + appB
  | + B stuff
  + libs
    + lib1
    + lib2

appA 和 appB 都使用 lib1 和 lib2（它们本质上是抽象出共享数据库的数据模型）。 appA 是一个包含多个组件的 webapp，并非所有组件都是 python。它被部署为一个涉及一堆容器的 docker 堆栈。我使用poetry 管理我的依赖项以确保可重复构建等...每个python 组件（appA、appB...）都有自己的pyproject.toml 文件、虚拟环境等...

appB 单独部署。

所有开发都在 linux 上，如果有什么不同的话。

我需要什么

我正在寻找一种干净的方式来处理库：

appA 的开发在本地 docker-compose 设置中完成。后端会在文件更改时自动重新加载（使用 docker 卷），我希望它也适用于库中的更改。
appB 的开发更简单，但正在转移到 docker，因此问题将是相同的。

我尝试过的

我最初的“解决方案”是将 libs 文件夹复制到 appA 中的一个临时位置进行开发。它适用于导入，但一旦我想更改库代码（这仍然很常见），它就会很混乱，因为我需要更改原始文件，复制，重建容器。
我尝试将库符号链接到后端的 docker 环境中，但符号链接似乎不适用于 docker（它似乎没有跟随链接，因此文件不会最终出现在 docker 映像中，除非我本质上是复制 docker build 上下文中的文件，这违背了链接的目的。）
我尝试将每个 lib 打包成一个 python 包，并通过 poetry add ../../libs/lib1 安装它们，这在 docker 中实际上不起作用，因为路径不匹配，然后我回到符号链接问题。李>

我确信有一种干净的方法可以做到这一点，但我想不通。我知道我可以将 repo 分解成更小的 repo 并安装依赖项，但是开发仍然会在 docker 内部引起问题，因为每次更改 lib 文件时我仍然需要重建容器，所以我宁愿保留 monorepo。

【问题讨论】：

如果您仍然使用 docker-compose，您可以使用卷在您的容器中挂载本地库，并能够在您的主机系统和容器中编辑它们。不是超级花哨，但应该可以，对吧？
目前我有一个像path/to/appA_source:/app 这样的卷，所以你是说我可以添加像libs/lib1:/libs_in_container/lib1 这样的东西？如果我这样做，实际部署会发生什么？那我就直接把文件复制过来吗？
那么，您将如何为 appA 进行部署？您不会将卷挂载用于实际部署到生产，因此您可以使用应用程序和库构建映像，并且只能在您的工作站上通过卷挂载覆盖数据
@ckaseer 您的建议似乎确实有效。简而言之，在我做COPY ../libs/lib1 /app/lib1 的docker 文件中，然后为了本地开发，我将../libs/lib1 挂载到/app/lib1 上。这给了我我正在寻找的行为。我为此使用了一个拆分的 docker-compose 文件。该设置会导致需要一些额外配置的各种工具出现一些问题，因此他们知道库是代码库的一部分，但没有什么不可能的。感谢您的想法！

标签： python docker docker-compose python-poetry

【解决方案1】：

如果您仍然使用 docker-compose，您可以使用卷将本地库挂载到您的容器中，并能够在您的主机系统和容器中编辑它们。不是很花哨，但应该可以，对吧？

@ckaseer 你的建议似乎确实有效。简而言之，在 docker 文件中，我执行 COPY ../libs/lib1 /app/lib1，然后为了进行本地开发，我将 ../libs/lib1 挂载到 /app/lib1 上。这给了我我正在寻找的行为。我为此使用了一个拆分的 docker-compose 文件。该设置会导致需要一些额外配置的各种工具出现一些问题，因此他们知道库是代码库的一部分，但没有什么不可能的。感谢您的想法！

因此，即使它不是本地安装在应用程序和 lib 目录上的理想解决方案，也适用于 Linux 系统。

仅供参考：在 Windows 主机上，如果您想监视文件更改可能会遇到麻烦，因为文件更改不会从 Windows 主机传播到 Linux 容器。

【讨论】：