难部署的taiga,式微的circus——趋势从进程管理到容器管理,简单才是美

时间:2021-10-25 21:21:14

一直需要一个项目管理系统,一直没时间弄。

taiga是github上搜project management star最多的项目,又是基于django用python写的后端,所以就用它:

难部署的taiga,式微的circus——趋势从进程管理到容器管理,简单才是美

但是,集中精力折腾了一下,给我的感觉并不好。

taiga的部署,总的来说非常难受。

我没想到一个后端用django做api 前端coffee-script的玩意,竟然搞这么多配置文件,各种配置项互相引用。

它完全没赶上容器化的趋势,没有提供官方的docker镜像。

官方的部署教程, 读下来总体感觉就是乱。东1个配置文件,西1个配置文件,往下读后面还经常给出另外版本的配置文件。把http改成https,居然是多配置文件,每个给2个版本。TM有病啊。

越是难部署的过程,就越值得脚本化、容器化部署。但它复杂到搜taiga docker   项目好几个,但星级都不高,而且做法也都五花八门。

难部署的taiga,式微的circus——趋势从进程管理到容器管理,简单才是美

这些星级多的,也仅仅是按官方的前后,分成了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年获各种奖。

难部署的taiga,式微的circus——趋势从进程管理到容器管理,简单才是美

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

而它当年(2013)打出的卖点是:

1它支持py3,而supervisor不支持,

2它1个可以负责各种服务,取代 supervisor 和gunicorn 两个

难部署的taiga,式微的circus——趋势从进程管理到容器管理,简单才是美

难部署的taiga,式微的circus——趋势从进程管理到容器管理,简单才是美

但是今天:

circus:

难部署的taiga,式微的circus——趋势从进程管理到容器管理,简单才是美

supervisor

难部署的taiga,式微的circus——趋势从进程管理到容器管理,简单才是美

gunicorn

难部署的taiga,式微的circus——趋势从进程管理到容器管理,简单才是美

注意虽然这些年这些都不再活跃了,但是在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却仍然是成功的:
 
没有明显的竞品出现!定位精准
 
——这是必须学习的