关于 Python 项目的生产环境部署

[mickerwx]

现实情况

• 目前公司有很多个项目，其中涉及 django 和 fastapi 两种框架，以及一些大模型服务
• 目前包管理是使用的 miniconda ，然后各个项目直接 nohup 部署在跑，生产加测试差不多有十几个服务
• 服务器涉及公有云和私有云两种，差不多也有 10 来台，包括开发测试服务器、生产服务器、redis 服务器、lvs 服务器、数据库服务器等
• 目前还有部分服务需要和 java 后端那边进行通信

遇到的问题

1. 服务太多管理与更新麻烦
2. 使用 conda 进行环境管理，太多环境了，切换也很麻烦
3. 多个服务使用 http 进行通信，耗时有点长

想想问问各位大佬们你们的生产是怎么部署的

1. 直接部署还是会使用 supervisor 或者 docker 或者 k8s 等
2. 包管理是使用什么进行管理的 venv?conda?还是其他？
3. 多服务之间的通信是 http 还是 rpc ？

[ytmsdy]

使用用 docker-compose 跑就行了，然后在服务器上写 README 就行了

[neotheone2333]

1. docker(compose)
2. pip+requirements.txt
3. http(碰到性能问题最近准备迁移到 grpc)

刚从运维手动启停服务（ nohup ）的模式切过来，目前跑了两个月了没啥问题。就是 Python 镜像有点大，华为云的小水管每次上传要花点时间

[mickerwx]

@ytmsdy
@neotheone2333 这么说的我也去拿 docker 跑项目试试 搞个测试环境先跑跑看

[xiaogu2014]

1. 一般来说 docker 和 k8s 都会上。docker 负责打包 image 。不需要 care 环境依赖啥的。k8s 主要做服务部署编排。。
2. poetry 比较多。
3. 一般来说是 rpc.服务间通信

以及针对你现在的问题：
服务太多管理与更新麻烦-> 如果每个服务环境都相互独立就不不会麻烦了。
使用 conda 进行环境管理-> 这个是在每个 docker image 里面建立不同的环境。所以不需要考虑环境切换的问题。
多个服务使用 http 进行通信，耗时有点长-> 体感上耗时长的话,可能并不是 rpc 能解决的问题。考虑下服务之间数据传输的合理性以及考虑下其他方式？

[vZexc0m]

1.更新麻烦 ->可以选择 Jenkins 之类的做 CI/CD
2.环境管理->docker 、podman
3.http 进行通信内网还好把

django 用 gunicorn 部署 fastapi 用 uvicorn 。用容器就不用关心什么环境问题了

[mickerwx]

@xiaogu2014
@vZexc0m ok 感谢两位大佬 docker 确实能省时省力 不过上 ci/cd 的话 要维护的东西太多了 他们的代码提交很不规范 应该是没办法实现了

[mickerwx]

@xiaogu2014
@vZexc0m
@neotheone2333
@ytmsdy

还有个问题 你们有需要解决并发请求的吗 原本他们解决并发是同一套代码部署多个服务 使用 nginx 做负载均衡 后来我加了 celery ，把这些业务代码放 celery 跑

[xiaogu2014]

看起来你们需一个架构师来把服务微服务化+建立一套完整的 cicd 流程。
这个是一劳永逸的事情。之后别人只需要提交 pr. 等 review.合并。然后一键部署就好了。

[xiaogu2014]

`还有个问题 你们有需要解决并发请求的吗 原本他们解决并发是同一套代码部署多个服务`
这不就是 k8s 帮你干的事情吗。。服务自动扩容/横向/纵向扩容。。

[mickerwx]

@xiaogu2014 唉 别提了 招架构师是不可能的了 除非我自己来搞 但是这种吃力不讨好的活儿 老板看不到 实属没必要

[mirrornighth]

10 多台机器 docker swarm 就够了

[mirrornighth]

1.docker swarm 或 k8s （一般 10 多台 swarm 就沟通）

[defunct9]

天天搞这些，k8s 是正解。

[Hstar]

开发环境用什么做包管理都行, pip/poetry/pipenv, 最后一定要导出一个 requirement.txt, 生产环境只用 pip+requirement.txt 极简. 因为在生产环境再装一个其他东西没必要且还会引入包依赖问题.

[vZexc0m]

@mickerwx #6 CI/CD 不复杂，可以研究下 一劳永逸的事情。自动就部署了。

并发请求是啥意思？同一台机器上一个项目跑多个实例没多大意义。如果之前只是单线程部署的话，部署的时候启用多个工作线程就行了，django 还可以结合 gevent.具体看文档。

[mickerwx]

@mirrornighth 我去瞅瞅这俩 看看能不能用起来

[mickerwx]

@vZexc0m 确实是可以去研究一下 ci/cd 正好最近项目没有啥事情干

[mayi203]

我个人项目，一直是 docker-compose

[adoal]

我建议是先用 systemd unit （首选，除非还要跑在 EoL 很多年的老发行版上）或者 supervisord / s6 / runit 之类的服务管理工具，把服务启停管起来再说，至少不要设备意外重启了后接到电话时哼哧哼哧远程登进去 nohup 。并且在这个过程中逐步梳理项目，学习一下 FSH 之类的基础知识和运维安全知识，养成服务器管理操作的好习惯。

上容器当然也是一种可行的选择。不过把乱七八糟的东西装进容器，只是给屎浇一层巧克力壳，掩盖乱七八糟。

[neotheone2333]

@mickerwx 我们的并发是两套处理，普通 http 请求不必说，定时任务和异步 http 接口做法是：
1. io 密集型的走 fastapi 的 BackgroundTask ，写法用 httpx 之类的库全部改成 async
2. cpu 密集型的走的 celery worker

如果还处理不过来就得加机器了