开发者中心 > 专栏 > 内容详情
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

京东mPaaS平台之Android组件化系统私有化部署改造实践!

  • JDEMOP
  • 2021-01-26
  • 25543浏览

一、背景

在当前,上云无疑是一个非常火热的话题,不管是科技企业还是传统企业都在说着这一话题,帮助企业降本增效、协同办公等等,咱作为一个技术人关注的话题还是技术相关的,本篇文章就是在京东打造的零售云的大背景下,将mPaaS平台中的Android组件化系统进行私有化部署改造的历程记录下来,分享给大家。

mPaaS平台是京东打造的企业级移动研发运营平台,AuraAndroid方向的组件化、插件化解决方案。

T-PaaS平台是京东进行私有化部署的底座,旨在帮助各种PaaS应用更容易的在各种客户环境中进行商业化输出。其接入规范完全遵循云原生标准,保证PaaS服务能容易与生态应用、客户业务协同配合,以云原生的容器及operator的方式实现应用逻辑,并以Helm标准的方式打包,在Kubernetes之上统一部署和管理。

在京东进行上云的环境背景下,Aura平台(Android组件平台)开始了上云、上T-PaaS环境的改造历程。

二、需求分析及方案选定

1. 需求分析

需求和目的很明确,就是将现在内部的平台系统AuraTPaaS平台上进行部署

TPaaS平台是以Kubernetes进行容器的编排部署和管理Docker容器的,所以,我们需要做以下两件事

Ø  编译出Docker镜像

Ø  撰写k8s编排文件,并在TPaaS平台上进行部署和管理

2. 方案选择

Ø  现有轮子

我们是移动开发的团队,团队的成员大多都是客户端开发的,但是小伙伴们一技多能,还能维护平台的开发,并在京东内网进行部署。

现在为了部署TPaaS,基础技术组的同事进行了前期的技术探索,开发了一套不用写Dockerfile即可接入TPaaS平台的方案,使我们客户端团队的成员不至于又去重头学习一套全新的技能Dockerfile编写和部署,降低了大家接入的门槛,加快了接入的步伐。此方案主要解决了以下问题:

n  免写Dockerfile

n  参数配置化

n  编译镜像自动化

Ø  使用现有轮子?发明轮子?

我们尝试过这套方案之后,发现这套方案对于Java写的后端平台部署简直太棒了,按照规范把自己的War包放到云存储上,然后修改配置文件,再按照流程在平台上进行一键打包,哦哦,镜像出来啦~

当然对于前端部署一样的友好。

对于Aura平台,这套轮子不好用了,仔细研究后,发现了问题所在,这套方案之所以好用,是因为内置了一些常用的软件,比如NginxTomcat等,足以满足上述所说的环境部署。

但是Aura平台的系统架构较复杂,使用这套方案的话,就不只是使用轮子了,还需要再在这个轮子上加装很多东西才能达到使用的目的,尝试过后发现得不尝失,而且这个轮子的学习成本太高,不是使用学习成本,而是学习它的改装成本太高。

怎么办?发明一个轮子?为了这一个平台中的一部分,发明一个轮子显然不是明智之举,干脆让我们一部分老弱妇孺坐上这台马车,另一部分腿脚健全、身强力壮的小伙子直接走路吧,不见得就比马车慢。

最后,小伙子先走着,可以边走边完善轮子,或者能走出来一个更加便捷的轮子,再然后就不只是一技多能,而是一技多再加一能了,哈哈~

三、开始干活

1. 镜像划分

Aura平台的系统架构是这样的



Aura平台按照架构分为三个镜像,分别是

Ø  Aura2Web:包含前端,后端

Ø  Aura2JenkinsMaster:任务调度器

Ø  Aura2JenkinsSlaveCI构建节点

经过分析,由于Aura2WebAura2JenkinsSlave使用到的软件较多,环境配置复杂,决定这两个镜像使用DockerFile进行编写。

2. DockerFile编写

自己写的Dockerfile有两个,在写之前先研究一下Dockerfile的编写规则吧,否则事倍功半。

从网上找来了几条编写DockerFile需要注意的点,遵循这些经验才能编写出优秀的镜像

Ø  选择最精简的基础镜像

Ø  减少镜像的层数

Ø  清理镜像构建的中间产物

Ø  注意优化网络请求

Ø  尽量去用构建缓存

选择基础镜像

基于我们的环境,选择了服务器最稳定的Centos,版本号是7.2.1511,并修改源为京东内网源,加快下载依赖的速度。

安装基础软件

安装以下一些软件:JDKnginxPythonMavenGitTomcatJQ

业务源码到二进制包再到镜像

镜像是为了跑我们自己服务的,所以需要把我们的平台包放到镜像中,这个需要制定一个规则,方便记录从源码到镜像这一过程,并且可回溯。

Ø  前端:

n  前端使用的是Vue,需要进行编译构建,将构建后的产物放到镜像中

n  首先在源码中打TagPush到服务器,由WebHook钩子触发持续集成,编译出前端

n  将前端的产物打成zip包,放到京东的云存储上,记下链接地址备用。

Ø  后端:

n  后端需要进行混淆加密,加密后的产物同理打成zip包,然后将其放到京东的云存储上,记下链接地址备用。

3. 统一配置化改造

由于镜像中的代码使用到的配置文件较多,只Aura2Web镜像就达到了6个之多,所以需要一种方法进行统一的配置化

经过研究发现了一个超好用的配置管理的软件confd,下面介绍一下这个软件的用法

confd简介

Confd是一个轻量级的配置管理工具。通过查询Etcd或其它后端,结合配置模板引擎,可以保持本地配置最新,同时具备定期探测机制,配置变更自动reload。其后端支持的数据类型有:etcdconsulvaultenvironment variablesrediszookeeperdynamodbstackenginerancher。不过一般使用Confdetcd的配合使用比较多。

在我们的项目中暂时还用不着后端配合,只需要使用它的模板渲染,进行统一配置管理即

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

enteryshell脚本中执行生成真实的配置文件

    /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的编排文件编写

只要把握好了这些关键点,相信其它平台如有相同的需求,在进行私有化改造部署落地的过程中也会是很顺利的。




共0条评论