DevOps - Cloud Foundry

时间 2020-08-22

标签 devops cloud foundry 栏目云服务繁體版

原文原文链接

1 - 一些概念

云服务抽象层次分为3层：基础架构即服务（IaaS），平台即服务（PaaS）和软件即服务（SaaS）。php

IaaS 为用户提供构建和部署应用程序所需的基本基础架构。
PaaS 提供更高级别的抽象，所以用户不会暴露于OS，中间件或运行时，只须要关注本身的应用程序和数据
SaaS 由第三方平台构建和托管的应用程序，并经过互联网提供给用户

1.1 CF(Cloud Foundry)

Cloud Foundry是基于容器技术的一套开源云应用平台，适合于私有云、公有云和混合云部署。html

独立于云的开源平台即服务（PaaS）
提供了一整套云环境、开发框架和配套的应用支持服务，方便用户快速、便利地进行应用的开发、测试、部署和扩容。
商业版本的Cloud Foundry，如 IBM Bluemix和Pivotal Cloud Foundry（简称PCF），都是基于开源的Cloud Foundry 项目开发的。
https://www.cloudfoundry.org/
https://github.com/cloudfoundry
https://cloudfoundry.cn/

1.2 CF优点

结构化平台前端

包含开发云软件的最佳实践
经证实能够有效运做
采用标准程序（例如服务绑定）下降复杂性
执行部署和应用管理的预约义程序来减小工做量

简单快速的应用开发，专一于业务逻辑java

无需考虑底层基础架构、操做系统和运行系统
可扩展、负载均衡、健康管理和配置管理提供开箱即用支持
应用在隔离的容器化环境中运行

1.3 CF特色

# 快速发布
整个Cloud Foundry最核心的一条命令就是CF push。
但在简单部署的背后，Cloud Foundry平台实现了从运行时环境buildpack的准备、应用镜像droplet的打包、软件包的二进制存储、准发布环境staging测试、应用软件部署、日志和监控保护、服务弹性和伸缩等核心功能。
    
# 多语言支持
几乎全部常见的语言都有默认的运行时环境（runtime buildpack）支持，包含Java、Node.js、Go、Python、PHP、Ruby、.NET等。
    
# 网络和路由绑定
经过路由（Routing）和应用执行层（Application Execution）的配合，能够很方便地实现内部、外部路由解析和数据通讯。
    
# 用户和认证
用户和认证是PaaS平台的主要功能之一，可是在容器平台（如Docker）和容器编排平台（如Kubenetes）并无给予很强的管理和集成。
这也是Cloud Foundry做为开源云应用平台的优点所在。
    
# 日志和监控
Cloud Foundry经过消息（Messaging）和日志（Logging）模块实现基本的日志管理。
它能够经过在平台里添加砖块（Tile）的方式，很天然地对接主流的监控平台（Splunk、LogStash、NewRelic、Datadog、Dynatrace等）
    
# 第三方支持
当前有近200个主流商业或开源产品对Cloud Foundry平台提供了第三方服务集成支持，从前端web服务到后端数据库服务，从云平台功能到大数据，不一而足。
对接过程相似于apple store和google play的市场化模块管理，用户能够从本地市场中选择须要的服务集成到各自的应用中。

2 - PCF(Pivotal Cloud Foundry)

Pivotal公司推出的商业版本Cloud Foundry, 简称为PCF, 提供了开放软件产品中未包含的用于安装和管理的额外工具。
PCF是云原生应用程序开发的高级抽象, 也就是说Pivotal公司在开源Cloud Foundry基础上扩充了一些商业功能。
给PCF一个应用程序，平台能够完成从理解应用程序依赖性到容器构建和扩展以及链接网络和路由的全部工做。node

BOSH

