专栏首页AI2ML人工智能to机器学习轻度解释Cloud Foundry命令行

轻度解释Cloud Foundry命令行

1 轻诉架构

1.1 应用之云飘啊飘

我们知道Cloud Foundry (CF)是一个PaaS平台。 CF命令行(CLI)作为开始部署使用CF云平台的用户来说,一个轻度的CF CLI的解释会是一个比较好的入门选择。所以飘在我们最前面的,目前很多企业工业云平台背后就是Cloud Foundry云平台。

那为什么很多企业云后面还有CF云呢?为什么选Cloud Foundry呢?因为企业工业云是要将一个可以绑定工业数字化模型的PaaS云,那么底层需要选择一个通用的PaaS云,而CF就是一个极好的PaaS云。 PaaS是要帮屏蔽了管理中间件和运行部分,让你集中在应用和数据。底层还有IaaS云,帮你屏蔽了管理操作系统。

其实除了这三层之外,还有SaaS层,但是为了适应不同的工业领域的应用开发,不能走到SaaS层,固定好数据和应用,所以只能到PaaS层:

那为什么选Cloud Foundry,而不选其他的PaaS平台呢?首先我们看一下目前有哪些知名的PaaS平台,不知名的,肯定不太靠谱了。我们看到在PaaS层面上,除了Docker和Cloud Foundry,其他的分布式Amazon, IBM, Microsoft,RedHat和SAP的平台。相比较而言, Amazon, IBM, Microsoft和SAP都有自己的工业业务,一定程度是也可以是很多企业的竞争对手。所以大部分企业工业云不能选由竞争对手主导的平台作为主流。再比较Docker,Cloud Foundry,和RedHat的OpenShift。那么Cloud Foundry在可扩展,稳定性方面的优势就比较明显了。所以选用了EMC投资的Pivotal Software。

CF是方便你管理应用和数据的PaaS云平台。那么,一般一个在线服务,会有三层:用户层,服务层,和资源层(数据层)。

1.2 不同架构高呀高

那么对应到三层里面的服务层,要做好用户层的需求,有个经典的MVC模型,划分出模型Model,来搞业务逻辑,视图View来搞展示界面,还有控制器Controller,来匹配模型和视图。这样,控制器就显得尤为重要。

这样我们对应不同的URL访问,就需要匹配不同的Controller (MVC实例)。

举个例子,一个订单应用里面,你要提供展示订单和添加订单的功能。

时候,人们把这个匹配的功能独立出来,提出了路由Route的功能。

随着路由功能的增强,他成为了新型MVC模型的一部分,使得不同服务可以使用相同的Controller,同一个服务也可以使用不同的Controller。

很快,人们又发现,一个Controller需要的有些子功能还需要其他服务Service的支持。

那么如何把Controller和后台一些服务绑定,这就需要有服务代理Service Broker。

最明显的是数据服务Data Service:

这样,我们把上面的应用,除了Controller之外的路由Router,服务代理Service Broker,引入了Application的体系里面。

其实, Controller还是会有相应的日志输出的,这里用于经常服务日志Log的一个组件就是信息总线Message Bus。

其实在Cloud Foundry里面,一般情况下, Controller通过Message Bus,把状态发给Health Manager,然后由Health Manager把日志信息发给总线的。

这样在CF里面, Health Manager就把状态信息发给总线,而总线会把信息发给Heath Monitor进行展示。

除了上面这些比较集中的功能, CF还提供对用户登录的管理,由两部分组成,登录服务器Login Server 和用户账户认证UAA User Account Authentication。

UAA比较好的解决了浏览器, 用户管理,应用和服务之间一次认证, 全部授权的机制。

其中, OAuth2,SCIM, OpenID等技术还是可以单独深挖的, 就不做讲解了。

这样综合上面三方面的内容,我们可以大致得到CF提供了几大模块,这些模块分成7层模型,路由层routing,用户认证层authentication,应用生命期层app lifecycle,应用存储运行层app storage & execution,服务层 services,信息层messaging,日志和性能仪表层metrics and logging。

