大公司搞 SRE 还可以，普通的运维就算了。

@allAboutDbmss 顺便提一句，PR 是 GitHub 的概念，不是 git 的。kernel 还是用原生 git 的那一套

你是不是在找 https://git.kernel.org ？子项目的合并过程，一般都是核心开发者在各自 repo 上做。
Kernel 相关的资源，在 kernel.org 首页上开始找都能找到。

"并且同步也是他在安排"??? 用 git 的普通流程不会出现“同步”这个词汇，虽然是小作坊这种核心资产还是应该用心一些。

浏览器的网页部分本体是什么编码方式？

先问问有多少用户？

如果让用户上传，要考虑的事情就太多了。需要对上传的文件做验证，还要管理用户的密钥，每一步都有大坑
用 certbot 管理 nginx 的证书，一行命令就能搞定。lua 脚本去做动态管理，或者 caddy 之类的工具也很多。

看着功能一堆，全是没用的形容词

可以搜到了。现在相当于 V2EX 给了外链

要是有信心压制对方，把薪资要求提高，也不是不能试试。

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

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 里给每个服务取有意义的名字
- 好嘞
---- 好嘞

初步建议：
1. 把编译过程写进 dockerfile
2. 把文件夹创建、文件复制过程写进 dockerfile
3. 编译过程的镜像和运行阶段的镜像分离，使用多阶段构建
4. 尽量少用 volume
5. nginx 单独容器，除非是做 nginx 功能相关开发
6. dockerfile 或者 composefile 都有 env 相关的功能
7. compose.yml 里给每个服务取有意义的名字

即使写了这么啰嗦，甚至最重要的代码编译过程并没有被容器所管理

十年来第一次见这么长的 command ，真的啰嗦，每一行都在藏隐患

@cmmulxuk 如果理解这几行的差异，就不会写出这样的失误。想解决问题先拿张纸画一下部署的逻辑结构吧，不是随便抓住一根稻草就能救命。

配置里的 upstream 是 443 和 80 端口，日志中的是 upstream 是 8008 端口。
原因就藏在你认为没关系而替换的这几行。

三个 proxy_pass 搞出三种风格：
proxy_pass https://example.com/;
proxy_pass https://example.com;
proxy_pass http://example.com;