BOSH工具来负责部署和生命周期管理，一般会负责搭建一个CF的环境，而且它经过CPI（Cloud Provider Interface）的机制屏蔽了底层基础设施的差别。
假设“想要一个虚拟机”，这时CPI会将这个请求转换成适用于不一样底层基础设施提供商的API调用，好比AWS，IBM，Google或者VMWare等等。
用户还能够直接调用BOSH，为其建立Cloud Foundry Application Runtime（CFAR）和Cloud Foundry Container Runtime（CFCR）、Cloud Provider Interface（CPI）的工做负载。
其中，CFCR是Cloud Foundry Foundation基于Kubernetes和BOSH开发和维护的支持容器架构的核心组件。python

PCF-dev

Pivotal为PCF的应用开发人员准备的一款App单虚拟机版的CloudFoundry, 包含了cloud foundry完整的技术栈
https://docs.pivotal.io/pcf-dev/mysql

3 - PWS（Pivotal Web Services ）

Pivotal 基于CF发布商业化版本PCF，而且将 PCF 部署到AWS 上作为一个参考实现，这就是 PWS（Pivotal Web Services ）。
https://run.pivotal.io/linux

4 - CF命令

CF是用于与 Cloud Foundry 进行交互的命令行工具。
Cloud Foundry使用Cloud Foundry命令行界面（CF CLI）将应用程序部署到云。
在manifest.yml文件中设置应用程序部署参数。
可使用Cloud Foundry中的一些内置构建包（buildpack，应用程序的框架和运行时支持）来部署应用程序。
参考：http://cli.cloudfoundry.org/zh-Hans/cf/nginx

经常使用命令git

# 命令帮助
cf --help

# 登陆
cf login https://apps.sys.sea.preview.pcf.manulife.com 

# 退出登陆
cf logout

# 进行发布
cf push gwdemo -p D:\wars\appSimulation.war

# 经过target指定一个组织Organization和一个空间Space
cf target -o ORG_NAME -s SPACE_NAME 

#  查看或设置目标 API URL
- 查看：cf api
- 设置：cf api [URL]

# 查看日志
- 跟踪日志：cf logs APP_NAME
- 显示最近的日志：cf logs APP_NAME --recent
- 保存为文件：cf logs APP_NAME > APP_NAME.log

# 查看应用
- 查看当前 space 下全部的 application：cf apps    
- 查看当前 space 下指定的 application：cf app APP_NAME

# 删除应用
cf delete APP_NAME

# 重命名应用
cf rename APP_NAME NEW_APP_NAME

# 查看变量
cf env APP_NAME

# 查看服务
- 列出目标空间中的全部服务实例：cf services
- 显示服务实例信息：cf service SERVICE_INSTANCE

5 - Buildpacks

Buildpack是Cloud Foundry部署过程链中的核心连接，能够自动检测应用程序框架，应用程序编译和运行。

可插入的、模块化的工具，经过提供比Dockerfile更高级别的抽象，将源代码转换为容器就绪的构件。
提供了一种控制的平衡，最小化了最初的生产时间，减小了开发者的操做负担，并支持大规模管理应用程序的企业运营商。

大多开发者以写一个dockerfile 来使用Docker，这个file会定义整个生成Docker image的build流程，将服务项目以一个Docker Container来发布。
利用一个Dockerfile在生产环境运行一个应用，每每须要从一个基本的image开始，而后再将其余额外须要的包加入进来。
在这个过程当中，整个image会充满不少非相关的缓存文件夹，若是想去掉这些文件来缩减整个image大小，但只会对本地有序性build有用。
使用Dockerfile来rebuild就会要把整个image从新build，并不能适当利用那些缓存目录，在速度上存在短板。
此外，当使用Dockerfile构建应用时的还可能存在其余的挑战和难点，例如定制化dockerfile的建立与维护、基础image的变动与设置，
简而言之，必须对具体应用和底层机制有适当的了解，才可以让编写出的Dockerfile产生适用的image来兼容之后的更新与依赖变更，避免产生不匹配的现象。
也就是说，Dockerfile将运行和应用的关注点混合在了一块儿，对于专一功能实现的开发者其实是一个体验很是差的工具。

