Cloud Foundry 命令总结

参考一:

1 安装cloudfoundry cli 客户端 

2  带密码等录 
cf login --skip-ssl-validation -a https://api.yourcompany.com -u username -p password 

3  显示组织(org) 
cf orgs 

4  创建组织(org) 
cf create-org ORG_NAME 

5 删除组织(org) 
cf delete-org ORG_NAME 

6 重命名组织(org) 
cf rename-org ORG_NAME 

7 选择组织(org) 
cf target -o ORG_NAME 

8  显示空间(space) 
cf spaces 

9  创建空间(space) 
cf create-space dev 

10 删除空间(space) 
cf delete-space dev 

11 重命名空间(space) 
cf rename-space dev 

12 选择空间(space) 
cf target -s dev 

13 选择组织和空间 
cf target -o ORG_NAME -s SPACE_NAME 

14 创建新用户 
cf  create-user user1@paas.local(用户名)  password(密码) 

15 删除用户 
cf  delete -user user1@paas.local(用户名) 

16 显示当前组织的用户 
cf  org-users 

17  给用户分配组织角色 
cf set-org-role user1@paas.local ORG_NAME  OrgManager 

18  删除用户在组织中的角色 
cf unset -org-role user1@paas.local ORG_NAME  OrgManager 

19 显示服务 
cf m 

20 显示服务实例 
cf services 

20 创建服务 
cf  create-service service_name  service_plan  myservice 

21 删除服务 
cf delete-service  myservice 

21 给应用绑定服务 
cf bind-service myapp   myservice 

22 发布应用 
cf p myapp -i 1 -m 256M -p c:\demo\myapp.war 

23  显示目标空间所有应用 
cf apps 

24  显示应用程序的健康状态 
cf app myapp 

25  改或查看应用程序的实例个数,磁盘空间配额和内存配额 
cf scale myapp -i 2 -m 512M 

26 删除一个应用程序 
cf delete myapp 

27 重命名应用程序 
cf rename  myapp newmyapp 

28 启动应用程序 
cf  start myapp 

29 停止应用程序 
cf stop myapp 

30 重新应用程序 
cf restart  myapp

参考二:

1     CloudFoundry简介
CloudFoundry是VMware旗下子公司Pivotal的一款开源PaaS产品,是一个由多个独立子系统组成的分布式系统,能偶支持多种运行时环境、开发语言、框架及服务,可以构建于IaaS平台之上,也可以直接部署于物理机器上,总共有两个版本分别是V1和V2,V2版本采用的更为成熟的架构思想,引入了如Buildpack、Warden等强大灵活的组件。

Cloud Foundry v1已于2013年1月底停止开发与维护,v2版本主要有以下变化:

1.v1中Router使用的是nginx+lua+ruby server的方式,v2使用了go语言gorouter,据称支持了websocket且极大提升了性能;

  2.v2中Cloud Controller新增了quota、org、space等新的概念,更方便的进行权限和资源管理;

3.v1中为应用打包使用的是Stager组件,v2中移除了该组件,将打包功能加入到DEA中,另外完全重写了Health Manager;

   4.v1里DEA可以独立运行,一个DEA负责的所有app都以子进程的形式挂在DEA主进程下,但v2之后DEA强依赖于Warden提供的安全容器来运行app了。

Cloudfoundry 的部分特色:

1、 基于消息的多组件架构是实现集群的简单、且有效方法。消息可以使集群节点间解耦,使自注册,自发现这些在大规模数据中心中很重要的功能得到实现;

2、 适当的抽象层,模板模式的使用,方便第三方可以方便在CloudFoundry开发扩展功能。CloudFoundry在DEA及Service层都做了抽象层处理,相对应地使开发者可以容易地为CloudFoundry开发Runtime和Service。例如,在CloudFoundry刚推出的时候,只支持Node.js, Java, Ruby,但第三方提供商、开源社区快速跟进,为CloudFoundry添加了PHP, Python的支持。这得益于CloudFoundry精巧的DEA架构设计。

3     CloudFoundry V2 主要名词解释
3.1      CloudController
CC即Could Controller,CloudFoundry V2版本中叫CC_ng,是CloudFoundry的管理模块,主要负责为cf、vmc、sts等客户端提供REST API接口,管理App的整个生命周期的状态及运行环境、日志等,是基于Fog组件规范的接口。

