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端技術

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。