Buildpacks正是一种能够减小此类复杂度的替代办法，一种不再须要dockerfile并将源代码转换为Docker Image的标准。
一个 buildpack可以以识别应用代码语言的行为惯例，自动收集依赖（retrieve dependencies），运行数据信息，清理缓存，而且给编译应用语言代码。
Buildpack帮助paas平台完成了一个app在部署层面的抽象，主要搞定应用依赖的runtime和framework。
简而言之，Builpacks的设计原则就是最大程度简化所须要的依赖安装和环境设置，以达到快速稳定运行应用的目的，让开发者能够更加注重应用，而不是拼凑一个build管道。

6 - 云原生Buildpacks（CNB）

Cloud Native Buildpacks ：https://buildpacks.io/
Buildpacks最先是由Heroku在2011年构想的，此后被Cloud Foundry，以及Gitlab、Knative、Dokku和Drie等所采用。
基于从Pivotal和Salesforce Heroku维护产品级构建包（buildpacks）的经验，CNB被构建为提供一个平台到构建包的API契约，该契约获取源代码并输出Docker镜像，这些镜像能够在支持OCI镜像的云平台上运行。
云原生Buildpacks（CNB）将 Buildpacks 的简洁性和可用性与container的优点结合，能够产出一个 “开放容器计划”兼容（OCI-Compliant）image, 而且这个image可使用现存的Docker工具，以及更广阔的现存容器生态系统。

网站/代码：
https://buildpacks.io/
https://github.com/buildpack

文档：
https://buildpacks.io/#get-started
https://github.com/buildpack/resources

错误和功能请求：
https://github.com/buildpack/spec/issues

7 - Cloud Foundry 中的 Buildpacks

https://docs.cloudfoundry.org/buildpacks/
BuildDacks在Cloud Foundry中做用与功能

检测应用程序的编程语言
安装应用程序所需的依赖项
必要时编译应用程序
为Cloud Foundry提供应用程序配置数据。
虽然每一个buildpack一般都针对一种编程语言及其相应的构建工具，但在推送应用时能够不用指定buildpack，Cloud Foundry支持自动构建包检测。

7.1 CF发布应用的基本过程

解压用户发布的应用程序压缩包
按照指定顺序将全部的buildpack与程序包进行匹配，直到找到第一个可以运行这些代码的buildpack，并将buildpack解压
将解压后应用程序和buildpack的内容打成一个包（即droplet），将这个包放入在按照指定的运行环境参数生成的容器
按照buildpack指定的启动命令，启动应用

在上面的过程当中，buildpack实现了三步功能：

第一步，detect：
虽然每一个buildpack一般都针对一种编程语言及其相应的构建工具，但在推送应用时能够不用指定buildpack，Cloud Foundry支持自动构建包检测。 
每一个构建包都有一个检测步骤来识别是否可使用该构建包构建应用程序。 
检测步骤查找特定的文件或目录，若是找到这些项目，那么该构建包将用于构建您的应用程序。
Cloud Foundry按照指定buildpack顺序检测，当第一个buildpack能够打包应用程序时，将再也不尝试其余的buildpack。
 常见的作法是将最经常使用的buildpacks的position设为靠前的位置。

第二步，compile：
实际构建应用程序，将应用程序包与buildpack包结合。
该构建过程将为对应的语言运行通用包管理器，确保构建过程是同样的，可以在相同的环境中运行。
下载buildpacks和app buildpack缓存，并使用buildpack来编译，而后把app文件和运行时依赖以及启停脚本一块儿打包，生成的包称为droplet。
打包完成以后，将存储droplet到BlobStore中，并上传buildpack cache到BlobStor，便于下次使用。

第三步，release：
将droplet复制到应用程序容器中，droplet被解包，运行启动应用程序的命令。 
若是想建立更多的应用程序实例，那么在这些新应用程序容器上使用相同的droplet。

7.2 buildpack目录

任何一个buildpack都有一个bin路径，放着三个指定名字（detect、compile、release）的脚本对应着功能实现
buildpack工做在CloudFoundry框架下的，根据CloudFoundry要求，buildpack至少含有一个bin目录，此目录下有三个固定文件，分别是：

