一、背景

在當前，上云無疑是一個非常火熱的話題，不管是科技企業還是傳統企業都在說著這一話題，幫助企業降本增效、協同辦公等等，咱作為一個技術人關注的話題還是技術相關的，本篇文章是在京東打造的京東零售云的大背景下，將京東零售云mPaaS平臺中的Android組件化系統進行私有化部署改造的歷程記錄下來，并分享給大家。

京東零售云mPaaS平臺是京東打造的企業級移動研發運營平臺，Aura是Android方向的組件化、插件化解決方案。

T-PaaS平臺是京東進行私有化部署的底座，旨在幫助各種PaaS應用更容易的在各種客戶環境中進行商業化輸出。其接入規范完全遵循云原生標準，保證PaaS服務能容易與生態應用、客戶業務協同配合，以云原生的容器及operator的方式實現應用邏輯，并以Helm標準的方式打包，在Kubernetes之上統一部署和管理。

這里分享的是京東在進行上云的環境背景下，Aura平臺(Android組件平臺)開始了上云、上T-PaaS環境的改造歷程。

二、需求分析及方案選定

1. 需求分析

需求和目的很明確，就是將現在內部的平臺系統Aura在TPaaS平臺上進行部署

TPaaS平臺是以Kubernetes進行容器的編排部署和管理Docker容器的，所以，我們需要做以下兩件事

• 編譯出Docker鏡像
• 撰寫k8s編排文件，并在TPaaS平臺上進行部署和管理

2. 方案選擇

現有輪子

我們是移動開發的團隊，團隊的成員大多都是客戶端開發的，但是小伙伴們一技多能，還能維護平臺的開發，并在京東內網進行部署。

現在為了部署TPaaS，基礎技術組的同事進行了前期的技術探索，開發了一套不用寫Dockerfile即可接入TPaaS平臺的方案，使客戶端團隊不至于重新學習一套全新的技能Dockerfile編寫和部署，大大降低了接入的門檻，加快了接入的步伐。此方案主要解決了以下問題:

• 免寫Dockerfile
• 參數配置化
• 編譯鏡像自動化

使用現有輪子?發明輪子?

我們嘗試過這套方案之后，發現這套方案對于Java寫的后端平臺部署簡直太棒了，按照規范把自己的War包放到云存儲上，然后修改配置文件，再按照流程在平臺上進行一鍵打包，哦哦，鏡像出來啦～

當然對于前端部署一樣的友好。

對于Aura平臺，這套輪子不好用了，仔細研究后，發現了問題所在，這套方案之所以好用，是因為內置了一些常用的軟件，比如Nginx，Tomcat等，足以滿足上述所說的環境部署。

但是Aura平臺的系統架構較復雜，使用這套方案的話，就不只是使用輪子了，還需要再在這個輪子上加裝很多東西才能達到使用的目的，嘗試過后發現得不嘗失，而且這個輪子的學習成本太高，不是使用學習成本，而是學習它的改裝成本太高。

怎么辦?發明一個輪子?僅為了單一平臺中的一部分，顯然不是明智之舉，干脆讓部分老弱婦孺的組件坐上這臺馬車，另一部分腿腳健全、身強力壯的小伙子直接走路吧，不見得就比馬車慢。

最后，小伙子先走著，可以邊走邊完善輪子，或者能走出來一個更加便捷的輪子，再然后就不只是一技多能，而是一技多再加一能了，哈哈～

三、開始干活

1. 鏡像劃分

Aura平臺的系統架構是這樣的

 

Aura平臺按照架構分為三個鏡像，分別是

• Aura2Web：包含前端，后端
• Aura2JenkinsMaster：任務調度器
• Aura2JenkinsSlave：CI構建節點

經過分析，由于Aura2Web、Aura2JenkinsSlave使用到的軟件較多，環境配置復雜，決定這兩個鏡像使用DockerFile進行編寫。

2. DockerFile編寫

自己寫的Dockerfile有兩個，在寫之前先研究一下Dockerfile的編寫規則，遵循這些經驗才能編寫出優秀的鏡像

• 選擇最精簡的基礎鏡像
• 減少鏡像的層數
• 清理鏡像構建的中間產物
• 注意優化網絡請求
• 盡量去用構建緩存

選擇基礎鏡像

基于我們的環境，選擇了服務器最穩定的Centos，版本號是7.2.1511，并修改源為京東內網源，加快下載依賴的速度。

安裝基礎軟件

安裝以下一些軟件：JDK，nginx，Python，Maven，Git，Tomcat，JQ等。

業務源碼到二進制包再到鏡像

鏡像是為了跑我們的自己服務，所以需要把我們的平臺包放到鏡像中，這需要制定一個規則，方便記錄從源碼到鏡像這一過程，并且可回溯。

前端：

• 前端使用的是Vue，需要進行編譯構建，將構建后的產物放到鏡像中。
• 首先在源碼中打Tag，Push到服務器，由WebHook鉤子觸發持續集成，編譯出前端。
• 將前端的產物打成zip包，放到京東的云存儲上，記下鏈接地址備用。

后端：

• 后端需要進行混淆加密，加密后的產物同理打成zip包，然后將其放到京東的云存儲上，記下鏈接地址備用。

3. 統一配置化改造

由于鏡像中的代碼使用到的配置文件較多，只Aura2Web鏡像就達到了6個之多，所以需要一種方法進行統一的配置化。

經過研究發現了一個超好用的配置管理的軟件confd，下面介紹一下這個軟件的用法。

confd簡介

Confd是一個輕量級的配置管理工具。通過查詢Etcd或其它后端，結合配置模板引擎，可以保持本地配置最新，同時具備定期探測機制，配置變更自動reload。其后端支持的數據類型有：etcd、consul、vault、environment variables、redis、zookeeper、dynamodb、stackengine、rancher。不過一般使用Confd和etcd的配合使用比較多。

