JD Retail Cloud mPaaS プラットフォーム: Android コンポーネント化システムのプライベート展開と変換の実践

1. 背景

現在、クラウドコンピューティングは間違いなく非常にホットな話題です。テクノロジー企業と従来型企業の両方がこの話題について話し合い、企業のコスト削減、効率性の向上、共同オフィスなどを支援しています。技術者として、私たちが注目する話題は依然としてテクノロジー関連です。この記事は、JD.com が作成した JD Retail Cloud の背景に基づいています。 JD Retail Cloud mPaaS プラットフォームにおける Android コンポーネント化システムのプライベート展開と変換のプロセスを記録し、全員と共有します。

JD Retail Cloud mPaaS プラットフォームは、JD.com が作成したエンタープライズレベルのモバイル R&D および運用プラットフォームです。 Aura は、Android 向けのコンポーネントベースのプラグインソリューションです。

T-PaaS プラットフォームは、JD.com のプライベート展開の基盤であり、さまざまな PaaS アプリケーションをさまざまな顧客環境でより簡単に商用化できるように設計されています。アクセス仕様はクラウドネイティブ標準に完全に準拠しており、PaaS サービスがエコシステムアプリケーションや顧客ビジネスと容易に連携し、クラウドネイティブコンテナとオペレータの形でアプリケーションロジックを実装し、Helm 標準の方法でパッケージ化し、Kubernetes 上で統一的に展開および管理できることを保証します。

ここで共有されているのは、JD.com のクラウド移行の文脈において、Aura プラットフォーム (Android コンポーネントプラットフォーム) がクラウドおよび T-PaaS 環境への移行プロセスを開始したことです。

2. 需要分析とソリューションの選択

1. 需要分析

要件と目的は明確で、現在の社内プラットフォームシステムAuraをTPaaSプラットフォーム上に展開することです。

TPaaS プラットフォームは、Kubernetes を使用してコンテナのオーケストレーションとデプロイを行い、Docker コンテナを管理するため、次の 2 つの作業を行う必要があります。

Dockerイメージをコンパイルする
k8sオーケストレーションファイルを作成し、TPaaSプラットフォームにデプロイして管理する

2. ソリューションの選択

既存のホイール

私たちはモバイル開発チームです。私たちのチームメンバーのほとんどはクライアント開発者ですが、多才な人材が揃っており、プラットフォーム開発を維持し、JD のイントラネットに展開することもできます。

TPaaS を展開するために、基礎技術グループの同僚が予備的な技術調査を実施し、Dockerfile を記述せずに TPaaS プラットフォームにアクセスするソリューションを開発しました。これにより、クライアントチームは Dockerfile の記述と展開に関する新しいスキルセットを再学習する必要がなくなり、アクセスの敷居が大幅に下がり、アクセスのペースが速まります。このソリューションは主に以下の問題を解決します。

Dockerfileを書く必要はありません
パラメータ設定
イメージのコンパイル自動化

既存のホイールを使用しますか?発明しますか?

このソリューションを試した後、Java で記述されたバックエンドプラットフォームのデプロイメントに最適であることがわかりました。私たちは、仕様に従って War パッケージをクラウドストレージに配置し、構成ファイルを変更し、プロセスに従ってワンクリックでプラットフォームにパッケージ化しました。あ、画像出ましたね〜

もちろん、フロントエンドのデプロイメントにも同様に適しています。

Aura プラットフォームの場合、このホイールセットは使いにくいです。慎重に調査した結果、問題が見つかりました。このソリューションが使いやすい理由は、Nginx、Tomcat など、上記の環境展開を満たすのに十分である、一般的に使用されるソフトウェアが組み込まれているためです。

ただし、Aura プラットフォームのシステムアーキテクチャは比較的複雑です。このソリューションを使用する場合、ホイールを使用するだけでなく、使用目的を達成するためにホイールに多くのものを追加する必要があります。試してみると、利益が損失を上回らず、このホイールの学習コストが高すぎることがわかりました。使用方法を学ぶコストは高くありませんが、変更方法を学ぶコストは高すぎます。

何をするか？車輪を発明しますか？明らかに、単一のプラットフォームの一部だけを対象にするのは賢明な動きではありません。高齢者、体の弱い人、女性、子供の一部を馬車に乗せ、健康な足を持つ若者が直接歩かせるのが良いでしょう。馬車より遅くはないかもしれません。

最後に、若者はまず歩き、歩きながら車輪を改良したり、より便利な車輪を考案したりすることができます。そうなると、1つのスキルに複数の能力だけではなく、1つのスキルに複数の能力がプラスされてさらにもう1つの能力になるんですね、ハハハ～

3. 仕事を始める

