云应用部署方式的未来方向！

前言

本文主要介绍在Openshift PaaS平台上，部署应用的几种方式。

本文在书写过程中，在得到授权的前提下，笔者纳入了我前同事--王建的研究报告。谨借此文，祝愿王建在新的岗位上更上一层楼！

一、什么是Service Broker？

云计算一个很重要的属性是“自服务”。

要想实现自服务，就必须有服务目录，就像我们到京东买东西，页面能看到的产品一样。

在云管界面（CMP），我们可以申请应用、部署应用等。在这时候，云基础架构就是Service provider。例如，我们登录Openshift，在UI选择部署Tomcat，这个时候，Openshift就是Service provider。

随着服务目录中的应用越来越多，平台越来越多，为了实现服务目录和后端Service Provider松耦合（例如一个服务目录既可以访问IaaS层，又可以访问PaaS层），Service Broker概念被提出了。

二、Open Service Broker API开源项目

Open Service Broker API（https://www.openservicebrokerapi.org/）项目的目的，是让开发人ISV以及SaaS提供商可以用一种简单便捷的方式在多种云原生平台部署应用，这些平台包括：K8S、Openshift、CloudFoundry等。

三、OpenShift上的Open Service Broker

目前，Openshift3.7版本中，Service Catelog主要支持三种Service Broker：

OpenShift Template Broker、OpenShift Ansible Broker、AWS Service Broker。

OpenShift Template Broker是Openshift传统的模式。对于OpenShift Template Broker而言，它的Service Provier就是Openshift Template，说白了就是我们之前用的比较多的应用模板（yaml文件），即以模板的方式发布（多个）应用（组合）

这种方式通过书写yaml文件的方式实现，例如我们来看一个部署redis的模板：

目前在社区，已经有不少template的samples，供我们修改使用。但是，如果每个应用都通过编写template来实现，有的时候工作量会略大。

OpenShift Ansible Broker利用Ansible Playbook Bundles来实现应用在PaaS平台的部署。OpenShift Ansible Broker在Openshift3.7版本正式发布。对OpenShift Ansible Broker而言，它的Service Provider是Ansible Playbook Bundles。

在自动化运维领域，Ansible的易用性、多平台支持性我不再赘述。除此之外，很关键的一点是：借助于OpenShift Ansible Broker，负责运维的工程师的技能以及已经写好的众多Ansible Playbook，可以平移到PaaS平台上，这对企业而言，无疑实现了价值最大化。

OpenShift Ansible Broker的工作原理如下：首先，用户登录到Servcie Catelog，发起查找应用集合请求，这时候，Service Catelog向Ansible Service Broker发起请求，获取可用的App；接下来，Ansible Service Broker访问Registry，获取可用的App，并返回到Service Catelog上。此时，用户可见app，点击部署，接下来，Ansible Service Broker调用Ansible Playbook Bundles完成应用的部署。