打包其實分為 4 個問題：Python 解釋器怎么辦？

項目的依賴怎么辦？

項目自身的代碼怎么辦？

項目配置如何管理

Python 自身其實缺少一個像 Jar 一樣的打包格式。因此這里沒有標準的解決方案。pex，buildout，甚至 bazel 都在嘗試解決這些問題。針對上面 4 個問題，解決方法分別如下：實際生產環境中，一般不會把 Python 解釋器打進去，解釋器太大會造成分發代碼比較慢。解釋器本身很標準，可以預先安裝到機器中。

項目依賴我們選擇每個項目獨立打包自己的依賴，必須隔離。不選擇全局 pip install 的方式，因為一旦需要運行多個項目切依賴版本沖突就直接SB了。還有就是線上安裝包其實是高危操作，每次部署都要 install 一遍也容易跪在網絡上，太不可靠了。

自身代碼怎么辦？有些打包格式會移除 .py 文件只保留 .pyc。這個各家情況不同根據自己的情況定就好。需要注意的是要把 .git 目錄給排除掉，一個是減小體積，還能一定程度防止有開發線上給你熱部署代碼去。

配置管理，我個人其實傾向于配置是代碼的一部分，應該放在一起。不過實踐起來爭議太大，這個就不給結論了。一般公司都有配置管理系統，靜態配置管理，還有些可以實時生效的。生產環境下，配置管理系統可能會成為性能瓶頸或者不穩定因素。

基于上面的選擇，最終的方案是：pipenv (或 buildout) + .tar.gz 的方式。打包過程在 CI 中完成，連代碼帶依賴壓縮好，去目標服務器上直接解壓縮就好了。

上面沒有談到容器環境下該如何處理，其實方案是一樣的。在 Docker Image 里安裝好 Python 解釋器，然后將上一步打包好的代碼解壓縮到 Docker Image 中就可以了。實踐中我們選擇每個 app 每次 commit 都會對應一個唯一的 Docker Image 作為部署的權威版本。Docker Image 的分層存儲保證雖然 Image 很多，但是不會占用太多額外空間。

總結

以上是生活随笔為你收集整理的python管理系统项目首选公司_Python 项目的部署，目前互联网公司有哪些成熟的方案？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。