hy這個破項目

最近部署hy記事

這段時間攤上了個挺噁心的項目，叫什麼hy鞋同平臺。。先後左右整的人挺難受的。學到的東西特別少，並且比較浪費時間。不過，仍是總結一下吧，好歹花了這麼久的時間了

---

Doc管理xi tong

話說這個hy平臺的原由，罪魁禍首就是6月份開始調研的wen dang管理系統。只從技術角度說說吧。

wendang管理系統調研:

• Sea-(f！)ile 國產的，廣告作的挺響亮，下一代wendang管理軟件.
• Open-(K！)m 國外的開源軟件，Java寫的，功能挺全面，可是就是很複雜
• 調研狀況：後者使用到了不少的Java組件，各類各樣的什麼都有。對於我Java盲而言確實比較費勁。但第一次接觸到了Java的強大，並且理解爲何企業系統是Java在一統天下（若是有一天能有機會接觸Java項目，我確定第一個上）。
  -- tomcat服務器：企業級的應用服務器，保證了穩定性和效率
  -- hibernate數據庫驅動：任意鏈接全部數據庫，強大到沒法自拔
  -- elasticsearch及其基於的lu什麼搜索引擎：搜索就靠它了，無縫集成毫無問題
  -- 還有Spring框架什麼的，這個我一點不懂
• 開源選型最後定爲了前者，儘管後者功能強大，可是聽說主體開發團隊不喜歡Java，因而乎，python和C勝出了。今後開啓了痛苦的開發歷程。

audit 審計

我這塊負責審計功能的開發，就是把用戶在系統上的操做都記錄下來。這兒最初的思想十分簡單，就是找到源碼中相應的執行操做的點，把審計函數插入進去就好了，傳入一些相關的參數便可。也是第一次接觸django，剛開始手足無措，後來才知道有url.py文件，才慢慢從前端js跟蹤到了後端的python函數，將審計函數插入其中。剛開始作的時候想起了linux系統自帶的審計，記得它也是將某個審計函數插入在所需的地方，而後經過一些配置文件可以對審計的開啓、關閉，審計信息的詳細程度進行配置。咱們這裏就不用這麼複雜了。。寫了個簡單的審計函數，先將數據丟進es去了。以後有了其餘組作好了mysql Rest API，就把es換成他們得api了。其實都是同樣的：寫了個函數，調用python的curl模塊，繼而調用Rest API。後來發現有時curl速度比較慢，影響到了用戶的頁面體驗。而後就調研django異步執行框架celery，將curl函數一包裝，放進celery的worker裏執行，這樣就不影響頁面響應速度了。不過，這裏尚未作的地方是審計函數的執行結果沒有進行判斷（成功or失敗？）。其實想了一個方案，把結果丟進redis裏，隨後找個午夜時間（定時執行也靠celery框架）用相關函數處理一下（但後來沒實現這方案）。

部署django項目

哎呀，這塊剛開始時候但是被整的。。系統依賴的軟件包、python模塊至關的多，並且沒有提供自動部署腳本，致使大量時間浪費在了部署上面。不過，也正由於此，才致使我碰見了docker這貨。當時因爲部署複雜，開發組專門提供了一個虛擬機鏡像，裏面預裝好了全部依賴包。可是該鏡像竟然有8.0G大小，攜帶、傳輸都十分困難（百度網盤也不支持這麼大的。。。），致使沒有什麼卵用。而後就想起了過年來的時候調研過docker，它不就是作依賴包封裝、持續集成用的嗎？很興奮的用起docker來，果不其然，特別方便，鏡像作出來也特別小（不多超過1G）。更好的地方是部署、遷移、更新、啓動、關閉速度都遠遠優於笨拙的虛擬機。接着，我將本機的全部服務都搞成docker容器了。。。（當時熱衷於此，以爲是趕時髦了），而後還搞了mesos+zookeeper+marathon來管理本機的這五、6個容器。真是不亦樂乎。要說docker有什麼缺點，那就是沒法跑在win系列機器上（可是據說win也支持docker了），其餘方面都是優勢，用起來大大的爽，部署時間從2-3天減小到2-3個小時。
隨着docker使用的頻繁，也想試試持續集成是什麼鬼。因而本身鼓搗出一個方式。因爲在本機以前搭建過一套gitlab服務器，就想着怎麼能把他們聯繫起來。我寫好代碼以後，push到gitlab上，而後利用git的hooks方式，判斷本次commit的代碼註釋（-m）是否帶有[deploy]字樣的，若是有，就進入一個特定目錄執行pull操做。該特定目錄是mount在docker容器內的。仍是在hooks這個腳本中，執行docker exec命令，進而在容器內部執行部署腳本（部署腳本也是在commit的源碼中）。而後就大功告成了，容器中會對源碼進行編譯、安裝、服務啓動。也就是說，開發完後直接執行push，而後就等着刷新瀏覽器吧！自覺得體驗到了持續集成的一點小優點~（可是整個過程的最後一步docker exec沒有實現，當時好像是由於docker版本過低，還不支持exec命令。當時都是人工進容器，而後執行部署腳本的。。。）

