如何跨云实现应用部署管理

e 里面定义了 Memory 的可选配置。在用户创建这个应用的实例时，DashBoard 会根据 config.json 里面的定义渲染页面，也就是右侧的截图， 可以让用户根据开发者提供的配置， 选择自己要创建的应用实例类型。上图是一个 cluster.json.tmpl 的例子， 双花括号里面的是引用自 config.json 里面的值，一键创建时，用的是 config.json 里面变量的 Default 值，当然如果用户创建时通过命令行或者 DashBoard 修改了变量的值，则按照新的值渲染并创建。这里定义了这个应用有一个叫 ZK 的角色，这个角色创建时需要用到 Docker 的这个 Image，下面 Service 部分则描述了应用创建，删除等生命周期所需要执行的指令，比如这里定义了创建时要执行的 Init 指令和 Start 指令。开发者通过简单的配置包定义，就完成了应用的开发，可以通过 OpenPitrix，让不同云平台的用户去部署使用。第二个问题：开发者的应用映像如何分发到多云环境？其实容器类的应用在映像分发方面做的很好，可以有统一的容器映像仓库，启动时去仓库 Pull Image，所以微服务应用支持不存在映像分发的问题。而传统应用通常是部署到虚拟机中的，传统应用多云部署时就面临映像分发的问题，开发者定义在应用 Package 里面的映像 ID，如何分发到多云的环境中去？我们知道，每个公有云都会有很多的 Region 和 Zone，如果让开发者自己在每个里面上传或创建映像，是一件很困难的事情，为了解决这个问题，我们想了很多解决方案，但都还不成熟。比如让开发者将 VM Image 的制作流程写成脚本，需要某些软件包，则从公网上下载，这样在用户第一次创建这个应用实例的时候，OpenPitrix 平台自动创建这个 Image，然后在跨 Zone 将 Image 迁移到其他 Zone，并共享给用户确保其能够启动应用。在第一版本传统应用我们会先采用 VM 里面跑 Docker 的方式来解决映像分发的问题。第三个问题，如何操作云主机执行命令，是个网络问题。OpenPitrix 自身是可以部署到任何地方的，而最终用户要部署的应用是运行在各个云环境上的 IaaS 资源上，那两者之间如何通信，以及发送指令的呢？我们的解决方案是通过公共互联网，也就是两者通过公网打通，现在的云平台主机资源为了安全性， 一般都是运行在专有网络里面的，也就是位于 VPC 下面，我们 OpenPitrix 也会将应用实例默认部署到 VPC 下，具体解决方案是分别在 OpenPitrix 框架内，位于 VPC 下应用实例主机里定义了 3 个组件：Pilot、Frontgate、Drone。Pilot 领航员的意思，是 OpenPitrix 在部署 VM 类型应用时所使用的一个服务，作用就是下发命令给具体部署在某个 Provider 提供的云服务的 Runtime 的 Instance。Drone，无人机，是运行在应用程序所在的主机上的，该组件由 Agent 和 Confd 所构成，Confd 是一个开源的项目，能够自动完成 App 服务配置文件更新，并在配置发生变化时触发特定的操作。Agent 负责接受 OpenPitrix 框架发过来的指令，并上报指令的执行状态。Pilot 没办法直接发指令给 Drone，因为一个在 OpenPitrix 上，一个在具体 Runtime 上， 环境不同，没法直接通信， 所以需要一个 Proxy，来转发请求， 这个功能就是 Frontgate 提供的。Frontgate，直译是前门，也就是最外层的大门，在有应用运行的 VPC 中都会存在一个 Frontgate，这个 VPC 内的所有应用集群共享这个 Frontgate。该组件包含 Proxy 和 ETCD，Proxy 起着承上启下的转发功能，Frontgate 主机创建时，会将 Pilot 的地址写入，Frontgate 启动时可以和 Pilot 建立一个双向的 Grpc Stream，建立这个连接后，两个组件之间可以任意通信了。后面 Pilot 就可以发指令给 Frontgate，而 Frontgate 和 Drone 位于同一 VPC 内，属于内网，可以将请求发给 Drone 并执行，执行结果也可以经由 Frontgate 上报给 Pilot。Frontgate 里面的 ETCD 会存储应用部署实例的元数据信息， Drone 里面的 Confd 也是通过 Watch ETCD 从而实现服务发现和自动配置变更的。这里有必要说一下, 既然 Pilot 只是一个下发指令的服务，从 Cluster 里面独立出来，是为了灵活的扩展性。Pilot 控制多云 VM Based 的 Runtime 里面的主机，量会越来越多。目前第一版本，我们没有考虑多云应用的编排, 比如 AWS 上的一个 Kafka，使用的 OpenStack 上部署的一个 ZooKeeper。但由于 Pilot 可以和任何一个 Runtime 交互，所以后面的版本我们可以基于 Pilot 做多云应用的编排。现在假设有一个用户要在 OpenPitrix 上部署一个应用，他选择应用，选择 Runtime，填写应用所必须的资源信息和环境变量后，点击创建，OpenPitrix 会如何工作呢？首先，发送 API 到 API 网关，API 网关会将之转发给 Cluster 子服务；然后，Cluster 子服务收到请求之后，会先解析配置包，注册 Cluster 的数据库信息，然后将请求封装为一个 JOB，并放到 JOB 消息队列中等待调度执行，JOB Controller 会异步的解析 JOB，拆分成多层 Task，每一层 Task 是可以并行执行的，多层 Task 是有依赖关系需要顺序执行的，这样就将一个 JOB 解析成了 Task 的工作流，Task Controller 可以逐层的去调度执行 Task，保障依赖顺序。其次，Task 是根据当前 Runtime 的 Provider 的 Provider Plugin 来执行的，Task 有几种类型：一种是调用云服务的 API 来执行 RunInstance、CreateVolume 的操作，如果是容器类的应用，Task 会将请求发给 Helm 的 Server 端，Tiller 去执行，这个后面会介绍。如果是基于 VM 的应用，有些 Task 是需要经由 Pilot 下发到 Drone 的，这些 Task 的依赖 Task 就会完成前序工作。也就是创建好 Frontgate 并和 Pilot 建立双向 Grpc Stream 连接。通过他们之间的交互，完成创建步骤后续的元数据注册，Confd 服务启动，开发者定义的 Init 和 Start 指令的执行等操作。OpenPitrix 同样支持容器类型的应用，我们第一版本中的 K8S Provider Plugin 是通过 Helm Client 实现的，容器应用会通过 Helm 部署到 Kubernetes 集群中。目前 Helm 的服务端 Tiller 只支持将 Chart 的实例部署到单一 Kubernetes 中去，所以需要在 Kubernetes 的 Runtime 里安装 Tiller 这个服务。OpenPitrix 应用实践刚才介绍了 OpenPitrix 的功能以及技术架构，接下来一同看下 OpenPitrix 的主要应用场景。由于 OpenPitrix 的