1. ミラーパーティション

Auraプラットフォームのシステムアーキテクチャは次のとおりです。

Aura プラットフォームは、アーキテクチャに応じて 3 つのイメージに分かれています。

Aura2Web: フロントエンドとバックエンドを含む
Aura2JenkinsMaster: タスクスケジューラ
Aura2JenkinsSlave: CI ビルドノード

分析の結果、Aura2Web と Aura2JenkinsSlave は使用するソフトウェアが多く、環境構成も複雑であるため、DockerFile を使用してこれら 2 つのイメージを書き込むことにしました。

2. DockerFileの書き方

2 つの Dockerfile を作成しました。これらを書く前に、まず Dockerfile を書くためのルールを勉強しました。これらの経験に従うことによってのみ、優れた画像を書くことができます。

最も合理化されたベースイメージを選択する
画像レイヤーの数を減らす
イメージ構築の中間生成物をクリーンアップする
ネットワークリクエストの最適化に注意する
ビルドキャッシュの使用を試みる

ベースイメージを選択

私たちの環境に基づいて、バージョン番号 7.2.1511 の最も安定した Centos サーバーを選択し、依存関係のダウンロードを高速化するためにソースを JD イントラネットソースに変更しました。

基本ソフトウェアをインストールする

JDK、nginx、Python、Maven、Git、Tomcat、JQ などのソフトウェアをインストールします。

ビジネスソースコードからバイナリパッケージ、そしてイメージへ

このイメージは独自のサービスを実行するために使用されるため、プラットフォームパッケージをイメージに配置する必要があります。これには、ソースコードからイメージまでのプロセスを記録し、追跡可能にするためのルールを策定する必要があります。

フロントエンド：

フロントエンドでは Vue が使用され、コンパイルとビルドが必要で、ビルドされた製品はイメージ内に配置されます。
まず、ソースコードにタグを追加してサーバーにプッシュし、WebHook フックによって継続的インテグレーションをトリガーして、フロントエンドをコンパイルします。
フロントエンド製品を zip パッケージにまとめ、JD のクラウドストレージに配置し、後で使用するためにリンクアドレスを書き留めておきます。

後部：

バックエンドは難読化および暗号化する必要があります。暗号化された製品は zip パッケージにまとめられ、JD のクラウドストレージに配置されます。今後の使用に備えてリンクアドレスをメモしておいてください。

3. 統一された構成変換

イメージ内のコードでは多くの設定ファイルが使用され、Aura2Web イメージだけでも 6 個ものファイルがあるため、統一された設定を行う方法が必要です。

調査の結果、非常に便利な構成管理ソフトウェア confd を見つけました。以下はこのソフトウェアの使い方の紹介です。

confd の紹介

Confd は軽量の構成管理ツールです。 Etcd またはその他のバックエンドをクエリし、それを構成テンプレートエンジンと組み合わせることで、ローカル構成を最新の状態に保つことができます。また、定期的な検出メカニズムも備えており、構成の変更を自動的に再読み込みします。バックエンドでサポートされているデータタイプには、etcd、consul、vault、環境変数、redis、zookeeper、dynamodb、stackengine、rancher などがあります。ただし、Confd と etcd は通常一緒に使用されます。

当プロジェクトでは、当面バックエンドの連携は必要ありません。テンプレートレンダリングを使用し、統合された構成管理を実行するだけです。

confdg ダウンロード

https://github.com/kelseyhightower/confd/releases から confd のバイナリファイルをダウンロードします。

ここでは、confdをイメージに配置し、次のステートメントをdockerfileに直接追加する必要があります。

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

confd設定ファイルとテンプレートファイルを作成する

図に示すように、ニーズに応じて複数の構成とテンプレートを作成できますが、それらは互いに対応している必要があります。

例: frontend_domain.toml

 [テンプレート]  
 src = "frontend_domain.template"    
宛先 = "/opt/servers/nginx/conf/domains/frontend_domain"    
キー = [  
 「/aura/frontend/domain_inner」 、  
 「/aura/frontend/domain_outer」 、  
 ]  
 Frontend_domain.テンプレート 
サーバ 
 {  
聞く 80;  
 server_name {{ getv "/aura/frontend/domain_inner" }} {{ getv "/aura/frontend/domain_outer" }};  
 ...  
 }

構成ファイルとテンプレートファイルを Dockerfile 内のイメージにコピーします。

 /etc/confd をコピーする

実際の設定ファイルを生成するには、entery のシェルスクリプトを実行します。

 /usr/bin/confd -onetime -バックエンドファイル -ファイル ${config_file_path}

4. 関連するミドルウェア構成

データベース