此過後記：今後對docker感興趣，最近又本身看了看go語言的書 。。。想着啥時候能看看docker的源碼呢！

被逼使用Openstack

不知是爲了實際做用仍是說爲了能讓項目花哨點兒、有料點兒，後來提出了讓各個服務部署在Openstack虛擬機上，列出了一堆堆Openstack的優點。
可是當時的形勢是我在本身機器上已經經過docker基本構建起了hy平臺的各項服務，又由於對新東西Openstack不熟，因此情緒仍是蠻抵制的。不過也是久聞大名了，也看到不少帖子寫到爲何docker能替代Openstack的爭論，後來仍是老老實實開始了Openstack的調研（其實主要是領導熱衷於這個。。 我固然不得不去作了）。
可是，此處應該記住教訓，不要對新東西猶豫不決，不去用過，是沒有發言權的。
雲計算這麼火，Openstack做爲雲平臺的管理軟件，起着核心的做用。咱們的hy平臺運行的服務大概有五、6種，初步思想是把每種服務都單獨運行在一臺實例上。因而乎開始調研，而後嘗試安裝K版；在安裝基本完成時，官網又發佈了L版。。
下面總結這個過程當中的關鍵點。首先是部署結構的設計。devstack使用單機部署全部服務，但官網的手動部署教程是使用控制、網絡、計算三節點的部署方式。我使用後者在virtualbox上搞了一套L版。而後，最重要的就是網絡配置部分，這裏要首先理解原理而後再進行部署才行。在這塊剛開始弄的時候，一頭霧水，搞了三、4天沒有頭緒，由於想趕忙把環境搞起來，可是根本不瞭解原理，瞎打瞎撞。這些相關資料網上都有，並且這裏的思想就是SDN，學習一下這些技術仍是很使人興奮。最後，還有一個關鍵點是備份。咱們部署中間有一次斷電了，而後重啓後各類都起不來。。 這時所需的應該是將虛擬機鏡像進行斷電前備份、斷電後導入；導入包括從控制節點1導入控制節點二、從控制節點導入宿主機kvm，其實方法都是同樣，就是把實例的虛擬磁盤搞出來就好，這塊要理解kvm虛擬磁盤的格式、backing file、打快照的方法等。

被文檔折磨的死去活來

需求文檔寫了將近一個月，緊接着開始寫設計文檔。實際上咱們的系統基本已經成型（反正是基於開源的搞的），可是上面要求用寫文檔的形式理順目前作的事。
寫文檔過程當中的經驗教訓。首先，心態要好。作程序猿雖然說應該以代碼爲重，可是文檔任務也不能掉以輕心。能敘述的清楚的程序猿，編碼起來才能行雲流水。文檔中的文字描述、流程圖之類的能很好的幫助思路。不要抵制，既然是工做，就不是本身想怎樣就怎樣的；任務分下來了，那就認真對待，好好作。不要區分任務的等級高低、類型貴賤（不要分髒活累活仍是好活），無論啥活，用心認真作了，學到的東西就是本身的。而後，網上粘貼的東西要仔細過兩遍，不能爲了堆砌篇幅而瞎貼。其實仍是回到以前說的，不要用應付的心態去作這件事。
是挺難受的，我認可。需求文檔、設計文檔寫了好幾稿，都被打回來。仍是那句話，對於有些任務，真的心態要好。

補充內容

此次項目讓知識面拓寬了很多。一直在思考是要廣仍是要精的問題，在目前的工做環境下，作的活雜七雜八，接觸東西不少，在廣上有優點。但我仍是想肯定好本身的方向，好比雲計算，好比虛擬化。興趣我是有的，但這得本身努力了。據說要作開發者很難的，天天下班、週末都應該去學習、看代碼的。本身仍是差太遠了。