用 docker compose 做调试的困惑

[raw0xff]

服务端开发时，每次调试都先编译程序，和其他相关文件一并都覆盖复制到一个本地临时目录，启动 docker compose,容器内建立目录映射到本机临时目录，容器内再分别把文件复制到容器中相应的位置，容器中启动程序。以上步骤都通过本地脚本和 compose yaml 的 command 实现。

想求教一下彦祖们，这种操作姿势是否正确？有没有更好的调试方式？

为什么我总会遇到明明代码没问题，但在容器中会得到莫名其妙的错误，然后让 docker 重启一下就能恢复正常。当不能确定是代码问题还是环境问题时，每次排查都很浪费时间。

[SenLief]

@raw0xff compose 主要是编排，让多容器可以容易组合，你不应该让他参与过多的事物，如果容器启动前需要处理事务，我觉得还是用启动脚本比较好。另外容器应该是最小化的应用，你这个是把 nginx 也打包到 dockerfile 中去吗？为何不用单独的 nginx 容器呢？

[Lax]

1. 把编译过程写进 dockerfile
- 编译过程是指程序的编译吗？我是写入启动脚本.sh 文件中，编译后再 up 。
---- 指的就是程序的编译（ go build 或者 java 之类的 build ）。编译软件的版本对生成结果有影响，本机编译和环境一致的目标相悖，这是第一个隐患。

2. 把文件夹创建、文件复制过程写进 dockerfile
- 文件复制 我是想区别不大，索性都放在 compose 中方便调试。
---- 不认同这条，可以放弃使用容器了。

3. 编译过程的镜像和运行阶段的镜像分离，使用多阶段构建
---- 补充：多阶段构建和上面第一条有关。

4. 尽量少用 volume
- 少用 volume 的原因是什么？防止文件 io 冲突吗？之前遇到过，所以就复制进容器内了。
---- 跟 io 没关系。具体去看文档

5. nginx 单独容器，除非是做 nginx 功能相关开发
- 项目中有 web 部分，所以 dockerfile 中 add 了安装 nginx ，容器启动时启动 ngixn 。
---- 没有因果关系，“所以”没意义。巨大的单个容器可以只用 docker 没必要 compose 。既然用了 compose ，就要考虑多容器的优势，拆分 nginx 、Redis 、MySQL 等基础组件容器，拆开后也很容易支持动态和静态。

6. dockerfile 或者 composefile 都有 env 相关的功能
- 对 env 有一些逻辑判断，所以写入 sh 。
---- compose 的 env 功能支持简单逻辑。env 只存环境相关变量。少量逻辑放在启动脚本完全没问题。

7. compose.yml 里给每个服务取有意义的名字
- 好嘞
---- 好嘞

[klo424]

dockerfile + docker-compose.yml + gitlab ci/cd ，最后 docker ps 查看状态，docker log [container id] 查看日志。

[raw0xff]

@SenLief 不好意思的说，主要是不懂怎样单独用 nginx 容器：）只会用已知的方式实现。

[raw0xff]

@Lax 用 compose 是为了模拟网络环境，生产环境是应用程序和 nginx 直接运行在节点上没有用到 docker ，所以选择容器中装 nginx 而没有单独用 nginx 容器，不知道这样做对不对请指教。

[SenLief]

@raw0xff compose 编排多容器，nginx 作为一个容器，依赖 web 应用就可以。

[cdlnls]

所以有没有可能，在你的这种场景下并不适合用 docker-compose 来调试程序，程序调试的时候，直接在本机跑和调试，应该是最方便的。看了你的 docker-compose.yml ，也是感觉不用 docker-compose 应该是一个更好的选择。

[Lax]

这种很基础的应用场景，compose 文档讲的很清楚，花两三个小时通读一遍，很多问题自然就能解决了