标签：工程 简单 开发 api 文件 py3 导致 全局 nbsp
taiga是github上搜project management star最多的项目：
taiga的部署，总的来说非常难受。我没想到一个后端用django做api 前端coffee-script的玩意，竟然搞这么多配置文件，各种配置项互相引用。
它的官方部署教程, 完全没赶上容器化的趋势，读下来总体感觉就是乱：东1个配置文件，西1个配置文件，往下读后面还经常给出另外版本的配置文件。把http改成https，居然是多配置文件，每个给2个版本。TM有病啊。
越是难部署的过程，就越值得脚本化、容器化部署。但它复杂到搜taiga docker 项目好几个，但星级都不高，而且做法也都五花八门。
最不爽的地方集中在：
1 把git clone写在dockerfile里了，但是TM工程是会演进变化，有BUG的！这样看都不看直接打包进去，直接后果就是taiga配置项变化和小错误导致的部署失败，有些taiga docker 的作者都不知道怎么改。（其实老实把代码下载下来看看，都不难的）
2 因为难部署，所以为每个镜像再写点sh。本来就觉得配置复杂了啊，还要每个镜像再加点sh脚本。虽然一时配好了没问题，但是更增加了复杂度
总的来说——不满足：一处修改，多次执行的要求，而是到处修改，1次执行。
以至于，我哪个都觉得别扭，参考它们之后，自己搞了一套。
总的原则是：
1代码和配置文件尽量都放在镜像外，启动时用-v挂进去。
2保证眼睛能看到到挂进去、COPY进去的都是什么东西.而且位置要集中，不要让我到处翻看（git clone 肯定得放外面）
3配置项太杂，配置文件太多，互相依赖（各端口号、主机名、本地路径、SERECT_KEY之类）需要脚本自动产生配置文件，自动添加配置文件
简单说：把所有值得配置的参数集中到唯一1个yml配置文件里，然后搞一套各种配置文件模板（包括全局的docker-compose, 和back front events db rabbitmq celery_work的dockerfile 以及需要COPY进各image的配置文件）。
运行的时候大致步骤：
读全局yml参数
用jinja2渲染出各配置文件
git clone下载好taiga各工程代码
执行docker-compose up（用它调用各镜像的build和容器启动）
——结果几天下来，一不留神就写成了1个工程。
回头看，其实是taiga的开发、部署统统落伍了。
taiga是2014年开发的，2015年获各种奖。
它官方安装文档里 前后端进程管理工具，用是circus。星级不高，近期也不活跃了
它当年打出的卖点是：它1个取代 supervisor 和gunicorn 两个：
当年2013左右，还能搜到文章提到它，说它思路新，支持py3，是supervisor 的替代品。但是今天：
supervisor
gunicorn
直到今天，supervisor 官方还是说不要在生产环境用py3版的。
但是我照样用supervisor。为啥？因为gunicorn 有py3的版本就够了啊！
单机上的服务启动是 supervisor(py2)-> [ gunicorn(py3), nginx]
gunicorn(py3)再启动app 就OK了
为什么对进程的管理变得更简单了（或者说，保存简单就够了，不需要更复杂的管理工具）？
因为单机运行多个服务的方式变了，从多进程，变成了多容器。
所以，不再是进程管理工具之间的竞争，而是加入了docker, k8s这些玩意。
监控、控制服务的启动停止 从使用进程管理工具，到在docker-compose里设置restart 就可以管起来，端口设置ports就管起来了。
这样就保证了每个容器内部，跑的进程都不复杂（甚至比原来还简单，种类还少），但还多少需要点管理工具，所以supervisor gunicorn仍然活的很好，而试图取代它两个的复杂的circus，却衰落了。
难部署的taiga，难用的circus——从进程管理到容器管理，简单才是美
标签：工程 简单 开发 api 文件 py3 导致 全局 nbsp
原文地址：http://www.cnblogs.com/xuanmanstein/p/8016296.html