用户通过命令行工具cf与CloudFoundry Server打交道,实际主要就是和Cloud Controller交互。用户把app push给Cloud Controller,Cloud Controller将其存放在Blob Store,在数据库中为该app创建一条记录,存放其meta信息,并且指定一个DEA节点来完成打包动作,产出一个droplet(是一个包含Runtime的包,在任何dea节点都可以通过warden run起来),完成打包之后,droplet回传给Cloud Controller,仍然存放在Blob Store,然后Cloud Controller根据用户要求的实例数目,调度相应的DEA节点部署运行该droplet。另外,Cloud Controller还维护了用户组织关系org、space,以及服务、服务实例等等。

3.2     DEA
DEA组件全称Droplet Execution Agent,相当于部署App应用的容器,用于管理应用实例的整个生命周期,能够与CC组件通讯进行应用实例的启动和停止,在应用实例的整个生命周期中,DEA都会对其保持跟踪监控,并周期性地通过NATS消息组件将应用实例的状态信息进行广播(主要是被Health manager组件接收);最新版本的DEA组件(DEA_next)与老版本的DEA组件相比,优势在于新版本更具模块化,并且测试的覆盖面更广,而且还有一个非常大的改进:依赖Warden组件进行应用实例隔离;DEA中的还有个组件叫Director server,基于Go语言编写,当有请求发起时,DEA响应请求并重定向到director server,在DEA对该URL请求作出处理之前由director server验证其有效性。

DEA,部署在所有物理节点上,管理app实例,将状态信息广播出去。比如我们创建一个app,实例的创建命令最终会下发到DEA,DEA调用warden的接口创建container,如果用户要删除某个app,实例的销毁命令最终也会下发到DEA,DEA调用warden的接口销毁对应的container。

3.3     Warden
Warden是CloudFoundry的一个基础组件,用来在Unix系统环境中构建独立、完全隔离的资源环境,能够对CPU、内存、硬盘资源、网络资源进行控制。

当CloudFoundry刚刚推出的时候,Droplet包含了应用的启动、停止等简单命令。用户应用可以随意访问文件系统,也可以在内网畅通无阻,跑满CPU,占尽内存,写满磁盘,一切可以想到的破坏性操作都可以做到。CloudFoundry显然不会放任这样的情况太久,现在他们开发出了Warden,一个程序运行容器。这个容器提供了一个孤立的环境,Droplet只可以获得受限的CPU,内存,磁盘访问权限,网络权限,再没有办法搞破坏了。

Warden在Linux上的实现是将Linux内核的资源分成若干个namespace加以区分,底层的机制是CGROUP。这样的设计比虚拟机性能好,启动快,也能够获得足够的安全性。在网络方面,每一个Warden实例有一个虚拟网络接口,每个接口有一个IP,而DEA内有一个子网,这些网络接口就连在这个子网上。安全可以通过iptables来保证。在磁盘方面,每个warden实例有一个自己的filesystem。这些filesystem使用aufs实现的。Aufs可以共享warden之间的只读内容,区分只写的内容,提高了磁盘空间的利用率。因为aufs只能在固定大小的文件上读写,所以磁盘也没有出现写满的可能性。

LXC是另一个Linux Container。那为什么不使用它,而开发了Warden呢。因为LXC的实现是和Linux绑死的,CloudFoundry希望warden能运转在各个不同的平台,而不只是Linux。另外Warden提供了一个Daemon和若干Api来操作,LXC提供的是系统工具。还有最重要的一点是LXC过于庞大,Warden只需要其中的一点点功能就可以了,更少的代码便于调试。

3.4      Health Manager
Health Manager最初是用Ruby写的,后来用golang写了一版,称为HM9000,HM9000主要有四个核心功能:

·        监控app的实际运行状态(比如:running, stopped, crashed等等),版本,实例数目等信息。DEA会持续发送心跳包,汇报它所管辖的实例信息,如果某个实例挂了,会立马发送“droplet.exited”消息,HM9000据此更新app的实际运行数据;

·        HM9000通过dump Cloud Controller数据库的方式,获取app的期望状态、版本、实例数目;

·        HM9000持续比对app的实际运行状态和期望状态,如果发现app正在运行的实例数目少于要求的实例数目,就发命令给Cloud Controller,要求启动相应数目的实例。HM9000本身,不会要求DEA做些什么。它只是收集数据,比对,再收集数据,再比对;

·        用户通过cf命令行工具是可以控制app各个实例的启停状态的,如果app的状态发生变化,HM9000就会命令Cloud Controller做出相应调整;

