项目地址： GitHub - bamboo-cms/bamboo: A CMS optimized for conference hosting
难度：中等
为前后端程序添加 Dockerfile。
我考虑有两种方式，一种是前后端分别创建 Dockerfile，然后引入 Docker Compose 或 K8s 来管理部署。另一种是使用单个 Dockerfile，把前端 build 产物放到后端程序作为 static 文件 serve。
@frostming 你更倾向哪种方式？还是有其他建议
都提供，我们会同时提供 Dockerfile 和docker-compose.yaml
OK，其他几个任务你帮忙确认一下吧，没问题我再公开（可以直接更新任务要求）
都没问题了，更新了一个需求去掉了前端相关的部分
是的，忘记上来认领了 
关于项目中一些中间件的选型，比如数据库、缓存等暂时有敲定的方案吗？@frostming @greyli
我先给出一个后端常用的选型：
)在 Python 中由于其语言特性，因此需要依赖环境来运行，但这会导致其镜像十分大。因此希望了解下在 Python/Flask 容器镜像打包方面有什么最佳实践可以参考？（或者说这就是最优选择？）
我期望可以像 Go 一样充分利用分层构建的特性，压缩其镜像体积（但目前看起来和Java类似，均需要依赖运行时环境）
数据库用SQLite
缓存没有定好像，如果需求比较简单可以用本地缓存，这里我推荐一下cacheout（利益相关，我是contributor）
服务器的话，一般后端gunicorn + apiflask，前端nginx + vue（只是我的个人建议）
缓存方面感觉目前主要需要考虑「多实例」部署的情况.
Docker镜像这块我没看太明白
如果依赖只是单纯的Python环境的话，似乎不是很大。如果您的镜像很大的话，注意选择tag中带“slim”的镜像
如果您说的依赖是指第三方库的话，那可以不必打包到镜像中。可以在docker file中预先定义好安装脚本，在构建容器时，再安装
相对于只有 5-10 M 大小的 alpine 镜像来说，Python 最精简的基础镜像也大了10倍多 XD
这一样会导致镜像体积变大，无法使用到分层构建的特性
这不太准确，核心并不是希望控制在多少内。而是希望看看社区的最佳实践，目前的方案是否已是最佳实践。
技术选型目前确定的是：
其他的 @frostming 定吧。
镜像构建我也没有太多经验，我的想法是没有必要过度追求非常小的 size（？）。在使用 slim 镜像的基础上，可以尝试分层构建，在 build 层安装依赖，在 prod 层只把 build 层的源码和 Python 环境 copy 过去。
缓存这种优化不要太早考虑，现在redis是用来给rq做任务后端的
其实我觉得Dockerfile应该尽量自包含，不依赖外部服务，所以尽量选择本地方案：
并暴露环境变量能让熟悉docker的用户自己定制外部依赖
在docker-compose.yaml里面再做全套的。
这样是非常友好的，提供了三个层面的定制化
千万不要上来就想引入高大上的业界标准，产品都还没做出来，原型就要快糙猛