他们之间的简单通信,就得到了CF的架构,譬如:

1.UAA Login和CloudController之间。

2.Cloud Controller和Health Manager(HM9000)和NATS Message Bus 和Metrics Controller之间。

3.Cloud Controller和Service Broker之间。

4.另外,运行虚拟机也有细分, DEA Droplet Execution,Agent Warden Server等构成了运行虚拟机作为应用执行环境:

举个PHP应用的例子,我们结合架构图在看一把, DEA里面运行好多节点,每个节点有个PHP的运行,然后由Warden管理这些节点的生命周期,而他们的访问由Router导入访问, Cloud Controller (CC)把状态发给Health Manager (HM9000),而每个Controller要访问的数据库服务有服务代理Broker管理。

1.3 应用执行Go吧Go

其实,在最新的CF架构里面,对执行架构进行了升级,从DEA Droplet Execution Agent架构升级到了Diego架构。 其中最大的升级就是把开发语言从Ruby换成了Go,同时更名了对应的名称。核心的,虚拟机的生命期管理,从Warden变成了Garden; Controller的运行从DEA 节点Node 变成了 Diego Cell; Controller之间的协调器从DEA变成了Diego Brain。如下表所示:

还可以看到原来DEA是和Cloud Controller绑定的,限制Diego和Cloud Controller解耦合了。 这样我们来看一下整个组件有哪些变化:

从上图,我们看到,应用运行从DEA框架换成Diego框架之后, Message Bus 和 Health Manager 也对应进行了变化。直观来说就是把Health Manager的功能进一步独立细分了,把一部分功能独立成信息层的功能了。从Health Manager (HM9000) 变成了 nsync, BBS, 和 Cell Rep 更多组件了。

至此,我们再来详细看一下,前面讲的Controller, Router, Health Manager, Message Bus, Application Execution是如何变化的?

可以看到:

1.Controller不是再和Health Manager联系了,是和nsync进行交互。整个组成Controller API,CAPI模块。

2.Router和Controller也不是和NATS Message Bus交互了,而是用bbs替换了NATS的功能。

3.引入auction机制到Diego Brain来作为协调机制

另外一个不太容易看到的特性是:

4.Warden只能运行Linux容器,而Garden提供了各种操作系统的虚拟机。

综上,我们把Cloud Foundry的架构轻度解释了一遍,这样是为了后面我们把命令行和这些部分对应起来。

2.轻诉命令行

命令行操作的安装就跳过了,可以参考 https://docs.cloudfoundry.org/cf-cli/install-go-cli.html

2.1 登录进入CF

你需要制定API ,然后再login:

你也可以把上面两步,写成一步,给cf login 加一个 -a 参数,之后,你可以把你自己的APP 推Push到云上去。

然后,你可以通过target来指定一个组织Organization和一个空间Space。

当然,cf api 本身如果没有参数的话,就可以作为查询当前API。

登录到空间小结:

2.2 空间Space管理

一般来说你需要注册一个这个组织的用户,然后获得对应Space的全新Permission。一旦进入到Space,你就可以推送APP和创建服务了。

譬如下面定义了一个student1-org的组织,里面有development, production和test 三个空间,每个空间都有apps和services的两大部分。

空间管理小结:

2.3 应用APP管理

首先,你要部署一个APP,通过cf push命令:

创建完成后,一般你需要调整硬盘和内存大小,这时候你需要利用cf scale命令。

另外, 你需要启动,重启,停止app的命令。

当然,万一你忘记了app的名字和相关信息,你还需要查询所有app,和单个app的详细信息。

应用管理小结:

2.4 服务Service管理

在每个Space里面,除了你可以创建管理APP之外,非常类似你可以创建Service。 你可以管理Service,更新和删除。注意这里更新是使用update,而不是scale。你可以绑定或者解绑定某个服务到某个APP。

