难部署的taiga，式微的circus

sunfull

　　一直需要一个项目管理系统，一直没时间弄。
　　taiga是github上搜project management star最多的项目，又是基于django用python写的后端，所以就用它：

　　但是，集中精力折腾了一下，给我的感觉并不好。
　　taiga的部署，总的来说非常难受。
　　我没想到一个后端用django做api 前端coffee-script的玩意，竟然搞这么多配置文件，各种配置项互相引用。
　　它完全没赶上容器化的趋势，没有提供官方的docker镜像。
　　官方的部署教程, 读下来总体感觉就是乱。东1个配置文件，西1个配置文件，往下读后面还经常给出另外版本的配置文件。把http改成https，居然是多配置文件，每个给2个版本。TM有病啊。
　　越是难部署的过程，就越值得脚本化、容器化部署。但它复杂到搜taiga docker   项目好几个，但星级都不高，而且做法也都五花八门。

　　这些星级多的，也仅仅是按官方的前后，分成了2个镜像而已。有的也没有配官方给的taiga-events  没有celery。
　　我真正参考的是一个只有10星的（有颗还是我打的）项目：https://github.com/douglasmiranda/docker-taiga
　　优点是

　　1除了3个官方工程backend frontend events之外，还独立出了postgres的db，rabbitmq，celery_worker
　　2用了docker-compose，-配置了端口和存储路径，docker-compse up 直接启动

　　这才真正有点体现容器化的优势的意思。而且rabbitmq和celery的部署套路，对手里自己的项目的容器化部署，也有很好的借鉴意义（自己写的docker版的rabbitmq和celery的小demohttps://github.com/xuqinghan/celery-with-docker-compose）。还是给作者点个赞.
　　不爽的地方集中在：

　　1 把git clone写在dockerfile里了，但是taiga工程本身是会演进变化，有BUG的！这样看都不看直接打包进去，直接后果就是taiga配置项变化和小错误导致的部署失败，有些taiga docker 的作者都不知道怎么改。（其实老实把代码下载下来看看，都不难的）
　　2 因为难部署，所以为每个镜像再写点sh。本来就觉得配置复杂了啊，还要每个镜像再加点sh脚本。虽然一时配好了没问题，但是更增加了复杂度

　　总的来说——不满足：一处修改，多次执行的要求，而是到处修改，1次执行。
　　最终，这些用docker部署taiga的项目，我哪个都觉得别扭，参考它们之后，自己搞了一套。
　　总的原则是：

　　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个工程https://github.com/xuqinghan/taiga-docker-compose。
　　回头看，其实是taiga的开发、部署统统落伍了。
　　taiga是2014年开发的，2015年获各种奖。

　　它官方安装文档里 部署时的进程管理工具，不是常用的supervisor，而用是circus。星级不高，近期也不活跃了。因为没人维护，导致在容器环境下，难安装（debian系的没有官方apt源，只有ppa，但其实也是2013年的，现在不能用），难用（自己添加服务脚本）：
　　而它当年（2013）打出的卖点是：

　　1它支持py3，而supervisor不支持，
　　2它1个可以负责各种服务，取代 supervisor 和gunicorn 两个

　　但是今天：
　　circus:

　　supervisor

　　gunicorn

　　注意虽然这些年这些都不再活跃了，但是在2014-2017，后两个的人气还是比circus大太多了（2013之后几乎没人管了）
　　再看它的2个卖点：
　　1 py3：
　　直到今天，supervisor 官方还是说不要在生产环境用py3版。
　　但是我照样用supervisor。为啥？因为gunicorn 有py3的版本！
　　单机上的服务启动是 supervisor(py2)-> [ gunicorn(py3),  nginx]
　　gunicorn(py3)再启动app 就OK了
　　2 1个人伺候多种服务：
　　这个问题更有意思了，可以说，随着容器的崛起，这个问题直接不存在了。
　　为什么对进程的管理变得更简单了（或者说，保存简单就够了，不需要更复杂的管理工具）？
　　因为单机运行多个服务的方式变了，从多进程，变成了多容器。
　　当年它图里的redis等等这些玩意，都拿出去放到单独的容器里了。
　　所以，不再是进程管理工具之间的竞争，而是加入了docker,  k8s这些容器管理工具。
　　从更高抽象层次（虚拟环境 操作系统），对配置工作进行了切分。
　　监控、控制服务的启动停止  从使用进程管理工具，到在docker-compose里设置restart 就可以管起来，端口设置ports就管起来了。
　　这样就保证了每个容器内部，跑的进程都不复杂（甚至比原来还简单，种类还少），但还多少需要点管理工具，所以supervisor gunicorn仍然活的很好，而试图取代它两个的复杂的circus，却衰落了。
　　应对复杂问题的演进：共性是：

　　通过建立多个抽象层次，在每个层次上让任务保持、或者变得更简单；而不是在某1个维度上，变得更复杂。

　　知识不是1条线，也不是2维的书架和窗格，而是一个宫殿。
　　而跨抽象级别的映射，决不孤立。所以架构和套路，是可以复用的。
　　taiga项目显示出技术发展快速的残酷性：3年前这种前后分离的架构，也许是惊艳的，但是现在优劣互现了：
　　优势：
　　1后端用古老的django做api（易开发）；
　　2前端分离出来，可以搞得很好看；
　　但现在：
　　1部署方式落后，进程管理工具circus完全式微；
　　2前端的coffee-script angularjs已经落伍（ts+ ngx了）；
　　——对taiga要学习优点（前后端分离，前后端的技术寿命完全不一样），对缺点要尽量避免（难部署）。
　　——对circus，要引以为戒，不要把产品搞成这个样子，这是犯了路线错误啊啊啊。
但在业务和产品定位上，taiga却仍然是成功的： 没有明显的竞品出现！定位精准 ——这是必须学习的