HM9000就是保证app可用性的一个基础组件,app运行时超过了分配的quota,或者异常退出,或者DEA节点整个宕机,HM9000都会检测到,然后命令Cloud Controller做实例迁移。HM9000的代码在这里:https://github.com/cloudfoundry/hm9000

Health Manager模块目前还不是十分完善,但是Cloud Manage栈里面,自动化health管理、分析是一个很重要的领域,而这方面可以扩展的地方也很多,结合Orchestration Engine可以使云自管理、自预警;而与BI方面技术结合,可以统计运营情况,合理分配资源等,这方面CloudFoundry还在发展之中。

3.5      Buildpack
Buildpack通常是ruby工程,由若干ruby脚本和配置文件组成,包含了APP应用部署运行所需要的所有环境,包括语言框架和运行时环境,CloudFoundry原生支持Ruby、Java、Node.js及其主流框架,另外,Heroku等第三方的Buildpack也能部分支持,APP应用上传部署的过程中,CloudFoundry会检测APP配置以确定哪个buildpack能够适用,第三方的开源buildpack需要在部署的时候手动指定:cf push --buildpack URL。

    举例来说,如果把一个php应用放置在某个路径下,然后将apache配置好,最后写一个启动脚本,然后将apache, php应用代码和启动脚本打成一个压缩包。在另外一台环境完全相同的机器上,你只需要下载这个压缩包,解压到对应目录下,然后启动脚本,应用就可以完美的复制到这台机器上。一个打好压缩包就是一个droplet,打压缩包的程序就叫buildpack,打包的过程叫staging。不同的应用类型对应的buildpack代码也不同。如果要增加一门cloudfoundry默认不支持的语言或者应用类型,就需要自定义buildpack。

当前版本默认支持的buildpack有java buildpack、ruby buildpack、nodejs buildpack三种,所以如果增加java、ruby、nodejs应用几乎不用上传这些应用需要的相关环境文件,只需要上传app应用就可以在dea上部署,如果新增的app需要的环境不是上述三种buildpack能够支持的,例如app需要的runtime是pyp,则需要新增一个自定的buildpack。

3.6      Router
V2版本的Router组件改为Gorouter,是基于Go语言编写的,用于CF平台到各组件(如CC,DEA等)的网络路由。Router通过定制实现了对所有连接到Router的网络连接的控制,从而能够更好地支持websocket和其他一些网络协议如HTTP等,所有的路由逻辑都有其独占的进程,减少一些不必要的网络延迟。Gorouter在CF平台上运行时,需要随时通过NATS消息进行更新,默认情况狂下,2分钟未接收到NATS消息,则该route将会被废弃,以释放资源,所以如果需要保存route激活状态的话,最起码得2分钟内对其进行一次更新操作。

Gorouter提供了两个HTTP接口进行监控管理:/varz和/healthz。/routes接口的返回结果是JSON格式的路由表信息,每个Route都有一个对应的接口信息数组。这些接口都要求身份认证,认证信息通过gorouter.yml文件进行配置,其中有端口、用户名、密码等配置项。

Router是整个平台的流量入口,负责分发所有的请求到对应的组件,包括来自外部用户对app的请求和平台内部的管理请求。它在内存中维护了一张路由表,记录了域名与实例的对应关系,所谓的实例自动迁移,靠得就是这张路由表,某实例宕掉了,就从路由表中剔除,新实例创建了,就加入路由表。

CloudFoundry1.0中的router是用nginx+lua嵌入脚本实现的,2.0用golang重写,更名为gorouter,性能有所提升,并声称试图解决websocket请求和tcp请求(虽然这在笔者看来是没用的),它的代码https://github.com/cloudfoundry/gorouter

3.7      UAA
UAA组件全称User Account and Authentication,是基于java语言进行开发,使用Maven进行包管理的一个子项目,主要用于CF平台的身份认证管理,事实上,它并不是CF平台的内部组件,而是一个基于OAuth2和OpenID通用身份认证规范的独立功能组件,可以用于CF平台的身份认证,也可以为其他项目提供SSO单点认证服务。

3.8      Droplet
Droplet---封装包(不好解释,暂且将其中文名称为封装包),是应用程序经过Staging(不好解释,暂且将其中文名称为封装)过程产生的一个可以执行运行的程序包,源于程序,封装后会留有一个端口用于监听HTTP请求,同时包含2个可执行动作:启动、停止,这个包里边会包含以下内容:

