難部署的taiga，式微的circus——趨勢從進程管理到容器管理，簡單纔是美

一直須要一個項目管理系統，一直沒時間弄。

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卻仍然是成功的：

 

沒有明顯的競品出現！定位精準

 

——這是必須學習的