京東零售云mPaaS平臺之Android組件化系統私有化部署改造實踐
一、背景
在當前，上云無疑是一個非常火熱的話題，不管是科技企業還是傳統企業都在說著這一話題，幫助企業降本增效、協同辦公等等，咱作為一個技術人關注的話題還是技術相關的，本篇文章是在京東打造的京東零售云的大背景下，將京東零售云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的編排文件編寫
只要把握好了這些關鍵點，相信其它平臺如有相同的需求，在進行私有化改造部署落地的過程中也會是很順利的。
