Docker大型項目容器化改造的方法

本篇內容介紹了“Docker大型項目容器化改造的方法”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

一個幾十萬行c++代碼、大幾十個應用程序的大型項目進行容器化。如何對原來的代碼改造最小，甚至代碼都不需要修改。如何靜悄悄的，甚至不讓業務程序員發覺。如何將業務鏡像的體積做到最小。如何快速地制作一個業務鏡像。這些一直是困擾我們多時的問題。容器分類的時候，如果需要對代碼組織方式和架構進行調整，對于幾十萬行的項目將會是一個災難。容化改造完后，如果開發模式變化太劇烈，無可避免會面臨幾十個、上百個業務程序員重新學習適應的過程，成本驚人。業務鏡像的大小直接影響對現場更新容器方便與否的問題，特別是當項目在海外，網絡速度不是很快的情況下。自動化、快速的鏡像制作是能否進行敏捷開發的關鍵。

一、如何開始

如何將一個運行于linux的項目挪到容器里面去運行通常是遇到的第一個問題。網上找一個帶gcc編譯器和linux操作系統的基礎鏡像，基于這個鏡像可以先制作一個編譯和ci檢查（代碼檢查、運行單元測試等等）的構建鏡像。利用構建鏡像進行編譯和ci檢查，然后基于基礎鏡像制作運行鏡像，將編譯好的庫和可執行程序拷貝進去（通過dockerfile）。這樣一個最簡單鏡像就制作好了。

上面方法做出來的業務鏡像可以運行，但有兩個問題，制作的時間特別長（我們項目需要一個小時）、鏡像的業務層特別大（我們項目有1個g）。兩個問題不是特別嚴重，但如果項目拿去商用就是一個很麻煩的問題。

二、容器分層

容器分層的概念是docker的核心概念，就是支持每個容器可以“繼承”自另外一個容器。這里的繼承跟面向對象里的繼承應該是同一個概念。這樣除了可以帶來“繼承”特性的好處，底層鏡像變動時，不需要去更新上層的鏡像，這樣就可以少更新很多東西。的確很妙，面向對象的繼承我都沒覺得有這么好用！受這個特性影響，我們將項目用到的第三方庫單獨提出來做成一層。制作的流程也相應地變成下圖所示。

雖然過程多了一步，但效果也是立竿見影的，業務層的制作時間從原來1個小時縮短為12分鐘，大小也變為100m左右。

三、業務容器分類

在docker最佳實踐的建議里面，建議一個容器最好只跑一種程序，或者一類程序。像原來那樣，一個容器跑幾十個進程一定是不合適的。分類清晰的容器也便于管理和進行各種操作。同時，在微服務的最佳實踐里面，建議將項目的代碼分割成一個個的微服務。每個微服務的代碼由不同的團隊維護，各自獨立。我們先暫時不討論這種方式的優缺點。原先的項目是一個幾十萬行、幾十個程序的大項目，有幾十個人開發人員，有無數的公共模塊，每個模塊間相互引用也很普遍，每個程序由數量不等的模塊來組成。如果按上面的建議來進行docker的業務分類，無疑會給項目帶來巨變，并且涉及組織架構的大調整，幾乎是一個不可能的任務。那么如何做既可以對容器進行分類，又保持原有的開發模式不變。有時候察覺不到改變才是推進一項新技術的最佳方式。

方法其實也很簡單，容器里面有一個叫docker-entrypoint.sh的角本，管理容器啟動后要啟動哪些進程。上面我們已經制作了一個項目統一的鏡像，在分類的時候，我們只要根據不同類型容器，修改不同的docker-entrypoint.sh來啟動不同類型的進程就可以了。要配合設置不同的環境變量，不同的配置文件等等。當然，這一切都很容易！

“Docker大型項目容器化改造的方法”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！