一直需要一個項目管理系統，一直沒時間弄。
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，要引以為戒，不要把產品搞成這個樣子，這是犯了路線錯誤啊啊啊。