OpenPitrixは、オープンソースのアプリケーション管理システム曇りです

背景

クラウドコンピューティングは、よく知られているクラウドサービスベンダーで、今日の企業の大半で使用されている RightScaleの最近の調査に表示されていること、使用管理曇りのメーカーが増えています。そこ顧客が曇った管理を選択するためにあまりにも多くの理由があり、かつ単一のサプライヤを使用するよりも最大の理由は、ロックされているにつながることができます。したがって、曇った環境で曇りの環境、および自動化を管理する方法を、多くの企業は、単に必要になってきているし、このいずれかで、管理アプリケーションが特に重要です。さらに、挑戦アプリケーションは、従来のアプリケーション（またはアプリケーションと呼ばれる単量体、または従来のマスタ・スレーブ、スライスなどのアプリケーションの種類を管理するため、ワンストップ管理プラットフォームを作成することですpeer-これらの問題と学生を解決するための分散型エンタープライズアプリケーションのピア・ツー・ピア・アーキテクチャ）、マイクロサービスアプリケーションだけでなく、サーバレスアプリケーションの近年の急速な発展、OpenPitrix。文はOpenPitrixを説明しました。

OpenPitrixは、曇りの環境パッケージで使用されるオープンソースプロジェクトであり、デプロイおよびクラウドプラットフォームは、AWS、Azureの、Kubernetes、QingCloud、OpenStackのは、VMwareが含まれている間に、伝統的な用途、マイクロサービスアプリケーション、およびサーバレスアプリケーションを含む、異なるタイプのアプリケーションを、管理します、ように。

選択された新しいメインモードを作成するためのプログラミング、ビジネスアプリケーションの必然的な傾向であるマイクロサービスアーキテクチャとして知られているマイクロサービス、、。また、オープンソースプロジェクトKubernetesがデファクトとなっているオーケストレーションプラットフォームのリーダー、それが自動展開、拡張性、およびコンテナの管理のアプリケーションにユニークな利点を持っています。しかし、そう、たくさんの伝統的なレガシーアプリケーションのユーザーのクラウドプラットフォームにそのアーキテクチャを変更せずに、多くのユーザーのためにケース内に移動する、マイクロサービスアーキテクチャ、またはサーバレス・アーキテクチャの使用は、非常に長い道のりオフになって残っています私たちは、これらのユーザーはOpenPitrix非常に重要な機能であるクラウドコンピューティングプラットフォームに自分のレガシーアプリケーションを動かすために支援する必要があります。

2017年3月27日には、QingCloudがリリース AppCenterのが、目的はプラットフォームをクラウド従来のエンタープライズアプリケーションの開発者とユーザー間の友情の橋を設定するには、このプラットフォームの最大のハイライトは、それが開発者は、非常に低コストで学ぶことができることです実行するために、伝統的なQingCloudアプリケーションも、そのような敏捷性、スケーラビリティ、信頼性、および監視など、クラウドのすべての機能を持つことができます。クラウドプラットフォームにアプリケーションを移行する一般的に、開発者は、全体のワークフローを理解するために数時間を費やす必要が、その後、週または（この複雑の特定のアプリケーションに応じて）2過ごします。プラットフォームは、人気のオンラインユーザーの好意と賞賛されているが、一部のユーザーはより多くの要求を行った後、彼らは彼らの内部の曇りの環境を管理するためにそれを展開します。ユーザーのニーズを満たすために、QingCloudは曇った状況下でのアプリケーションの複数の種類を管理すること、それを拡張し、事業の健全な発展にオープンソースのアプローチの使用。

諺に通り：クラウドでアプリケーションの開発を計算OpenPitrixオリジナルチームが豊富な十分な経験があるものの、そして成功した安定的なビジネスの製品を開発し、「簡単には口で言う」：AppCenterのは、あなたが知っている、の前で待って、まだたくさんあります克服すべき困難。OpenPitrix 実施するための道を開くために最初から、そして2018年2月24日のみ、その間に、チームを機能コードの最初の行を書いたまで、2017年8月には、GitHubの上の組織やプロジェクトを作成したがすべてのメンバーは、システム内の各臨界点を考えている、これらの議論の詳細については、GitHubの上で利用可能なオープンアクセス。

