How to Privatize JD’s Aura Android Component Platform on T‑PaaS with Docker & Kubernetes

Introduction

System cloudification helps technology and traditional enterprises reduce costs, improve efficiency, and enable collaborative work. This article records the journey of privatizing JD’s M‑PaaS Aura platform (an Android component platform) on the T‑PaaS environment.

Background

JD M‑PaaS is an enterprise‑level mobile development platform that provides a one‑stop solution for mobile development based on JD’s APP development experience. Aura is the Android‑focused componentization and modularization solution under M‑PaaS, offering efficient decoupling, parallel development, independent debugging, rapid building, and flexible integration.

T‑PaaS is the foundation for JD’s private deployment, designed to simulate various PaaS applications for easier commercial delivery in customer environments. It follows cloud‑native standards, packages services with Helm, and runs on Kubernetes.

1. Requirement Analysis

Requirement: Deploy the existing Aura platform on the T‑PaaS environment.

Compile Docker images for each component.

Write Kubernetes orchestration files.

Deploy on T‑PaaS.

2. Solution Selection

The existing standard solution simplifies Docker and K8s learning, enabling fast front‑ and back‑end private deployment. However, Aura’s complex architecture cannot be satisfied by the standard approach, especially for advanced CI/CD pipelines and intricate base‑environment containers. Therefore, a customized solution is required to lower transformation barriers and improve development efficiency.

Specific Transformation Implementation

1) Image Segmentation

The Aura system architecture is divided into three Docker images:

Aura2Web: contains front‑end and back‑end.

Aura2JenkinsMaster: task scheduler.

Aura2JenkinsSlave: CI build node.

Because Aura2Web and Aura2JenkinsSlave depend on complex third‑party software, custom Dockerfiles based on CentOS 7.2 are written for these images.

2) Dockerfile Writing Overview

Select the most minimal base image.

Reduce the number of image layers.

Clean up intermediate build artifacts.

Optimize network requests.

Leverage build cache whenever possible.

Based on CentOS 7.2, the Dockerfile installs JDK, Nginx, Python, Maven, Git, Tomcat, JQ, etc. The build process packages source code into binary artifacts, then into Docker images, following a traceable rule.

Custom rules:

Front‑end

Vue is compiled; the built artifact is placed into the image.

Tag the source, push to the server, trigger CI via WebHook, compile the front‑end.

Package the artifact as a zip and upload to JD Cloud storage.

Back‑end

Obfuscate and encrypt the back‑end, package as zip, and upload to cloud storage.

3) Unified Configuration Transformation

The Aura images contain many configuration files (e.g., six for Aura2Web). Managing them uniformly is crucial. The lightweight tool Confd is used for high‑efficiency configuration management.

Confd Introduction

Confd queries back‑ends such as Etcd, Consul, Vault, Redis, Zookeeper, etc., combines them with templates, and keeps local configuration up‑to‑date with automatic reload on changes.

In Aura, only the template rendering feature of Confd is needed.

Confd Usage Steps

Download the Confd binary from GitHub .

Add the binary to the image:

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

Create Confd configuration and template files.

Example configuration (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"]

Example template (frontend_domain.template):

server {
  listen 80;
  server_name {{ getv "/aura/frontend/domain_inner" }} {{ getv "/aura/frontend/domain_outer" }};
  ...
}

Copy configuration and template files into the image: COPY render /etc/confd Execute Confd in the entry‑script to generate real configuration files:

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

4) Middleware Configuration

Database : Create a new database (e.g., auradb) in the T‑PaaS MySQL instance, import Aura’s initialization SQL, and record connection info for ConfigMap.

GitLab : Create an account (e.g., aura) and record credentials for ConfigMap.

Maven Repository (Nexus OSS) : Create repositories libs-releases-local and libs-snaps, enable anonymous access, and record credentials.

MinIO (Cloud Storage) : Create required buckets and set read/write policies.

Dual‑Domain Transformation : Separate internal and external domains; add corresponding keys to ConfigMap and adjust Confd templates.

Kubernetes Manifests needed:

ConfigMap

Ingress

Service

Deployment

PersistentVolumeClaim

ConfigMap stores parameters for Confd rendering. PVC provides shared storage for Android SDK across JenkinsSlave nodes, reducing space usage.

Conclusion

This article presented the process of splitting the Aura platform into Docker images, compiling them, and deploying them in a private environment. The three key takeaways are:

Dockerfile authoring and image building.

Unified configuration management with Confd.

Kubernetes manifest creation.

Other platforms with similar requirements can follow these key points to achieve successful private deployment.