应用程序包(APP)
运行环境配置文件
管理控制脚本
3.9      Service Brokers
app在运行的时候通常需要依赖外部的一些服务,比如数据库服务、缓存服务、短信邮件服务等等。Service Broker就是app接入服务的一种方式。比如我们要接入MySQL服务,只要实现CloudFoundry要求的Service Broker API即可。但实际情况是在我们使用CloudFoundry之前,MySQL服务已经由DBA做了服务化、产品化,用起来已经很方便了。有必要实现其Service Broker API,按照CloudFoundry这套规则出牌么?笔者认为没有这个必要。app仍然按照之前访问MySQL服务的方式去做即可,没有任何问题。

3.10  Message Bus
NATS是一个分布式的消息发布和订阅系统,CloudFoundry的各组件之间的通信就是依赖NATS组件。

CloudFoundry使用NATS作为内部组件之间通信的媒介,NATS是一个轻量级的基于pub-sub机制的分布式消息队列系统,是整个系统可以松散耦合的基石。

我们以向router注册路由为例来说明NATS的作用。不管是外部用户对平台上的应用发起的请求,还是对内部组件(比如Cloud Controller、UAA)发起的请求,都是经由router做的转发,要能让router转发则首先需要向router注册路由。大体逻辑实现如下:

·        router启动时,会订阅router.register这个channel,同时也会定时的向router.start这个channel发送数据

·        其他需要向router注册的组件,启动时会订阅router.start这个channel。一旦接收到消息,会立刻收集需要注册的信息(如ip、port等),然后向router.register这个channel发送消息。

·        router接收到router.register消息后立即更新路由信息

·        以上过程不停循环,使router的状态时刻保持最新

3.11  Staging
Staging---封装(不好解释,暂且将其中文名称为封装),是DEA对上传完成的应用程序执行的一系列动作,DEA会按照buildpack中描述的具体要求,获取相关脚本或者其他依赖包,将其组装成为一个可以运行的封装包Droplet。

3.12   Flapping
应用程序(APP)部署或者运行的一种异常状态,表示该APP已经宕机多次无法正常运行或者根本就无法启动。

3.13  Authentication
这块包含两个组件,一个是Login Server,负责登录,一个是OAuth2 Server(UAA),UAA是个Java的项目,如果想找一个OAuth2开源方案,可以尝试一下UAA

3.14  Logging and Statistics
       Metrics Collector会从各个模块收集监控数据,运维工程师可以据此来监控CloudFoundry,出了问题及时发现并处理。物理机的硬件监控则可以采用传统的一些监控系统来做,比如zabbix之类的。

       Log这块是个大话题,CloudFoundry提供了Log Aggregator来收集app的log,我们也可以通过其他手段直接把log通过网络打出来,比如syslog、scribe之类的。

参考三:

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,通过cfpush命令:

 

 

创建完成后,一般你需要调整硬盘和内存大小,这时候你需要利用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等等。希望大家在用到时候进一步搞明白。



参考四:

CF命令行工具

cf version 6.22.2 - https://github.com/cloudfoundry/cli/releases/tag/v6.22.2

生态云应用引擎部署的CloudFoundry版本不是最新的,cf cli建议使用这个版本,更新的版本没有验证过

使用帮助: http://docs.cloudfoundry.org/cf-cli/

访问限制

cf命令行的后端服务器,限制白名单IP访问,请联系生态云管理员进行配置

常用命令

cf login

cf命令行使用独立的用户名和密码,请联系生态云管理员创建用户

cf login -a <cf-api-server> -u <user-name>
cf-api-server 地址
金山云-北京6https://api.mi-ae.net
AWS-北京https://api.mi-ae.cn
AWS-Oregonhttps://api.mi-ae.com
AWS-Singaporehttps://api.mi-ae.com.sg
AWS-Frankfurthttps://api.mi-ae.com.de

cf passwd

第一次使用cf login登录后,请使用cf passwd重置密码

cf target

运行大部分命令前,需要先设定目标org和space

cf target -o <org-name> -s <space-name>

app相关

cf apps : 列出当前space下所有的app

cf app :列出app的详细信息

获取JSON格式信息

获取org信息(guid)

cf curl /v2/organizations?q=name%3A<org-name>

获取space信息

cf curl /v2/organizations/<org-guid>/spaces

获取某space所有的app信息

cf curl /v2/spaces/<space-guid>/summary

获取某app各实例的cpu和内存指标

cf curl /v2/apps/<app-guid>/stats

ssh到应用的某个实例

cf ssh --help

其他命令

cf help -a

 

 

 

 

  • 0
    点赞
  • 7
    收藏
  • 4
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论 4
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值