detect # 侦测项目类别等相关信息
compile # buildpack的核心文件，拉取相应的Runtime下并配置放到指定位置，拉取相应的Framework并配置到指定位置
release # 输出一个yaml，描述如何启动应用
三个脚本由CloudFoundry顺次执行
Java-buildpack的bin目录示例： https://github.com/cloudfoundry/java-buildpack/tree/master/bin
nodejs-buildpack的bin目录示例：https://github.com/cloudfoundry/nodejs-buildpack/tree/master/bin

7.3 流程与步骤

https://docs.cloudfoundry.org/concepts/how-applications-are-staged.html
How Diego Stages Buildpack Apps

一、用户在命令行下进入app所在的目录，运行cf push，表示要上传应用

二、cf命令行工具发请求给CCNG，为新应用建立一个记录

三、
CCNG保存应用的元数据，包括名称、实例数、buildpack和其余信息等
CCNG管辖两个存储，一个是CCDB（RDBMS，能够用mysql），另外一个是BlobStore，存储一些大的二进制文件，好比用户要push的app和最后打包成的droplet

四、cf命令行工具从CCNG请求匹配的资源，并上传资源缓存中不存在的app源文件，CCNG合并这些文件建立app包

五、CCNG把建立的app包放在BlobStore

六、cf命令行工具发起start app指令

七、
CCNG接收到cf命令行给的start指令，可是此时app文件仅仅包含了应用逻辑代码，没有运行时环境的支持，没有启停脚本等，无法直接run。
CCNG向Diego发起staging请求，Diego安排一个Diego Cell运行staging任务，下载buildpacks和app buildpack缓存，并使用buildpack来编译和stage这个app。
stage就是把用户的app文件和运行时依赖以及启停脚本一块儿打包的过程，生成的包称为droplet。

八、Diego Cell能够在执行staging过程当中同步显示输出，便于开发人员进行此阶段的故障处理。

九、打包完成以后，Diego Cell将存储droplet到CCNG的BlobStore中，并上传buildpack cache到BlobStor，便于下次使用。

十、
Diego Bulletin Board System (BBS)报告给CCNG，表示已完成stage。
Staging应该在15分钟内完成，不然会失败。

十一、CCNG读取meta信息而后选取一个或多个相应的Diego Cell来部署droplet。

十二、Diego Cells汇报app的状态给CCNG，并最终反映到终端用户控制台。

How Diego Stages Docker Images

7.4 构建包类型

System Buildpacks（系统构建包）
https://docs.cloudfoundry.org/buildpacks/#system-buildpacks
Cloud Foundry有可用于经常使用的语言（如Go，Java，Ruby和Python）的构建包，称为System Buildpacks（系统构建包）。
系统构建包由Cloud Foundry开源社区的成员和提供生产质量托管的公司维护。

Community Buildpacks（社区构建包）
https://docs.cloudfoundry.org/buildpacks/#community-buildpacks

Customizing and Developing Buildpacks
https://docs.cloudfoundry.org/buildpacks/developing-buildpacks.html
可使用cf CLI直接使用构建包，默认值已经涵盖了大多数常见的用例。
能够在本身的正在运行的Cloud Foundry添加缺乏的构建包（需具有相应的使用权限），例如社区构建包或本身的自定义构建包

7.5 一些命令

# How do I add a buildpack to my CF environment?
$ cf create-buildpack some-build-pack-name /path/to/buildpack.zip 10

# How do I change the position of an existing buildpack?
$ cf update-buildpack some-buildpack-name -i

# How do I lock a buildpack to prevent updates?
$ cf update-buildpack some-buildpack-name --lock

# How do I unlock a buildpack to allow updates?
$ cf update-buildpack some-buildpack-name --unlock

# How do I rename a buildpack?
$ cf rename-buildpack some-buildpack- name some-new-buildpack-name

# How do I delete a buildpack?
$ cf delete-buildpack some-buildpack-name

