DockOne技術分享（四十）：用Docker和Git搭建線上開發環境

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

免責聲明

以下分享的內容是個人在業餘時間的一些經驗，並不代表IBM的觀點。

為什麼要在雲端搭建開發環境

如今，在傳統的開發模式下，版本控制，自動化測試，持續整合都已經陸陸續續放到的雲端。

• 測試工程師，可以用過自動化測試指令碼在雲端做大規模的迴歸測試
• 營運工程師，可以通過自動化的部署工具在雲端快速部署應用
• 產品負責人，可以通過版本控制工具控制產品的發布

唯獨開發工程師還在利用手中的電腦，筆記本等裝置來完成開發工作。
在項目開發階段，我們通常面臨下面幾個問題：

1. 在項目啟動階段，如何讓開發工程師快速搭建，並配置開發環境，來縮短項目啟動時間和成本。
2. 在項目開發階段，如何讓開發工程師有：
   
   • 完全相同的開發環境，來降低調試成本。
   • 近似於產品環境的架構，來降低部署時因環境差異帶來的風險。
   • 降低對開發裝置效能和種類要求，來降低裝置成本。
   • 靈活的分配開發資源（CPU，記憶體，儲存），讓需要大量開發資源的工程師快速拿到資源。

雲端開發環境要解決的問題總結

基於以上思考，我總結了以下4個雲端開發環境要解決的問題：

• 保證每個開發工程師都能快速的獲得一致的“開箱即用”的開發環境
• 開發環境擺脫開發裝置的種種限制，例如作業系統，裝置效能
• 讓開發環境儘可能類比產品環境的結構。
• 靈活的分配開發資源

在雲端搭建開發環境的挑戰

一個“開箱即用”的開發環境應該包括：功能完備的代碼編輯器， 一個應用運行環境，一個調試工具箱。

• 為了擺脫裝置的限制，整合式開發環境可以用HTML5等主流瀏覽器安全色技術實現。
• 為了靈活的分配資源和類比產品環境，可以將應用運行環境放在雲端，並使用容器技術配置。
• 調試工具包括日誌的輸出，斷點等功能。

技術痛點總結

• 線上的整合式開發環境：相容各大主流瀏覽器
• 隔離的運行環境：隔離，可定製，高效
• 調試代碼：查看日誌，可設定跟蹤斷點

潛在的可選技術

基於技術痛點，我做了一些調查研究，選擇了幾個備選的開源技術。

• 線上整合式開發環境：ICEcoder、Eclipse Orino、Codiad
• 隔離的運行環境：雲端虛擬機器、Docker
• 代碼調試：fluentd

目前，只確定了使用Docker來實現運行環境。

整合線上開發環境，我使用Git來解耦代碼運行環境和編輯環境，並代碼同步。

代碼調試，我使用獨立的fluentd服務收集日誌，通過SSH登入到虛擬機器查看fluent收集的Docker日誌。

雲端開發環境的架構概要

下面這張圖是一個簡單的架構說明。首先，使用Git來解耦代碼的編輯和運行環境。
我在雲端，使用Docker搭建了Git裸庫，裸庫中用Git hook來同步代碼。使用Docker來運行應用，通過瀏覽器來檢查結果。

因為，代碼的編輯和運行環境的分離，開發工程師可以靈活的選擇開發工具。開發工具可以是線上編輯器，也可以是本地的編輯器。
藉助於Docker的靈活性，開發工程師可以快速配置出應用運行環境，並分享給Team Dev成員。

概念驗證

• 在本地編輯代碼
• 用Git同步到雲端
• 用docker運行代碼查看結果

一小段視頻錄影，示範如何在雲端使用開發環境

視頻示範如何在雲端進行Django項目開發

詳細步驟

參考線上開發環境實踐

Q&A

Q：那麼多的開發人員，網域名稱怎麼分配？

A：目前，我是通過Nginx的反向 Proxy來分配不同的子網域名稱給不同開發人員。

Q：在這個體系中開發與測試是如何聯絡？

A：這套體系主要專註於開發的部分，測試與開發的互動並沒有在這套體系中體現出來， 不過有很多成型的DevOps體系可以作為參考。

Q：雲端開發是不是開發環境放在雲上，開發人員SSH到自己的開發環境，提交代碼後Compose是自動執行還是人為執行？

A：理想狀況下，是將一下三個部分都放倒雲端， 目前我只實現了運行環境在雲端。 Compose現在也是手動之行的， 但是可以通過指令碼做到自動化

• 功能完備的代碼編輯器
• 一個應用運行環境
• 一個調試工具箱。

Q：雲端開發會不會減少開發人員的工作量，讓其更專註於代碼上，而不是流程的應用上？

A：雲端開發會讓開發人員更少的經曆去學習瞭解中介軟體， 用更多的時間專註於業務功能的實現，從而做到讓開發更關注需求本身，而不是技術本身。
另外線上開發環境可以提高協作性。因為運行環境和代碼都在雲端，開發人員可以很快的切換其他人的開發環境和代碼。

Q：線上IDE在實際使用中的體驗，可被開發人員的接受程度如何，對各類語言的支援情況呢？

A: 目前的嘗試線上IDE受網路，和功能的制約，不能完全和本地的IDE相比較。 不過因為Git的解耦，開發人員可以選擇使用本地的IDE編輯代碼

Q：Git還是比較複雜，有沒有更簡單的工具？

A：除了Git之外還有一種sshfs的技術，可以直接映射遠端代碼到本地。 不過考慮到版本的回溯，甚至將來利用大資料來分析開發人員的開發行為。 Git會是一個比較好的選擇。 Git現在的複雜是因為相應的自動化指令碼沒有建立，在建立之後，開發人員可以忽略Git同步的部分。

