1 - 一些概念
云服务抽象层次分为3层：基础架构即服务（IaaS），平台即服务（PaaS）和软件即服务（SaaS）。
- IaaS 为用户提供构建和部署应用程序所需的基本基础架构。
- PaaS 提供更高级别的抽象，因此用户不会暴露于OS，中间件或运行时，只需要关注自己的应用程序和数据
- SaaS 由第三方平台构建和托管的应用程序，并通过互联网提供给用户
1.1 CF(Cloud Foundry)
Cloud Foundry是基于容器技术的一套开源云应用平台，适合于私有云、公有云和混合云部署。
- 独立于云的开源平台即服务（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优势
结构化平台
- 包含开发云软件的最佳实践
- 经证明可以有效运作
- 采用标准程序（例如服务绑定）降低复杂性
- 执行部署和应用管理的预定义程序来减少工作量
简单快速的应用开发，专注于业务逻辑
- 无需考虑底层基础架构、操作系统和运行系统
- 可扩展、负载均衡、健康管理和配置管理提供开箱即用支持
- 应用在隔离的容器化环境中运行
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一个应用程序，平台可以完成从理解应用程序依赖性到容器构建和扩展以及连接网络和路由的所有工作。
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开发和维护的支持容器架构的核心组件。
PCF-dev
Pivotal为PCF的应用开发人员准备的一款App单虚拟机版的CloudFoundry, 包含了cloud foundry完整的技术栈
https://docs.pivotal.io/pcf-dev/
3 - PWS（Pivotal Web Services ）
Pivotal 基于CF发布商业化版本PCF，并且将 PCF 部署到AWS 上做为一个参考实现，这就是 PWS（Pivotal Web Services ）。
https://run.pivotal.io/
4 - CF命令
CF是用于与 Cloud Foundry 进行交互的命令行工具。
Cloud Foundry使用Cloud Foundry命令行界面（CF CLI）将应用程序部署到云。
在manifest.yml文件中设置应用程序部署参数。
可以使用Cloud Foundry中的一些内置构建包（buildpack，应用程序的框架和运行时支持）来部署应用程序。
参考 ：http://cli.cloudfoundry.org/zh-Hans/cf/
常用命令
# 命令帮助
cf --help
# 登录
cf login https://apps.sys.sea.preview.pcf.manulife.com
# 退出登录
cf logout
# 进行发布
cf push gwdemo -p D:warsappSimulation.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
1、用户在命令行下进入app所在的目录，运行cf push，表示要上传应用
2、cf命令行工具发请求给CCNG，为新应用创建一个记录
3、
CCNG保存应用的元数据，包括名称、实例数、buildpack和其他信息等
CCNG管辖两个存储，一个是CCDB（RDBMS，可以用mysql），另一个是BlobStore，存储一些大的二进制文件，比如用户要push的app和最后打包成的droplet
4、cf命令行工具从CCNG请求匹配的资源，并上传资源缓存中不存在的app源文件，CCNG合并这些文件创建app包
5、CCNG把创建的app包放在BlobStore
6、cf命令行工具发起start app指令
7、
CCNG接收到cf命令行给的start指令，但是此时app文件仅仅包含了应用逻辑代码，没有运行时环境的支持，没有启停脚本等，没法直接run。
CCNG向Diego发起staging请求，Diego安排一个Diego Cell运行staging任务，下载buildpacks和app buildpack缓存，并使用buildpack来编译和stage这个app。
stage就是把用户的app文件和运行时依赖以及启停脚本一起打包的过程，生成的包称为droplet。
8、Diego Cell可以在执行staging过程中同步显示输出，便于开发人员进行此阶段的故障处理。
9、打包完成之后，Diego Cell将存储droplet到CCNG的BlobStore中，并上传buildpack cache到BlobStor，便于下次使用。
10、
Diego Bulletin Board System (BBS)报告给CCNG，表示已完成stage。
Staging应该在15分钟内完成，否则会失败。
11、CCNG读取meta信息然后选取一个或多个相应的Diego Cell来部署droplet。
12、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 的区别 ： https://blog.csdn.net/qq_30154571/article/details/84955097
- 从开发者的角度比较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远程调试
- https://developer.mindsphere.io/zh/paas/paas-cloudfoundry-ssh.html
- https://yq.aliyun.com/articles/704309
- https://yq.aliyun.com/articles/704310
# 检查空间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>