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	地址
金山云-北京6	https://api.mi-ae.net
AWS-北京	https://api.mi-ae.cn
AWS-Oregon	https://api.mi-ae.com
AWS-Singapore	https://api.mi-ae.com.sg
AWS-Frankfurt	https://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