8 - Pivotal Cloud Foundry - Buildpacks

Buildpacks ： https://docs.run.pivotal.io/buildpacks/
Customizing and Developing Buildpacks ： https://docs.run.pivotal.io/buildpacks/developing-buildpacks.html
Packaging Dependencies for Offline Buildpacks ： https://docs.run.pivotal.io/buildpacks/depend-pkg-offline.html

Pivotal kpack - 开源 Kubernetes 原生容器构建服务

https://github.com/pivotal/kpack
https://tanzu.vmware.com/content/blog/introducing-kpack-a-kubernetes-native-container-build-service
Pivotal 开源 Kubernetes 原生容器构建服务 kpack ： https://www.infoq.cn/article/rotUZxgljYWNdGRhDAo1

9 - Sample - PCF buildpacks

λ cf buildpacks
Getting buildpacks...

buildpack                        position   enabled   locked   filename                                                         stack
hwc_buildpack                    1          true      false    hwc_buildpack-cached-windows-v3.1.10.zip                         windows
hwc_buildpack                    2          true      false    hwc_buildpack-cached-windows2016-v3.1.10.zip                     windows2016
hwc_buildpack                    3          true      false    hwc_buildpack-cached-windows2012R2-v3.1.10.zip                   windows2012R2
binary_buildpack                 4          true      false    binary_buildpack-cached-windows2012R2-v1.0.36.zip                windows2012R2
binary_buildpack                 5          true      false    binary_buildpack-cached-windows2016-v1.0.36.zip                  windows2016
staticfile_buildpack             6          true      false    staticfile_buildpack-cached-cflinuxfs3-v1.5.3.zip                cflinuxfs3
java_buildpack_offline           7          true      false    java-buildpack-offline-cflinuxfs3-v4.26.zip                      cflinuxfs3
ruby_buildpack                   8          true      false    ruby_buildpack-cached-cflinuxfs3-v1.8.6.zip                      cflinuxfs3
nodejs_buildpack                 9          true      false    nodejs_buildpack-cached-cflinuxfs3-v1.7.8.zip                    cflinuxfs3
go_buildpack                     10         true      false    go_buildpack-cached-cflinuxfs3-v1.9.4.zip                        cflinuxfs3
python_buildpack                 11         true      false    python_buildpack-cached-cflinuxfs3-v1.7.5.zip                    cflinuxfs3
php_buildpack                    12         true      false    php_buildpack-cached-cflinuxfs3-v4.4.5.zip                       cflinuxfs3
dotnet_core_buildpack            13         true      false    dotnet-core_buildpack-cached-cflinuxfs3-v2.3.3.zip               cflinuxfs3
dotnet_core_buildpack2210        14         true      false    dotnet-core_buildpack-cached-cflinuxfs3-v2.2.10+1556033874.zip   cflinuxfs3
binary_buildpack                 15         true      false    binary_buildpack-cached-cflinuxfs3-v1.0.36.zip                   cflinuxfs3
nr_dotnetcore_extension          16         true      false    newrelic_dotnetcore_extension_buildpack-v1.1.1.zip
nr_dotnetcore_extension_cached   17         true      false    newrelic_dotnetcore_extension_buildpack-cached-v1.1.1.zip
nr_hwc_extension                 18         true      false    newrelic_hwc_extension_buildpack-v1.1.1.zip
nr_hwc_extension_cached          19         true      false    newrelic_hwc_extension_buildpack-cached-v1.1.1.zip
nodejs_buildpack1643             20         true      false    nodejs_buildpack-cached-cflinuxfs3-v1.6.43+1549397317.zip        cflinuxfs3
nodejs_buildpack1644             21         true      false    nodejs_buildpack-cached-cflinuxfs3-v1.6.44+1550604789.zip        cflinuxfs3
staticfile_buildpack             22         true      false    staticfile_buildpack-cached-cflinuxfs2-v1.4.43.zip               cflinuxfs2
java_buildpack_offline           23         true      false    java-buildpack-offline-cflinuxfs2-v4.20.zip                      cflinuxfs2
ruby_buildpack                   24         true      false    ruby_buildpack-cached-cflinuxfs2-v1.7.42.zip                     cflinuxfs2
nodejs_buildpack                 25         true      false    nodejs_buildpack-cached-cflinuxfs2-v1.6.52.zip                   cflinuxfs2
nodejs_buildpack174              26         true      false    nodejs_buildpack-cached-cflinuxfs3-v1.7.4+1574351480.zip         cflinuxfs3
go_buildpack                     27         true      false    go_buildpack-cached-cflinuxfs2-v1.8.42.zip                       cflinuxfs2
python_buildpack                 28         true      false    python_buildpack-cached-cflinuxfs2-v1.6.36.zip                   cflinuxfs2
php_buildpack                    29         true      false    php_buildpack-cached-cflinuxfs2-v4.3.78.zip                      cflinuxfs2
dotnet_core_buildpack            30         true      false    dotnet-core_buildpack-cached-cflinuxfs2-v2.2.12.zip              cflinuxfs2
binary_buildpack                 31         true      false    binary_buildpack-cached-cflinuxfs2-v1.0.33.zip                   cflinuxfs2
ruby_buildpack1742               32         true      false    ruby_buildpack-cached-cflinuxfs3-v1.7.42+1563295089.zip          cflinuxfs3
ruby_buildpack1740               33         true      false    ruby_buildpack-cached-cflinuxfs3-v1.7.40+1559744133.zip          cflinuxfs3
binary_buildpack                 34         true      false    binary_buildpack-cached-windows-v1.0.36.zip                      windows
nginx_buildpack                  35         true      false    nginx_buildpack-cached-cflinuxfs3-v1.1.3.zip                     cflinuxfs3
r_buildpack                      36         true      false    r_buildpack-cached-cflinuxfs3-v1.1.1.zip                         cflinuxfs3
GuowangLi@CHN-L-GuowangLi /x
λ 
GuowangLi@CHN-L-GuowangLi /x
λ cf events release-mgt-guowang
Getting events for app release-mgt-guowang in org ASIAREGIONAL-SEA-DEV / space CD-COMMON as guowangli...