上記プロジェクトのOpenPitrixのインとアウトを導入して、次の詳細な機能やデザインの詳細のいくつかを説明します。

主な機能

所望の機能を達成OpenPitrix、次のものがあります。

このようAWS、Azureの、Kubernetes、QingCloud、OpenStackのは、VMwareなどというように複数のクラウド・プラットフォームのサポート。
サポートされているクラウドプラットフォームは、高い拡張性とプラグ可能です。
複数のアプリケーション・タイプのサポート：従来のアプリケーション、マイクロサービスアプリケーション、サーバレスアプリケーション。
アプリケーションのサポートは、新しいアプリケーションの種類は、将来発生に関係なく、OpenPitrixプラットフォームは、適切なプラグインを追加することによって、それをサポートできることをどの手段も高度にスケーラブルです。
倉庫のアプリケーションは、そのアプリケーションが取引されている使用することができOpenPitrixショップによって駆動された手段で、設定可能です。
可視性アプリケーションライブラリパブリック、プライベート、またはユーザーのみの特定のセットが市場を牽引しOpenPitrixによってアクセスすることができ、各ベンダーが彼/彼女の自身のアプリケーションストアの一部を動作させることができるようになります許可を含め、設定可能です。

ユーザーシナリオの例

OpenPitrix一般的なユーザーシナリオは以下のとおりです。

企業システムは、展開およびアプリケーションを管理するためのワンストップアプリケーション管理プラットフォームを達成するために、（ハイブリッドクラウドを含む）濁っの使用です。
管理アプリケーション濁った環境を実装するためのコンポーネントOpenPitrixの一つと考えることができるクラウドプラットフォーム管（CMP）。
Kubernetesは、アプリケーション管理システムとして使用することができます。OpenPitrixとヘルムはヘルムとOpenPitrix底がKubernetesアプリケーションをデプロイするが、根本的に異なるがありますが、そのような開発、テスト、として通常分類する状態のアプリケーションに応じて、そのような企業のように、完全なライフサイクル管理アプリケーション、、、上OpenPitrix焦点プレビュー、生産、さらにいくつかの組織はヘルムを持っていないとする、部門別に分類されます。

アーキテクチャの概要

基本的な考え方のOpenPitrixの設計は、以下のように（代わりに、クラウドプラットフォーム、以下同じランタイム環境を使用しての）アプリケーションとアプリケーション実行環境のデカップリングです。ストアからエンドユーザを一つ選択、あるプロバイダ情報と一致することに加えて、だけでなく、ここで、セレクタ（セレクタ）およびランタイム環境ラベル（ラベル）アプリケーション・ウェアハウスと一致する必要が、環境で実行するアプリケーション特定のアプリケーションは、それを展開しようと、システムが自動的にランタイム環境を選択します。あなたはこのアプリケーションを実行することができ、複数のランタイム環境を持っている場合、システムは、ユーザーが選択できるように、より設計の詳細を対応するダイアログボックスをポップアップ表示されます、ご参照ください OpenPitrixの設計文書を。

システムアーキテクチャ

ストレージサブシステムのアプリケーション

アーキテクチャの上記の概要に示されているように、ストレージサブシステムは、三つの成分に分けられる：ストレージ管理（レポマネージャー）、リポジトリインデックス（レポインデクサ）、倉庫（APPレポ）;ここ倉庫などのストレージ管理（レポサービス）およびそのバックエンドデータベース（DBレポ）、図に示すように、アーキテクチャ。目に見える、通常はシステム管理者や開発者が倉庫のプラットフォームを作成するかどうかURL、資格情報、：情報は、ウェアハウス・ユーザーとしてアプリケーションを作成するために設定するために必要。デーモン倉庫インデックスは、定期的に新倉庫、データベースアプリケーション管理サービスへの既存の倉庫への更新、および更新をスキャンします。私たちは、倉庫保管アプリケーションはどのOpenPitrixベースのアプリケーション管理プラットフォームと共有することができるので、倉庫保管は、特定のOpenPitrixプラットフォームから独立して、見ることができます。詳細については、設計を参照してください OpenPitrix倉庫・サブシステムの設計。

アプリケーション・ウェアハウスのアーキテクチャ

アプリケーション倉庫組織によっては、ストアベースOpenPitrixにより販売されている別個の資産として使用することができます。