最后你也可以cf services查询全部服务列表和单个服务的信息。

不过Service和App最大的不同是, App是本地推送上去的。而Service是注册使用的。 CF提供的服务来自Service marketplace,市场。 只有市场上有的服务,你才能创建一个实例。 这样你就要通过cf marketplace来查询有哪些服务可以被创建实例。

理解service命令之后,我们可以将前面提到的Controller的component功能就可以和service broker 链接起来,这里我们可以看一下创建服务之后,查询服务状态的过程中, controller是怎么和service broker进行交互的流程。

服务管理小结

2.5 路由Route管理

路由管理就是把某个域名下,对应的子域名 domain/subdomain (host + domain),或者路径path映射到对应的空间Space,同时还可以指定对应的应用apps和类型type。

譬如我们常用的空间有开发空间,测试空间,和产品空间。 那么一旦创建了这个空间的路由之后,那么对应的访问就会映射到这个空间来。

如果再绑定路由和应用之后,那么就可以根据应用找到对应的controller来处理请求了。 当然也可以删除路由,或者解开对应应用的映射。

也可以查询当前空间下的所有的路由。

路由管理小结:

2.6 域名Domain管理

传统意义上的域名是指DNS的不同级别。

但是这里的域名是指在一个组织org里面全面能够识别的全部域名。

这里域名是对应到组织org的,并且可以创建夸组织的域名。有创建域名,就必然有删除域名。 另外就是查询所有的域名,如下图所示。

域名管理小结:

2.7 环境变量Environment管理

除了上面空间,应用,服务,路由,域名之外。还有很重要求的就是环境变量和日志的管理。

环境变量比较简单,就是创建(set),删除(unset)和查询(list)。

日志有两种,一种是logs,另外一种是events。他们的区别就是logs一般是对某些变量的值进行输出,记录。 而events一般对生命周期的变化进行记录。

环境变量和日志管理小结:

除了上述重要的部署命令(deployment)还有很多管理的命令(admin),详细可以参考:https://docs.cloudfoundry.org/cf-cli/cf-help.html

3 轻诉蓝绿部署

3.1 蓝绿之分

我们知道路由可以随意和应用绑定,解绑定的。这种便利带来了部署上的蓝绿之分。 蓝色是传统的部署方式。就是我们把一个应用创建之后,绑定好了对应的路由和日志,等等。 但是这样,在线操作的时候,有个问题,线上的服务更新的时候,可能需要宕机。

而绿色部署就是先创建了另外一个应有,这是一个更新应有,当我们需要更新,直接把路由改变到新的服务。 然后再停止就的应用。这样就会带来零宕机时间。

举个例子,我们会把需要更新的应用先映射的demo-time-temp的hostname上面去,然后再通过路由切换成demo-time,这样就实现无宕机更替,更为绿色。

有了蓝绿运行方式之后, 我们也很容易想想做A/B Test的时候, 就会变得非常方便。 我们不需要对用户进行区分了, 直接在路由中把部分访问路由到部署的服务, 而不要把原服务停掉。

3.2 运行虚拟之分

其实真正在运行时候,还有一个staging的步骤。就是虚拟机准备好容器开始跑运行程序了。而具体到不同运行环境/容器来staging的时候,又会不一样。

例如利用buildpack和docker。buildpack就需要有metadata和运行文件的准备工作。

如果从DevOps的角度来看Buildpack和容器Container的对比,其实Container就需要开发者也提供。如果我们简单来比较Buildpack和Docker的话:

1. 从上传维护的角度,上传一个containerimage,要比上传一堆代码文件要更为简单。

2. 从配置的角度,由于buildpack和Cloudfoundry结合更为紧密,好多自动化配置做的更为完善,但是docker和Cloudfoundry结合就没有那么精密。

同时buildpack提供部分安全监控的端口,但是docker就没有。