time                          event                      actor
                description
2020-03-15T21:06:01.00+0800   audit.app.droplet.create   epipe_cd-common_release-mgt-pipeline_deploydev_ugizoo_554006_ep@mfcgd.com
2020-03-15T21:00:58.00+0800   audit.app.update           epipe_cd-common_release-mgt-pipeline_deploydev_ugizoo_554006_ep@mfcgd.com   state: STARTED
2020-03-15T21:00:57.00+0800   audit.app.build.create     epipe_cd-common_release-mgt-pipeline_deploydev_ugizoo_554006_ep@mfcgd.com
2020-03-15T21:00:43.00+0800   audit.app.upload-bits      epipe_cd-common_release-mgt-pipeline_deploydev_ugizoo_554006_ep@mfcgd.com
2020-03-15T21:00:37.00+0800   audit.app.update           epipe_cd-common_release-mgt-pipeline_deploydev_ugizoo_554006_ep@mfcgd.com
2020-03-15T21:00:37.00+0800   audit.app.map-route        epipe_cd-common_release-mgt-pipeline_deploydev_ugizoo_554006_ep@mfcgd.com
2020-03-15T21:00:33.00+0800   audit.app.create           epipe_cd-common_release-mgt-pipeline_deploydev_ugizoo_554006_ep@mfcgd.com   disk_quota: 2048, instances: 1, memory: 2048, state: STOPPED, command: [PRIVATE DATA HIDDEN], environment_json: [PRIVATE DATA HIDDEN]
GuowangLi@CHN-L-GuowangLi /x
λ

10 - CF与Kubernetes的区别