在我們的項目中暫時還用不著后端配合，只需要使用它的模板渲染，進行統一配置管理即可。

confdg下載

下載confd的二進制文件，下載地址為：https://github.com/kelseyhightower/confd/releases。

在這里需要將confd放到鏡像中，直接在dockerfile中加上如下語句

 

RUN set -ex \  
&& wget http://$storage_domain/our-tools/confd \  
&& mv ./confd /usr/bin \  
&& chmod a+x /usr/bin/confd 

創建confd配置文件和模板文件

如圖所示，根據您的需要，可創建多個配置和模板，但它們要一一對應起來。

舉例：frontend_domain.toml

 

[template]  
src = "frontend_domain.template"  
dest = "/opt/servers/nginx/conf/domains/frontend_domain"  
keys = [  
"/aura/frontend/domain_inner",  
"/aura/frontend/domain_outer",  
]  
Frontend_domain.template  
server  
{  
listen 80;  
server_name {{ getv "/aura/frontend/domain_inner" }} {{ getv "/aura/frontend/domain_outer" }};  
...  
} 

在dockerfile中將配置文件和template文件copy到鏡像中。

COPY render /etc/confd 

在entery的shell腳本中執行生成真實的配置文件。

/usr/bin/confd -onetime -backend file -file ${config_file_path} 

4. 涉及到的中間件配置

數據庫

參考TPaaS的文檔，將需要配置的Host等在本機配好，登錄phpmyadmin.tpaas.local(用戶名密碼從文檔中獲得)。

建立新數據庫，并自定義數據庫名稱，假設這里取名為：auradb。

下載之前建好的Aura的初始化sq，導入sql。

記錄以下信息，后續放入 configMap

• 網址和端口號
• 數據庫名
• 用戶名密碼

GitLab

參考中間件信息的網址，找到GitLab網址，登錄網站，使用中間件信息上提供的用戶名密碼或新建一個賬號，這里示例新建一個賬號：aura，密碼為： xxxxx，記錄下來，后續放入configMap。

Maven私服 (Nexus Repository OSS)

參考中間件信息的網址，找到地址和用戶名密碼，登錄。

建以下兩個倉庫，(創建時參數deployment policy選擇允許上傳)

• libs-releases-local
• libs-snapshots-local

開通匿名訪問權限，如已開通則忽略，建用戶并記錄其賬號和密碼，后續放入 configMap。

云存儲(minio)

• 參考中間件信息的網址，找到地址和用戶名密碼。
• 登錄并創建需要的bucket，并配置訪問策略為讀/寫。

5. 雙域名改造

由于私有化客戶的環境分為內外環境，所以平臺訪問的域名分為內外域名，服務間調用使用內部域名，用戶能直接訪問的使用外部域名。 雙域名改造的關鍵點就是將服務分類，哪些是只用內部服務調用的，哪些還需要用戶直接調用，分析清楚后，直接在configMap中添加對應的Key值，并改造Confd的配置，適配相關域名。例如在Confd章節中舉例的的 前端域名配置。

6. K8S編排文件

鏡像文件生成之后，接下來就該編寫K8S的編排文件了，然后就可以將鏡像部署到K8S平臺上。

需要配置的有以下編排文件

• configMap
• ingress
• service
• deployment
• PersistentVolumeClaim

configMap

它的主要作用就是將需要配的參數統一放到這里，然后傳給鏡像中的confd進行渲染配置

PersistentVolumeClaim

主要用于外部掛載文件或目錄，這里用它掛載了AndroidSDK，這樣多個構建節點可以共用SDK，節省了空間。

JenkinsSlave鏡像將會使用掛載的PVC做為Android SDK的輸入

多個 JenkinsSlave節點會共用同一份PVC中的Android SDK，以節省存儲空間。

PVC掛載目錄為 /usr/local/aura/auraCfs，也可將其掛載到其它目錄(例如/mnt/auraCfs)，然后將 /usr/local/aura/auraCfs 作為軟鏈指向它。

解壓SDK文件，文件有兩個：

 

aura-Cfs-mini-without-gradlecache.tar.xz  
aura-Cfs-mini-with-gradlecache.tar.xz 

它們兩個的區別差了一個 14G 左右的 gradle cache。 cache可使用也可不使用，如不使用則會自動從網絡下載，并只會延長第一次構建的時間。

步驟如下：

• 將文件 xz 解壓到 PVC的根目錄即可。
• 選擇使用 gradle 緩存。
• 可以使用預置的 gradle 緩存來加快首次的構建速度，也可不使用預置緩存，而是在構建過程中自動從網絡下載依賴的包。如要使用Grade緩存，按照以下步驟操作即可(變成冒號，底下的步驟能不能縮一下格式，做一個步驟區分，縮進一下，接下來的步驟，步驟是什么?)
• 保證JenkinsSlave鏡像中有充足的存儲空間(大于200G)
• 使用 with-gradlecache 的壓縮包
• 在PVC盤的根目錄下新建一個空文件 use_gradle_cache
• 解壓完畢后，鏡像啟動腳本會輸出：“Gradle User Home 緩存恢復完成”

四、經驗總結

本篇文章主要記述了，Aura平臺(Android組件平臺)拆分成Docker鏡像，并進行鏡像編譯和部署的過程。

私有化部署的事情總結下來主要有以下幾點

• Dockerfile編寫及鏡像編譯
• 配置的統一管理
• K8S的編排文件編寫

只要把握好了這些關鍵點，相信其它平臺如有相同的需求，在進行私有化改造部署落地的過程中也會是很順利的。