曇りの環境へのレガシーアプリケーションを移行する方法

彼らはパブリックまたはプライベートクラウドであるかどうか、すべてのそれはそれを明確にし、迅速な特別な事情がない場合には、この文脈で、曇りやハイブリッドクラウドの違いを区別することがOpenPitrix特にない、曇りの手段複数のクラウド環境つまり、最初のまたは同じもしくは異なるベンダーから。

仕様

很显然，我们将大量借助 QingCloud AppCenter 的经验来实现在多云环境下“云化”传统应用，这其中包括规范在内。为了简单起见，我们在这里展示了一个不完整的 ZooKeeper 云化规范版本，如下所示，完整版本请参考 AppCeneter 示例，该规范很容易理解，文件 cluster.json.tmpl定义了 ZooKeeper 集群信息，如名称、描述、多少节点（每个节点的 CPU、内存、存储、镜像、生命周期等），双花括号中的变量来自最终用户从 UI 输入的信息，这些变量是由文件config.json定义的。ZooKeeper 应用开发者将这两个文件打包上传到 OpenPitrix 平台，最终用户在部署应用的时候输入必要的信息、点击部署按钮即可。这个应用程序包(还包含语言文件)如同镜像是虚拟机的模板一样，它是一个应用程序的模板，只是它相比镜像更为的复杂罢了，因为它可能包括多个镜像，而且要定义应用程序集群的整个生命周期，还有，它还要支持自定义的监控、健康监测等等更多的功能。正如我们所看到的，开发者将传统应用移植到云平台中除了几个说明文件毋须任何的编码。

cluster.json.tmpl for ZooKeeper

config.json for ZooKeeper

架构

整个系统中最具挑战性的工作就是如何将上述的一套标准的传统应用软件包无需任何修改就能部署到多个云平台中，因为传统的应用均是基于虚拟机而非容器的。OpenPitrix 设计团队经过了激烈的讨论，最后总结出如下几个原则：

OpenPitrix 自身是可以部署到任何地方的。因此，该平台必须支持最终用户同时将应用程序部署到公共云和私有云中，这意味着 OpenPitrix 从架构必须支持能够通过公共互联网部署应用程序；
针对每个 IaaS 平台供应商的架构是一致的；
最终用户部署应用程序毋须任何麻烦的配置，这意味着对于最终用户而言，一切都是透明的，例如元数据服务的初始化。

经过反复的讨论后，我们提出了以下解决方案。首先解释一下架构中出现的一些术语。

Drone：该组件由 agent 和 confd 所构成，Confd 是自动配置 app 实例的守护进程，agent 负责和 Frontgate 的通信，例如来自最终用户发来的指令。agent 也会负责根据应用的状态启动和停止 confd。Drone 是预先安装到应用程序所在的每一个镜像中。
Frontgate：该组件包含 proxy 和 etcd，Etcd 是后端的存储，存储集群的信息包括集群名称、描述、多少节点、由最终用户发来的指令等。Proxy 连接 Pilot 和 Drone 的 agent，因为虚拟机是运行在 VPC 中，Pilot 无法和 Drone 直接进行通信，所以需要在它们二者之间设置一个 proxy。在有应用运行的 VPC 中会存在一个 Frontgate，这个 VPC 内的所有应用集群共享这个 Frontgate，这个 Frontgate 是当最终用户第一次部署应用程序时，系统自动创建的，且 Frontgate 对最终用户不可见。
Pilot：接受来自集群服务的指令和信息的组件，如创建集群等，并可以传递指令给 Frontgate，它还接收来自 Frontgate 上传上来的信息。

毫无疑问，工作流程很复杂。我们以部署一个应用程序为例来进行简要的说明，一般步骤如下：

最终用户发送请求到 API 网关，API 网关会将之转发给相应的服务，如集群服务；
集群服务收到请求之后，将之放到 job 队列，job 控制器收到后将其分解成 task，然后放到 task 队列；
Task 控制器将 Task 从队列中提出，然后去调用特定的云平台 API，创建集群资源如主机；
集群服务同样会给 Pilot 发送集群的元数据；
Pilot 转发信息给 Frontgate 的 proxy，然后 proxy 会将信息注册到后端的 Etcd；
应用程序镜像内部的 Drone 的 Confd 会监测 etcd 的更新，然后自动更新应用配置；
最后，Drone 中的 agent 为用户启动应用。