TPaaS のドキュメントを参照し、ローカルマシン上で構成する必要があるホストを構成し、phpmyadmin.tpaas.local にログインします (ユーザー名とパスワードはドキュメントから取得します)。

新しいデータベースを作成し、データベース名をカスタマイズします。ここでの名前は auradb であると仮定します。

以前に作成した Aura 初期化 SQL をダウンロードし、SQL をインポートします。

以下の情報を記録し、後でconfigMapに入力します。

URLとポート番号
データベース名
ユーザー名とパスワード

ギットラボ

ミドルウェア情報の URL を参照して、GitLab URL を見つけ、Web サイトにログインし、ミドルウェア情報で提供されているユーザー名とパスワードを使用するか、新しいアカウントを作成します。ここで、新しいアカウント「aura」が作成され、パスワードは「xxxxx」になります。それを記録し、後で configMap に配置します。

Maven プライベートサーバー (Nexus リポジトリ OSS)

ミドルウェア情報のURLを参照して、アドレスとユーザー名とパスワードを見つけてログインします。

次の 2 つのウェアハウスを作成します (作成時に、デプロイメントポリシーパラメータでアップロードを許可するを選択します)

libs-リリース-ローカル
libs-スナップショット-ローカル

匿名アクセス許可を有効にします。すでに有効になっている場合は無視してください。ユーザーを作成し、ユーザーのアカウントとパスワードを記録します。これらは後で configMap に入力されます。

クラウドストレージ（minio）

ミドルウェア情報の URL を参照して、アドレスとユーザー名とパスワードを見つけます。
ログインして必要なバケットを作成し、アクセスポリシーを読み取り/書き込みとして設定します。

5. 二重ドメイン名変換

民営化された顧客の環境は内部環境と外部環境に分かれているため、プラットフォームがアクセスするドメイン名も内部ドメイン名と外部ドメイン名に分かれています。内部ドメイン名はサービス呼び出しに使用され、外部ドメイン名はユーザーによる直接アクセスに使用されます。デュアルドメイン名変換の重要なポイントは、どのサービスが内部サービスによってのみ呼び出され、どのサービスがユーザーが直接呼び出す必要があるかを分類することです。明確な分析の後、対応するキー値を configMap に直接追加し、Confd 構成を変換して関連するドメイン名に適合させます。たとえば、フロントエンドドメイン名の構成は Confd セクションに指定されています。

6. K8Sオーケストレーションファイル

イメージファイルが生成されたら、次のステップは K8S オーケストレーションファイルを書き込むことです。その後、イメージを K8S プラットフォームにデプロイできます。

以下の配置ファイルを設定する必要があります

構成マップ
進入
サービス
展開
永続ボリュームクレーム

構成マップ

その主な機能は、設定する必要のあるパラメータをここに置き、それをレンダリング設定のためにイメージ内のconfdに渡すことです。

永続ボリュームクレーム

主にファイルやディレクトリを外部にマウントするために使用されます。ここでは、複数のビルドノードが SDK を共有してスペースを節約できるように、Android SDK をマウントするために使用されます。

JenkinsSlaveイメージはマウントされたPVCをAndroid SDKの入力として使用します。

複数の JenkinsSlave ノードは、ストレージスペースを節約するために、同じ PVC 内の Android SDK を共有します。

PVC マウントディレクトリは /usr/local/aura/auraCfs です。他のディレクトリ (/mnt/auraCfs など) にマウントし、/usr/local/aura/auraCfs をソフトリンクとして使用して、そのディレクトリを指すこともできます。

SDK ファイルを解凍します。ファイルは 2 つあります。

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

両者の違いは、Gradle キャッシュが約 14G です。キャッシュは使用しても使用しなくてもかまいません。使用しない場合は、ネットワークから自動的にダウンロードされ、最初のビルドの時間が延長されるだけです。

手順は次のとおりです。

xz ファイルを PVC のルートディレクトリに解凍します。
「Gradle キャッシュを使用する」を選択します。
プリセットの Gradle キャッシュを使用して最初のビルドを高速化することも、プリセットのキャッシュを使用せずにビルドプロセス中にネットワークから依存パッケージを自動的にダウンロードすることもできます。グレードキャッシュを使用するには、以下の手順に従います (コロンになり、次のステップをインデントしてステップを区別できますか、インデント、次のステップ、ステップは何ですか?)
JenkinsSlave イメージに十分なストレージ容量があることを確認します (200G 以上)
圧縮パッケージ with-gradlecache を使用する
PVCディスクのルートディレクトリに空のファイルuse_gradle_cacheを作成します。
解凍後、イメージ起動スクリプトは「Gradle User Home キャッシュの回復が完了しました」と出力します。