Cloud Foundry和 Kubernetes 的区别： http://www.javashuo.com/article/p-zkyzypgk-hc.html
从开发者的角度比较Kubernetes和Cloud Foundry: http://dockone.io/article/5679
能够极其粗略地将PCF理解为是“应用程序”PaaS的一个示例，称为Cloud Foundry Application Runtime，而Kubernetes是“容器”PaaS（有时称为CaaS）。
虽然Pivotal Cloud Foundry和Kubernetes共享许多相似的功能，如容器化，命名空间和身份验证，但它们部署云原生应用程序的总体方法差异很大。
“应用程序”PaaS：在应用程序级别拥有平台抽象，构建和部署彻底配置的应用程序
“容器”PaaS：在容器级别拥有平台抽象，构建和部署容器做为完整的部分应用

11 - 参考信息

## 背景
为何说 2019，是属于容器技术的时代？：https://www.infoq.cn/article/R1p3H3_29f4TYImExsyw
技术标准化—纷繁复杂趋势背后的规律： https://www.infoq.cn/article/0dDgKoABgu6ph6ud3AwP

## 命令行
cloudfoundry经常使用命令 ： https://www.cnblogs.com/fengtc/p/5288402.html
轻度解释Cloud Foundry命令行 ： https://www.jianshu.com/p/101235edcb4e

## 部署
基于Cloud Foundry平台部署nodejs项目上线:  https://www.cnblogs.com/gaojun/p/4153965.html
Pivotal：15分钟部署你的应用:  https://www.jianshu.com/p/515faf6bd5e5

## Buildpacks
Buildpacks项目简介：https://cloud.tencent.com/developer/article/1549909
CNCF公告：https://www.cncf.io/blog/2018/10/03/cncf-to-host-cloud-native-buildpacks-in-the-sandbox/
Buildpacks 进入 CNCF 沙箱：https://cloud.tencent.com/developer/article/1469643
CloudFoundry-Offline-BuildPack  ： https://blog.csdn.net/zhaozhenyang_go/article/details/27331813
Cloud Foundry buildpack开发部署实例解析 : https://blog.csdn.net/cloudguru/article/details/45026873
Cloud Foundry v2 部署及入门运维: https://blog.csdn.net/yangcs2009/article/details/38320353
CloudFoundry中buildpack介绍与自定义实践:  https://blog.csdn.net/ulricqin/article/details/84504957

## MindSphere 的 Cloud Foundry
https://developer.mindsphere.io/zh/paas/index.html
https://developer.mindsphere.io/zh/howto/index.html

## Cloud Foundry 开发者认证和培训计划
https://www.infoq.cn/article/2017/05/cloud-foundry-certification
https://cloudfoundry.cn/training/
Cloudfoundry部署实践视频课程： https://edu.51cto.com/course/8696.html

SSH远程调试

# 检查空间SSH是否开启
cf space-ssh-allowed <space-name>
# 启用指定空间SSH权限（默认开启）
cf allow-space-ssh <space-name>
# 查看应用的ssh标志位
cf ssh-enabled <app-name>
# 打开应用的ssh标志位（
# 不然使用cf ssh时可能会出现报错：ssh: unable to authenticate, attempted methods [none password], no supported methods remain
cf enable-ssh <app-name>
# 重启应用
cf restart <app-name>
# SSH进入应用空间
cf ssh <app-name>
# SSH远程登陆到运行在CloudFoundry环境下的应用，并映射端口到本地
cf ssh -N -T -L <app-port>:127.0.0.1:<local-port> <app-name>

1. Cloud Foundry 概述
2. Cloud Foundry 组件
3. Cloud foundry基础
4. 深入Cloud Foundry [转]
5. 深入 Cloud Foundry（上）
6. Cloud Foundry——Azure杀手?
7. Cloud Foundry BOSH 简介
8. JasperReports Server on Cloud Foundry
9. Cloud Foundry和 Kubernetes 的区别
10. Cloud Foundry 第一个程序
更多相关文章...
• RSS 元素 - RSS 教程
• Docker 教程 - Docker教程
• Spring Cloud 微服务实战(三) - 服务注册与发现
• Docker容器实战(一) - 封神Server端技术