整个流程，如下图所示：

VMベースのアーキテクチャ

应用程序镜像

正如上面所阐述的，传统应用通常是部署到虚拟机中的，而微服务应用往往是进行容器化的。如果我们使用虚拟机来支持传统应用部署到多云环境中的话，会遇到非常大的挑战。这意味着应用的开发者或供应商在每一个环境中都需要上传或创建镜像，而这在现实中往往很难行得通，尤其是公有云供应商提供很多的 region 和 zone。鉴于此种情况，我们选择了在虚拟机中运行容器的方式来解决此问题，可以建立集中的容器镜像仓库，需要运行时直接拉到云平台中的虚拟机中即可。此种方式也有弊端，那就是在网络不好的地方，拉容器镜像就是一个大的问题，如果下载容器镜像的时间过长，对于用户的体验和耐心都是极大的挑战。要解决此问题，在每个云环境部署缓存或 mirror 是非常好的选择。第二个问题是开发人员需要知道 Docker，这似乎不是一个大问题，因为在我看来，掌握 Docker 是当今开发人员的基本技能。

但是，我们依然需要支持直接在 VM 中安装应用程序软件，并将 VM 分发到每个云环境中，原因如下。

有一些应用需要定制化 Linux 内核；
开发者没有掌握 Docker 技术，或者说因为额外的学习或开发成本，开发者并不愿意用 Docker 的方式将传统应用移植到云环境中；
最终用户没有意愿去创建一个诸如 Kubernetes 这样的容器编排集群去部署一个传统应用，或者是用户没有 Kubernetes 环境。

在第一个版本中，会在虚拟机中使用 Docker 的方式来解决应用程序镜像的分发问题，在下个版本中，将支持直接在 VM 中安装应用程序软件。

如何支持多种类型的应用

正如我们开始所说的，OpenPitrix 是支持多种类型的应用程序。当一个用户开始部署一个应用的时候，系统会自动识别应用类型并选择相应的插件去创建应用集群。我们用 provider interface 和 provider plugin 来支持不同类型应用以及将来可能出现的未知应用类型。系统目前有两大类应用类型：基于虚机的和基于容器的，前者是支持传统应用上云，这个我们已经在上一章节解释过了，现在我们解释一下 OpenPitrix 如何支持日益流行的基于互联网规模的应用程序：微服务和 Serverless。对于 OpenPitrix 的第一个版本，没有打算支持 Serverless，我们认为 Serverless 应用还没有标准，而且也没有看清楚谁将赢得最后的胜利。市场上没有与其他主要供应商兼容的产品或服务。那么这样的局面就是家家都是标准的制定者，所以，OpenPitrix 团队决定第一个版本暂时先不支持将 Serverless 应用部署到多云环境, 并持续关注 Serverless 最新标准的进展。

另外，在容器的编排方面，开源项目 Kubernetes 已经赢得了胜利，因此，OpenPitrix 会支持 Kubernetes。Helm 是一个非常不错的 Kubernetes 包管理器，在第一版 OpenPitrix 中，我们使用 Helm 作为 Kubernetes 应用程序的部署工具，在下一版或许会直接采用 Kubernetes 的应用编排格式。

示されているようにOpenPitrixに以下のように、我々はヘルムクライアントパッケージ化されます、追加のサーバー側コンポーネントヘルムティラー意志OpenPitrix成分としてエンドユーザーのOpenPitrixなど、およびヘルムについて何かを学ぶために、私たちができる必要はありません。や非行で詳述するように、改善のため、まだ余地、執筆時点では、しかし、でKubernetesにマルチクラスタ管理Kubernetes用ヘルムサービスをアプリケーションを展開 1586年と1918年問題が解決される前に、そのため、私たちはティラーをインストールするには、各ユーザーに求めます、 Kubernetesクラスタ。ときにエンドユーザKubernetesクラスタ構成、システムが自動的にOpenPitrixとKubernetesクラスタ間の接続を設定し、テストします。そして、ユーザはKubernetesは、任意のクラスタにアプリケーションをデプロイすることができます。