DevOps - Cloud Foundry

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:\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發佈應用的基本過程

  1. 解壓用戶發佈的應用程序壓縮包
  2. 按照指定順序將所有的buildpack與程序包進行匹配,直到找到第一個能夠運行這些代碼的buildpack,並將buildpack解壓
  3. 將解壓後應用程序和buildpack的內容打成一個包(即droplet),將這個包放入在按照指定的運行環境參數生成的容器
  4. 按照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目錄,此目錄下有三個固定文件,分別是:

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

Pivotal kpack - 開源 Kubernetes 原生容器構建服務

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遠程調試

# 檢查空間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>
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章