Q：代碼提交到雲端後，容器中是怎麼生效的，是把代碼目錄作為掛載點還是容器中有進程即時去拉？

A：是的，現在代碼作為卷掛載到容器中的。

Q：但是如果是以掛載的方式，怎麼能重現Commit鏡像時保證代碼的同步呢？

A：我想這個問題回到了“這個體系關注的問題到底是什麼”上。 我分享的這套體系專註於項目中的開發部分，並不專註版本控制，測試和部署。
通常情況下，項目應該有另外一個Git倉庫來做版本控制，然後會有專門的build體系，來自動build指定的代碼。

Q：Commit鏡像時的鏡像裡並沒有代碼啊？打算任何環境都是以掛載的方式嗎？這樣可移值性會不會很差？

A：首先Container是通過項目路徑下的dockerfile產生的， 只是在運行環境中又掛在了一次代碼。 當開發結束後， 可以通過項目的dockerfile,整體build代碼和環境，並部署。

Q：例如採用git flow 這樣的多分支並行開發，每個分支都要有一套對應的docker container 嗎？如何來關聯分支和容器？

A：這是個好問題，首先Docker只提供代碼的運行環境，如果代碼的不同分支使用的是不同的運行環境，docker container是應該是多套的，而且，不同的dockerfile是應該跟代碼在一起的。
如果運行環境是相同的，可以使用同一套docker container。只需要把代碼切換到Container裡即可。

Q：當先就目前來說，在雲上部署確實很好，可是關於一些生產的私人性環境是不是在本地比雲端更靠譜？

A：我理解這個問題應該是問將雲端開發環境部署到公用雲端，還是私人雲端。 我個人的理解是， 目前來看，應該部署在企業內部的私人雲端上，來避免代碼的泄露。

Q：當前來說搭建一個統一的環境使用Kubernetes or SHIPYARD 搭建起來會更方便，而且現在物理裝置的價格也更便宜，可控程度更高，在雲端真的比在內部控制好嗎？

A：同第一個問題一樣，雲端指的可以是私人雲端，也可以是公用雲端。 我贊同提問者的考量，私人雲端會更好一些。

Q：是不是先提交代碼，觸發hook，在容器裡同步代碼並編譯和執行。這樣效率會更高嗎？

A：將代碼編輯環境和運行環境解藕， 使用Git來同步，效率受兩個因素制約：

• I/O也就是網路速度和盤速度。 保證網路速度的前提下，這個因素是可以忽略的
• Git本身的效率，因為每一次儲存都會提交Git，Git本身是增量儲存，所以效率也不會太低。

Q：對私人倉庫是否也能同樣生效？對於容器不能被外部存取的話，hook機制還能同步代碼嗎？

A: 目前這套體系建議整體部署在私人雲端中。

Q：每位開發人員都具有相同的開發環境，該開發環境是用Container麼，網路是如何解決的？也就是說在開發人員眼裡使用的就是虛擬機器，具有故定的IP。

A：應該說每位開發人員都有相同的代碼運行環境，這部分是通過Container實現的。目前明沒有對網路有太多的考量， 在規劃中會有一個網路分配的組件，為開發人員分配不同的子網域名稱，並自動將網域名稱路由到container上，這樣可以更靈活的分配主機資源，管理Container。

Q：代碼放在雲端怎麼保證安全，防止企業代碼泄漏？

A：部署在私人雲端上， 需要公網訪問時，使用VPN。

Q：我公司主要需要是C++研發電信行業，不通的省份，不同的機型都要搭理一套開發測試環境，你們講的主要是Web開發，C++是否適合雲端開發？

A：我主要研究Web方向。 只能簡單的說一下思路， C++的docker image是有的，主要是看你需要一個什麼樣的調試環境。如果可以通過Web查看結果。我覺得是可行的。

Q：關於使用Git搭建持續整合環境有一個疑問，就是如何處理在開發環境和生產環境下，個別檔案不同的情況應該如何處理？例如一些設定檔，Django中的settings.py，在生產和開發環境下，其內容是不同的。

A：通常情況下，設定檔是要獨立在代碼之外的，用Django舉例， 可以使用.env。 在開發環境，和生產環境使用不同的設定檔，而不是直接寫在代碼裡面。
如何配置產品環境和開發環境，可以參考一些好的實踐文章。 分離運行環境和代碼的實踐文章，業界比較認同的是“The 12-Factor App”這個設計思路。

Q：如果後端採用叢集方式進行管理，請問您對後端容器資源使用的預估，以及對整個叢集的負載能力的判斷，是如何考慮的？項目不同，對後端資源影響挺大。

A: 目前項目還處在概念驗證階段。 對於中型的Web項目，單個開發人員分配1CPU資源，1GB記憶體是完全可以滿足需要的。

Q：本地開發可以快速切換本地Git的不同代碼版本查看，遠程啟動並執行話，想要查看之前代碼的運行結果需要真的將代碼在遠程共用本庫中復原嗎？

A：是的，因為每個開發都自己的遠程代碼程式碼程式庫。 所以，復原並不會影響其他人，也不會丟失自己的代碼。

以上內容根據2015年12月29日晚群分享內容整理。分享人： 王延祺，IBM助理架構師，主要負責web應用設計和架構。 最近幾年，關注云技術對Web應用架構和開發方式的影響。 從2015年初開始學習並關注容器技術，並在個人業餘項目中實踐用Git和Docker搭建線上開發環境。Github: @yanqiw、Twitter: @yanqiw、frankwang.cn。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。