一、背景
在当前，上云无疑是一个非常火热的话题，不管是科技企业还是传统企业都在说着这一话题，帮助企业降本增效、协同办公等等，咱作为一个技术人关注的话题还是技术相关的，本篇文章就是在京东打造的零售云的大背景下，将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编写和部署，降低了大家接入的门槛，加快了接入的步伐。此方案主要解决了以下问题:
n
免写Dockerfile
n
参数配置化
n
编译镜像自动化
Ø
使用现有轮子？发明轮子？
我们尝试过这套方案之后，发现这套方案对于Java写的后端平台部署简直太棒了，按照规范把自己的War包放到云存储上，然后修改配置文件，再按照流程在平台上进行一键打包，哦哦，镜像出来啦～
当然对于前端部署一样的友好。
对于Aura平台，这套轮子不好用了，仔细研究后，发现了问题所在，这套方案之所以好用，是因为内置了一些常用的软件，比如Nginx，Tomcat等，足以满足上述所说的环境部署。
但是Aura平台的系统架构较复杂，使用这套方案的话，就不只是使用轮子了，还需要再在这个轮子上加装很多东西才能达到使用的目的，尝试过后发现得不尝失，而且这个轮子的学习成本太高，不是使用学习成本，而是学习它的改装成本太高。
怎么办？发明一个轮子？为了这一个平台中的一部分，发明一个轮子显然不是明智之举，干脆让我们一部分老弱妇孺坐上这台马车，另一部分腿脚健全、身强力壮的小伙子直接走路吧，不见得就比马车慢。
最后，小伙子先走着，可以边走边完善轮子，或者能走出来一个更加便捷的轮子，再然后就不只是一技多能，而是一技多再加一能了，哈哈～
三、开始干活
1. 镜像划分
Aura平台的系统架构是这样的
Aura平台按照架构分为三个镜像，分别是
Ø
Aura2Web：包含前端，后端
Ø
Aura2JenkinsMaster：任务调度器
Ø
Aura2JenkinsSlave：CI构建节点
经过分析，由于Aura2Web、Aura2JenkinsSlave使用到的软件较多，环境配置复杂，决定这两个镜像使用DockerFile进行编写。
2. DockerFile编写
自己写的Dockerfile有两个，在写之前先研究一下Dockerfile的编写规则吧，否则事倍功半。
从网上找来了几条编写DockerFile需要注意的点，遵循这些经验才能编写出优秀的镜像
Ø
选择最精简的基础镜像
Ø
减少镜像的层数
Ø
清理镜像构建的中间产物
Ø
注意优化网络请求
Ø
尽量去用构建缓存
选择基础镜像
基于我们的环境，选择了服务器最稳定的Centos，版本号是7.2.1511，并修改源为京东内网源，加快下载依赖的速度。
安装基础软件
安装以下一些软件：JDK，nginx，Python，Maven，Git，Tomcat，JQ等
业务源码到二进制包再到镜像
镜像是为了跑我们自己服务的，所以需要把我们的平台包放到镜像中，这个需要制定一个规则，方便记录从源码到镜像这一过程，并且可回溯。
Ø
前端：
n
前端使用的是Vue，需要进行编译构建，将构建后的产物放到镜像中
n
首先在源码中打Tag，Push到服务器，由WebHook钩子触发持续集成，编译出前端
n
将前端的产物打成zip包，放到京东的云存储上，记下链接地址备用。
Ø
后端：
n
后端需要进行混淆加密，加密后的产物同理打成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选择允许上传)
n
libs-releases-local
n
libs-snapshots-local
开通匿名访问权限，如已开通则忽略，建用户并记录其账号和密码，后续放入 configMap。
云存储(minio)
Ø
参考中间件信息的网址，找到地址和用户名密码
Ø
登录并创建需要的bucket，并配置访问策略为读/写
5. 双域名改造
由于私有化客户的环境分为内外环境，所以平台访问的域名分为内外域名，服务间调用使用内部域名，用户能直接访问的使用外部域名。 双域名改造的关键点就是将服务分类，哪些是只用内部服务调用的，哪些还需要用户直接调用，分析清楚后，直接在configMap中添加对应的Key值，并改造Confd的配置，适配相关域名。例如在Confd章节中举例的的 前端域名配置。
6. K8S编排文件
镜像文件生成之后，接下来就该编写K8S的编排文件了，然后就可以将镜像部署到K8S平台上了。
需要配置的有以下编排文件
n
configMap
n
ingress
n
service
n
deployment
n
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文件，文件有两个：
n
aura-Cfs-mini-without-gradlecache.tar.xz
n
aura-Cfs-mini-with-gradlecache.tar.xz
它们两个的区别差了一个 14G 左右的 gradle cache。 cache可使用也可不使用，如不使用则会自动从网络下载，只是会延长第一次构建的时间。
步骤如下：
n
将文件 xz 解压到 PVC的根目录即可
n
选择使用 gradle 缓存：
n
可以使用预置的 gradle 缓存来加快首次的构建速度，也可不使用预置缓存，而是在构建过程中自动从网络下载依赖的包。如要使用Grade缓存，按照以下步骤操作即可。
n
保证JenkinsSlave镜像中有充足的存储空间（大于200G）
n
使用 with-gradlecache 的压缩包
n
在PVC盘的根目录下新建一个空文件
use_gradle_cache
n
解压完毕后，镜像启动脚本会输出：“Gradle User Home 缓存恢复完成”
四、经验总结
本篇文章主要记述了，Aura平台（Android组件平台）拆分成Docker镜像，并进行镜像编译和部署的过程。
私有化部署的事情总结下来主要有以下几点
Ø
Dockerfile编写及镜像编译
Ø
配置的统一管理
Ø
K8S的编排文件编写
只要把握好了这些关键点，相信其它平台如有相同的需求，在进行私有化改造部署落地的过程中也会是很顺利的。
1446600浏览
