前言
作為創(chuàng)業(yè)公司和推行DevOps工程師們來說，都遇到過這樣的問題：
1.硬件資源利用率的問題，造成部分成本的浪費
在網(wǎng)站功能中不同的業(yè)務(wù)場景有計算型的、有IO讀寫型的、有網(wǎng)絡(luò)型、有內(nèi)存型的，集中部署應(yīng)用就會導(dǎo)致資源利用率不合理的問題。比如，一個機器上部署的服務(wù)都是內(nèi)存密集型，那么CPU資源就都很容易浪費了。
2.單物理機多應(yīng)用無法對無法進行有效的隔離，導(dǎo)致應(yīng)用對資源的搶占和相互影響
一個物理機器跑多個應(yīng)用，無法進行所使用的CPU、內(nèi)存、進程進行限制，如果一個應(yīng)用出現(xiàn)對資源的搶占問題，就會引起連鎖反應(yīng)，最終導(dǎo)致網(wǎng)站部分功能不可用。
3.環(huán)境、版本管理復(fù)雜，上線部署流程缺乏，增加問題排查的復(fù)雜度
由于內(nèi)部開發(fā)流程的不規(guī)范，代碼在測試或者上線過程中，對一些配置項和系統(tǒng)參數(shù)進行隨意的調(diào)整，在發(fā)布時進行增量發(fā)布，一旦出現(xiàn)問題，就會導(dǎo)致測試的代碼和線上運行的代碼是不一致的，增加了服務(wù)上線的風(fēng)險，也增加了線上服務(wù)故障排查的難度。
4.環(huán)境不穩(wěn)定，遷移成本高，增加上線風(fēng)險
在開發(fā)過程中存在多個項目并行開發(fā)和服務(wù)的依賴問題，由于環(huán)境和版本的復(fù)雜性很高，不能快速搭建和遷移一個環(huán)境，導(dǎo)致無法在測試環(huán)境中無法模擬出線上的流程進行測試，很多同學(xué)在線上環(huán)境進行測試，這里有很高的潛在風(fēng)險，同時導(dǎo)致開發(fā)效率降低。
5.傳統(tǒng)虛擬機和物理機占用空間大，啟動慢，管理復(fù)雜等問題
傳統(tǒng)虛擬機和物理機在啟動過程進行加載內(nèi)核，執(zhí)行內(nèi)核和init進行，導(dǎo)致在啟動過程占用很長時間，而且在管理過程中會遇到各種各樣的管理問題。
基于Docker容器技術(shù)，運維技術(shù)團隊開發(fā)了五阿哥網(wǎng)站的容器云平臺。通過容器云平臺95%的應(yīng)用服務(wù)已經(jīng)實現(xiàn)容器化部署。這些應(yīng)用支持業(yè)務(wù)按需拓展，秒級伸縮，提供與用戶友好的交互過程，規(guī)范了測試和生產(chǎn)的發(fā)布流程，讓開發(fā)和測試同學(xué)從基礎(chǔ)的環(huán)境配置和發(fā)布解放出來，使其更聚焦自己的項目開發(fā)和測試。
圖1 五阿哥容器云整體架構(gòu)
結(jié)合五阿哥容器云平臺和Docker容器技術(shù)的實踐，本文先介紹如何實現(xiàn)7*24小時“一站式”的持續(xù)交付，實現(xiàn)產(chǎn)品的上線。關(guān)于容器云平臺的介紹，請關(guān)注：https：//zhuanlan.zhihu.com/idevops
Docker鏡像標準化
眾所周知，Docker的鏡像是分層的。對鏡像分層進行約定：
- 第一層是操作系統(tǒng)層，由CentOS/Alpine等基礎(chǔ)鏡像構(gòu)成，安裝一些通用的基礎(chǔ)組件；
- 第二層是中間件層，根據(jù)不同的應(yīng)用程序，安裝它們運行時需要使用到的各種中間件和依賴軟件包，如，nginx、tomcat等；
- 第三層是應(yīng)用層，這層僅包含已經(jīng)打好包的各應(yīng)用程序代碼。
圖2：Docker鏡像分層約定
經(jīng)驗總結(jié)：如何讓自己的鏡像變的更小，PUSH的更快？
圖3 優(yōu)化前后對比
- dockerfile構(gòu)建應(yīng)用鏡像，在中間件層遇到一些需要安裝的軟件包時，盡可能的使用包管理工具（如yum）或以git clone方式下載源碼包進行安裝，目的是將軟件包的copy和安裝控制在同一層，軟件部署成功后清除一些無用的rpm包或源碼包，讓基礎(chǔ)鏡像的尺寸更小。
- Java應(yīng)用鏡像中并沒有將jdk軟件包打入鏡像，將jdk部署在每臺宿主上，在運行鏡像時，通過掛載目錄的方式將宿主機上的java家目錄掛載至容器指定目錄下。因為它會把基礎(chǔ)鏡像撐得非常大；
- 在構(gòu)建應(yīng)用鏡像時，docker會對這兩層進行緩存并直接使用，僅會重新創(chuàng)建代碼出現(xiàn)變動的應(yīng)用層，這樣就提高了應(yīng)用鏡像的構(gòu)建速度和構(gòu)建成功后向鏡像倉庫推送的速度，從整體流程上提升了應(yīng)用的部署效率。
容器的編排管理
編排工具的選型：
圖4：編排工具選型對比
Rancher圖形化管理界面，部署簡單、方便， 可以與AD、LDAP、GITHUB集成，基于用戶或用戶組進行訪問控制，快速將系統(tǒng)的編排工具升級至Kubernetes或者Swarm，同時有專業(yè)的技術(shù)團隊進行支持，降低容器技術(shù)入門的難度。
圖5： Rancher架構(gòu)圖
基于以上優(yōu)點我們選擇Rancher作為我們?nèi)萜髟破脚_的編排工具，在對應(yīng)用的容器實例進行統(tǒng)一的編排調(diào)度時，配合Docker-Compose組件，可以在同一時間對多臺宿主機執(zhí)行調(diào)度操作。同時，在服務(wù)訪問出現(xiàn)峰值和低谷時，利用特有的rancher-compose.yml文件調(diào)用“SCALE”特性，對應(yīng)用集群執(zhí)行動態(tài)擴容和縮容，讓應(yīng)用按需求處理不同的請求。https：/zhuanlan.zhihu.com/p/29093407
容器網(wǎng)絡(luò)模型選型：
圖6： 容器網(wǎng)絡(luò)模型選型
由于后端開發(fā)基于阿里的HSF框架，生產(chǎn)者和消費者之間需要網(wǎng)絡(luò)可達，對網(wǎng)絡(luò)要求比較高，需要以真實IP地址進行注冊和拉取服務(wù)。所以在選擇容器網(wǎng)絡(luò)時，我們使用了Host模式，在容器啟動過程中會執(zhí)行腳本檢查宿主機并分配給容器一個獨立的端口，來避免沖突的問題。
持續(xù)集成與持續(xù)部署
- 持續(xù)集成， 監(jiān)測代碼提交狀態(tài)，對代碼進行持續(xù)集成，在集成過程中執(zhí)行單元測試，代碼Sonar和安全工具進行靜態(tài)掃描，將結(jié)果通知給開發(fā)同學(xué)同時部署集成環(huán)境，部署成功后觸發(fā)自動化測試（自動化測試部分后續(xù)會更新https：//zhuanlan.zhihu.com/idevops）。
圖7：持續(xù)集成示意圖
靜態(tài)掃描結(jié)果：
圖8： 持續(xù)集成結(jié)果示意圖
- 持續(xù)部署，是一種能力，這種能力非常重要，把一個包快速部署在你想要的地方。平臺采用分布式構(gòu)建、部署，master管理多個slave節(jié)點，每個slave節(jié)點分屬不同的環(huán)境。在master上安裝并更新插件、創(chuàng)建job、管理各開發(fā)團隊權(quán)限。slave用于執(zhí)行job。
圖9： 持續(xù)部署架構(gòu)圖
基于上述圖9架構(gòu)，我們定義了持續(xù)部署規(guī)范的流程：
（1）開發(fā)同學(xué)向gitlab提交代碼；
（2）拉取項目代碼和配置項文件，執(zhí)行編譯任務(wù)；
（3）拉取基礎(chǔ)鏡像，將編譯好的應(yīng)用包打入生成最新的應(yīng)用鏡像，推送到鏡像倉庫；
（4）根據(jù)當前應(yīng)用及所屬環(huán)境定制化生成docker-compose.yml文件，基于這個文件執(zhí)行rancher-compose命令，將應(yīng)用鏡像部署到預(yù)發(fā)環(huán)境（發(fā)布生產(chǎn)前的測試環(huán)境，相關(guān)配置、服務(wù)依賴關(guān)系和生產(chǎn)環(huán)境一致）。
（6）預(yù)發(fā)環(huán)境測試通過后將應(yīng)用鏡像部署至線上環(huán)境，測試結(jié)果通知后端測試同學(xué)。
容器的運行管理
應(yīng)用容器現(xiàn)在已經(jīng)部署到線上環(huán)境，那么在整個容器的生命周期中，還需要解決下面兩個問題：
（1） 如何保存應(yīng)用程序產(chǎn)生的運行日志和其它業(yè)務(wù)日志；
（2） 如何在后端服務(wù)出現(xiàn)變化后nginx能夠自動發(fā)現(xiàn)并完成配置更新。
日志管理
容器在運行時會在只讀層之上創(chuàng)建讀寫層，所有對應(yīng)用程序的寫操作都在這層進行。當容器重啟后，讀寫層中的數(shù)據(jù)（包含日志）也會一并被清除。雖然可以通過將容器中日志目錄掛載到宿主機解決此類問題，但當容器在多個宿主機間頻繁漂移時，每個宿主機上都會有留存應(yīng)用名的部分日志，增加了開發(fā)同學(xué)查看、排查問題的難度。
綜上所屬，日志服務(wù)平臺作為五阿哥網(wǎng)站日志倉庫，將應(yīng)用運行過程中產(chǎn)生的日志統(tǒng)一存儲，并且支持多種方式的查詢操作。
圖10：日志服務(wù)平臺
通過在日志服務(wù)的管理界面配置日志采集路徑，在容器中部署agent把應(yīng)用日志統(tǒng)一投遞到logstore中，再在logstore中配置全文索引和分詞符，以便開發(fā)同學(xué)能夠通過關(guān)鍵字搜索、查詢想要的日志內(nèi)容。
經(jīng)驗總結(jié)：如何避免日志的重復(fù)采集問題？
- 日志服務(wù)agent需要在配置文件“ilogtail_config.json”中增加配置參數(shù)“check_point_filename”，指定checkpoint文件生成的絕對路徑，并且將此路徑掛載至宿主機目錄下，確保容器在重啟時不會丟失checkpoint文件，不會出現(xiàn)重復(fù)采集問題。
服務(wù)的注冊
etcd是一個具備高可用性和強一致性的鍵值存儲倉庫，它使用類似于文件系統(tǒng)的樹形結(jié)構(gòu)，數(shù)據(jù)全部以“/”開頭。etcd的數(shù)據(jù)分為兩種類型：key和directories，其中key下存儲單獨的字符串值，directories下則存放key的集合或者其他子目錄。
圖11 應(yīng)用注冊
在五阿哥環(huán)境中，每個向etcd注冊的應(yīng)用服務(wù)，它們的根目錄都以
”/${APP_NAME}_${ENVIRONMENT}”
命名。根目錄下存儲每個應(yīng)用實例的Key信息，它們都以“IP−{PORT}”的方式命名。
下圖是使用上述約定，存儲在etcd上某應(yīng)用實例的數(shù)據(jù)結(jié)構(gòu)：
圖12： 存儲在etcd上某應(yīng)用實例的數(shù)據(jù)結(jié)構(gòu)
可以看到我是使用get方法向etcd發(fā)送請求的，請求的是部署在預(yù)發(fā)環(huán)境（PRE）的搜索服務(wù)（search）；在它的根目錄“/search_PRE”下，僅存儲了一個應(yīng)用實例的信息，這個實例的key是“172.18.100.31-86”；對應(yīng)的value是“172.18.100.31：86‘’，整個注冊過程是這樣的：
① 通過代碼為容器應(yīng)用程序生成隨機端口，和宿主機正在使用的端口進行比對，確保端口沒有沖突后寫入程序配置文件；
② 把通過python和etcd模塊編寫的服務(wù)注冊工具集成在腳本中，將IP地址和上一步獲取的隨機端口以參數(shù)的方式傳遞給服務(wù)注冊工具；
③ 待應(yīng)用程序完全啟動后，由服務(wù)注冊工具以約定好的數(shù)據(jù)結(jié)構(gòu)將應(yīng)用實例的寫入etcd集群，完成服務(wù)注冊工作；
④ 容器定時向etcd發(fā)送心跳，報告存活并刷新ttl時間；
⑤ 容器腳本捕獲rancher發(fā)送至應(yīng)用實例的singnal terminal信號，在接收到信號后向etcd發(fā)送delete請求刪除實例的數(shù)據(jù)。
注：在ttl基礎(chǔ)上增加主動清除功能，在服務(wù)正常釋放時，可以立刻清除etcd上注冊信息，不必等待ttl時間。
經(jīng)驗總結(jié)：容器在重啟或者意外銷毀時，讓我們一起看一下這個過程中容器和注冊中心都做了什么事情？
應(yīng)用在注冊是攜帶key 和value時攜帶了ttl超時屬性，就是考慮到當服務(wù)集群中的實例宕機后，它在etcd中注冊的信息也隨之失效，若不予清除，失效的信息將會成為垃圾數(shù)據(jù)被一直保存，而且配置管理工具還會把它當做正常數(shù)據(jù)讀取出來，寫入web server的配置文件中。要保證存儲在etcd中的數(shù)據(jù)始終有效，就需要讓etcd主動釋放無效的實例信息，來看一下注冊中心刷新的機制，代碼直接奉上：
服務(wù)的發(fā)現(xiàn)
confd是一個輕量級的配置管理工具，支持etcd作為后端數(shù)據(jù)源，通過讀取數(shù)據(jù)源數(shù)據(jù)，保證本地配置文件為最新；不僅如此 ，它還可以在配置文件更新后，檢查配置文件語法有效性，以重新加載應(yīng)用程序使配置生效。這里需要說明的是，confd雖然支持rancher作為數(shù)據(jù)源，但考慮易用性和擴展性等原因，最終我們還是選擇了etcd。
和大多數(shù)部署方式一樣，我們把confd部署在web server所在的ECS上，便于confd在監(jiān)測到數(shù)據(jù)變化后及時更新配置文件和重啟程序。confd的相關(guān)配置文件和模板文件部署在默認路徑/etc/confd下，目錄結(jié)構(gòu)如下：
confd.toml是confd的主配置文件，使用TOML格式編寫，因為我們etcd是集群部署，有多個節(jié)點，而我又不想把confd的指令搞的又臭又長，所以將interval、nodes等選項寫到了這個配置文件里。
cond.d目錄存放web server的模板配置源文件，也使用TOML格式編寫。該文件用于指定應(yīng)用模板配置文件路徑（src）、應(yīng)用配置文件路徑（dest）、數(shù)據(jù)源的key信息（keys）等。
templates目錄存放web server下每個應(yīng)用的模板配置文件。它使用Go支持的text/template語言格式進行編寫。在confd從etcd中讀取到最新應(yīng)用注冊信息后，通過下面的語句寫入模板配置文件中：
圖13： 應(yīng)用發(fā)現(xiàn)示意圖
通過supervisor管理confd進程。confd在運行后會每隔5秒對etcd進行輪詢，當某個應(yīng)用服務(wù)的K/V更新后，confd會讀取該應(yīng)用存儲在etcd中的數(shù)據(jù)，寫入到模板配置文件中，生成這個應(yīng)用配置文件，最后由confd將配置文件寫入到目標路徑下，重新加載nginx程序使配置生效。（代碼請參考：https：//zhuanlan.zhihu.com/idevops）
總結(jié)
本文是五阿哥運維技術(shù)團隊針對Docker容器技術(shù)在如何在持續(xù)交付過程中探索和實踐，目前已經(jīng)將發(fā)布部署權(quán)限開放給應(yīng)用開發(fā)的owner，實現(xiàn)7*24小時“一站式”的持續(xù)交付，整體提高了公司的研發(fā)過程的交付能力。
接下來會不斷優(yōu)化持續(xù)交付過程中遇到的各種場景，逐漸完善容器云平臺，同時會將容器云平臺各種功能，總結(jié)的經(jīng)驗和教訓(xùn)不斷分享給大家，給大家在工作中一些參考，避免走重復(fù)的“彎路”。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題：基于Docker持續(xù)交付平臺建設(shè)的實踐
本文網(wǎng)址：http://www.ezxoed.cn/html/support/11121824047.html
相關(guān)文章