3. 从应用的角度,如果一个独立运行的应用,那么配置好了docker之后,独立运行,会比buildpack更为简单,正如上图所演示的,启动步骤也要少。

但是如果需要部署一个分布式,或者需要同步信息的时候,docker带来的配置就会变得比buildpack麻烦。

4. 从随意迁移的角度, docker可能更为广泛的被应用,Buildpack主要是cloudfoundry在应用。

5. 从类比的角度, buildpack好比修好地面轻轨,什么都自动化好了,你只要应用就好了。 而docker好比开个SUV,就算路面不好,你也能翻山越岭。

6. 从开源的角度,不管是build pack还是docker,都不是一个标准的app容器,只有建立业界容器标准,这样buildpack带来自动化配置的优势,和docker带来的迁移优势就能都有了。但是,这还不在路上...

小结

这样,我们再介绍命令行和运行之后,又对应的介绍了很多Cloud Foundry里面的概念,譬如组织Organization,空间Space,应用App,路由Route,域Domain,服务Service。但是还有很多概念没有介绍, Security Group, Cluster, Manager等等。希望大家在用到时候进一步搞明白。

这样我们从一个web应用出发,说明了Cloud Foundry是如何为这个应用建立需要的环境的。之后,再介绍了部分核心的命令行,与前面说明对应起来。谢谢大家~~~

本文分享自微信公众号 - AI2ML人工智能to机器学习(mloptimization)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-05-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 非均衡数据处理--如何学习?

    Sampling技术比较直观,就是怎么把样本变成均衡的。 我们知道不均衡数据, 最重要的还是收集minority数据。 但是一般这是一个长期的过程。 那么, ...

    史博
  • 机器学习背后的男人们

    在人工智能的大地上, 模式识别和计算统计碰撞出了新的火花, 机器学习。 以数据驱动为出发点的各种学习理论层出不穷: 监督学习、无监督学习、强化学习、深度学习。 ...

    史博
  • 矩阵分解 (加法篇)

    类比的看, 我们知道整数的分解可以利用乘法也可以利用加法。譬如我们玩过的游戏24点, 就是利用加法进行分解和整合。 这种分解很重要的是计算上的便利性!

    史博
  • 网络层路由选择协议(RIP&OSF)

    SuperHeroes
  • 防火墙相关概念讲解

    包过滤是防火墙的基本功能,包过滤防火墙本质上是一个特殊的路由器,通过检查数据的五元组(源IP地址、目的IP地址、协议号、源端口、目的端口)来丢弃一部分网络流量,...

    java达人
  • SAP CRM和Cloud for Customer中的Event handler(事件处理器)

    这些事件处理器实际上就是UI控制器(Controller)上具有特定接口类型的方法。

    Jerry Wang
  • Tungsten Fabric的服务链

    Tungsten Fabric项目是一个开源项目协议,它基于标准协议开发,并且提供网络虚拟化和网络安全所必需的所有组件。项目的组件包括:SDN控制器,虚拟路由器...

    Tungsten Fabric
  • Nginx实战操作-反向代理

    反向代理的核心是不想将我们内部的服务直接暴露给客户端。 Nginx可以作为我们反向代理服务器使用,具体怎么操作呢? 其实nginx反向代理的指令不需要新...

    用户4919348
  • 【DB笔试面试443】PL/SQL中的%ROWTYPE和%TYPE的区别是什么?

    %TYPE是定义一个变量,其数据类型与已经定义的某个数据变量的类型相同,或者与数据库表的某个列的数据类型相同,其使用示例如下所示:

    小麦苗DBA宝典
  • windows7 下,在CMD命令模式下,如何添加永久路由?

    双网卡之间互相访问原理其实很简单,互相设置对方的IP为自己的这张网卡的网关就足够了。为了让机器重启动后依然有效,在使用route 命令添加路由的时候加上 -p ...

    herve

扫码关注云+社区

领取腾讯云代金券