SAP云平臺Cockpit聽起來像是某個深藏在后臺的管理頁面但實際上它是使用SAP云平臺時繞不開的入口。Cockpit既能看到子賬戶有哪些資源也能完成權限分配、服務訂閱、空間管理、目的地配置等一整套云上運維動作。很多剛接觸的人第一次登錄后被左側一長串菜單搞得發(fā)懵子賬戶、空間、服務市場、Boosters這些詞全部堆在眼前完全不知道該先點哪個。這篇文章就圍繞SAP云平臺Cockpit的日常用法按照“賬戶模型-高頻操作-排障思路”這條線展開盡量把每一步背后的原因也講清楚適合已經(jīng)創(chuàng)建了試用賬戶、但不太清楚下一步該做什么的開發(fā)者也適合剛接手平臺管理工作、需要快速上手的運維同學。1. 先認清Cockpit在整套體系里的角色1.1 控制臺不是多出來的一個頁面Cockpit本質上就是SAP云平臺的統(tǒng)一管理前端。它背后不是一堆孤立的報表而是一整套賬戶和資源的管理邏輯。我剛開始接觸時犯過一個典型錯誤直接沖到Service Marketplace里訂閱各種服務卻完全忽略了這些服務必須掛在某個子賬戶下而子賬戶需要先獲得配額兩件事缺一不可。結果服務列表里明明有東西可選真正創(chuàng)建實例時卻一直提示配額不足浪費了不少時間。如果你把Cockpit當成一個日常操作臺就很好理解了。所有跟云平臺相關的“管理類操作”比如建子賬戶、給用戶授權、訂閱服務、配置連接都會在這里發(fā)生。至于應用本身跑在哪里、代碼日志怎么查那是運行時環(huán)境的事不在Cockpit的直接操作范圍內。很多初學者把這兩層混在一起以為在Cockpit里能看到所有應用的代碼級日志其實不是。1.2 登錄入口與區(qū)域選擇訪問Cockpit一般是通過你所處區(qū)域對應的平臺站點進入比如歐洲區(qū)域、美國區(qū)域各有各自的入口。登錄時使用的是平臺賬號而不是某個單應用的賬號。如果公司內沒有統(tǒng)一分配賬號也可以注冊試用賬號體驗試用賬號登錄后的界面和正式環(huán)境基本一致只是配額有限。第一次進入的時候大概率會要求選擇區(qū)域。這一步千萬別隨便選因為不同區(qū)域之間的可用服務種類、配額策略可能有差異。比如某個云基礎設施的服務不一定在每一個區(qū)域都上線。區(qū)域的選定還涉及數(shù)據(jù)流向后續(xù)應用部署在哪里數(shù)據(jù)就主要留在哪里。我們團隊日常會在兩個區(qū)域之間切換忘切區(qū)域去查資源是最常踩的坑之一。右上角的區(qū)域切換器非常重要查不到東西時先確認當前處于哪個區(qū)域再往下查子賬戶和服務很多時候問題就出在這一步。1.3 首頁儀表板該看什么登錄成功后的Overview頁面會展示當前區(qū)域的子賬戶數(shù)量、服務訂閱情況、可用許可證等。這一頁適合做常規(guī)體檢比如看看配額使用率、是否有異常資源占用但不建議在這里做實際修改操作。真正的功能入口在左側導航欄。左側導航從上到下依次會有Boosters、Subaccounts、Service Marketplace、Directories等入口部分版本還會多出告警監(jiān)控相關的菜單。這些項目才是Cockpit的核心操作面板。第一次接觸時我建議把左側菜單從上到下挨個點一遍花十分鐘搞清楚每一項目的是干什么的。這個投入非常值得之后你就知道遇到某種需求時該去哪一層找入口而不是在菜單之間來回猜。2. 賬戶模型與權限體系幾乎所有操作的底層邏輯2.1 目錄、子賬戶、空間之間到底什么關系很多教程一上來就讓你創(chuàng)建子賬戶卻沒有先把這三層結構講清楚。我自己梳理之后是這樣理解的目錄是最外層的“收納袋”用來把多個子賬戶組織在一起便于在團隊或者多項目場景下統(tǒng)一管理配額和成本子賬戶是實際擁有資源配額的最小管理單元里面可以啟用環(huán)境、訂閱服務空間則是Cloud Foundry環(huán)境里的進一步劃分類似開發(fā)環(huán)境中的“項目目錄”同一個子賬戶下可以劃出開發(fā)空間、測試空間和生產(chǎn)空間。打個比方目錄是辦公室里的文件柜子賬戶是其中一個抽屜空間則是抽屜里不同顏色的文件夾。資源配額通常是按抽屜來分配的而應用和服務則放在具體文件夾里。理解了這一層后面在菜單里找東西就不會迷路。Cockpit里創(chuàng)建子賬戶時頁面會要求填寫顯示名稱同時還可以指定空間名?？臻g名可以是默認的dev也可以自定義成test、prod之類。注意新創(chuàng)建的子賬戶不會自動獲得任何資源所有配額都要手動分配這一點在界面上雖然有提示但很多人還是會忽略。2.2 用戶、角色集合與權限的綁定用戶和權限這部分看起來有點繞但核心邏輯只有一句話用戶先進入子賬戶角色決定他在這個子賬戶及空間里能做什么。平臺內置了幾種預設角色比如管理員、開發(fā)者、查看者每種角色的權限范圍不同。管理員可以做全局配置開發(fā)者可以在空間部署應用查看者基本只能看。實際操作里Cockpit并不是直接在用戶身上逐條勾選角色而是通過Role Collections角色集合來綁定。流程是先在子賬戶的Security → Users里添加用戶然后在用戶詳情頁里分配角色集合。我見過很多人在這一步失敗用戶添加完了但沒綁角色集合結果用戶能登錄Cockpit一進入空間操作就會提示權限不足。解決方式也很簡單回到用戶詳情頁在Role Collections中勾選合適的集合并保存即可。另一個常見情況是用戶已經(jīng)綁了角色集合但新配置的權限沒有及時生效重新登錄一次就好。2.3 配額分配別把資源留在一個子賬戶子賬戶可用的服務配額來自平臺賬號的總配額。你需要手動把總配額拆分給各個子賬戶比如把內存配額一部分給開發(fā)子賬戶一部分留給生產(chǎn)子賬戶。劃分完成后子賬戶才能在Service Marketplace中創(chuàng)建對應服務的實例否則即使服務列表里顯示可用創(chuàng)建時依然會報配額不足。我在實際項目中吃過不少虧。剛開始圖省事把所有配額都集中在一個子賬戶里后面項目擴展時要給另一個環(huán)境騰資源就得反復回去調整。經(jīng)驗是動手之前先規(guī)劃哪個子賬戶跑什么服務、預計需要多少內存和存儲把這些寫下來再一次性在配額配置里調好。短期看起來多花了一點時間后續(xù)省下的是反復改配置和排障的成本。3. 高頻操作實戰(zhàn)從建子賬戶到跑起一個環(huán)境3.1 創(chuàng)建子賬戶的完整過程打開Cockpit之后進入Subaccounts頁面點擊創(chuàng)建子賬戶的按鈕。不同版本界面措辭可能略有差異但入口基本都一樣。需要填寫的信息主要有幾個顯示名稱、子賬戶所處的區(qū)域、選用的云基礎設施以及是否啟用Cloud Foundry環(huán)境。其中比較關鍵的是Cloud Foundry環(huán)境選項。如果現(xiàn)在就啟用頁面會要求指定一個空間名。如果暫時不想啟用可以之后在子賬戶詳情里再手動添加。這一點看個人需要但我的建議是如果你打算部署應用就在創(chuàng)建時順手啟用這樣整個環(huán)境鏈路會更順。創(chuàng)建完成之后Cockpit會生成一個子賬戶ID這個ID是全局唯一標識之后用命令行工具或者API訪問該子賬戶時會頻繁用到。很多教程不提這個ID導致后續(xù)對不上號建議用戶拿到ID后隨手記錄下來。還有一點容易被忽略創(chuàng)建子賬戶時可以順便打上標簽。標簽用于成本統(tǒng)計和資源歸類在子賬戶很多的情況下非常有用。我的建議是從一開始就規(guī)規(guī)矩矩打標簽例如項目名加上環(huán)境名后續(xù)做成本報表時會輕松很多。3.2 在服務市場里啟用服務Service Marketplace翻譯過來就是服務市場點進去之后會看到當前子賬戶在所選區(qū)域下能訂閱的所有服務。這里有一個容易誤解的地方列表列出了某項服務只代表“可用”并不代表本子賬戶已經(jīng)開通。要想真正使用必須進入該服務的詳情頁點擊創(chuàng)建選擇一個服務計劃Plan輸入實例名稱再完成配置。創(chuàng)建成功之后平臺還會引導你生成服務密鑰。服務密鑰里包含連接該服務所需的地址和憑據(jù)應用通過它來訪問服務。這步很多人會漏掉漏了之后程序連接服務時拿不到可用的憑據(jù)就會反復超時或者認證失敗。密鑰可以事后補建在服務實例詳情頁里能找到相關入口但最好在創(chuàng)建實例時順手就把密鑰生成出來并妥善保存。如果你把憑據(jù)寫進了代碼那就等于給項目埋了一個隱患。我遇到過一種情況服務市場里看不到想要的服務。第一步往往不是發(fā)帖求助而是回到子賬戶的配額界面檢查該服務的配額是否已經(jīng)分配給當前子賬戶沒有的話需要先從總配額里分配。至于服務的版本和可用區(qū)域可以在服務詳情里看到說明。不同區(qū)域的已上線情況不同這也是我前面強調區(qū)域選擇重要的原因。3.3 配置目的地讓云端應用連上外部系統(tǒng)Cockpit里有一個專門用來配置連接信息的模塊叫Destination中文通常叫目的地。它的作用可以理解為從當前子賬戶出發(fā)訪問另一個系統(tǒng)時所需的連接配置。最常見的是HTTP類型比如從云平臺上的應用調用某個本地系統(tǒng)的接口就要先把目標系統(tǒng)的訪問地址和認證信息配成一個目的地。新建HTTP Destination時主要字段有名稱、URL、身份驗證方式。身份驗證方式最常用的是BasicAuthentication也就是用戶名密碼方式也有NoAuthentication和ClientCertificateAuthentication可選。配置完成后界面通常會提供測試連接的功能點擊Check Connection平臺會嘗試發(fā)一次請求來驗證連通性。這一步我強烈建議做因為很多配置問題都會在測試時暴露出來。實際踩坑中最典型的錯誤是URL寫成了內網(wǎng)地址。云平臺跑在云端內網(wǎng)地址大概率不可達測試會直接報錯。另外有些系統(tǒng)對證書有校驗如果證書不被信任也會導致連接失敗。配置目的地之前最好先確認目標地址從云端網(wǎng)絡是否可達以及對方系統(tǒng)是否放開訪問權限。曾經(jīng)有同事折騰了一下午最后發(fā)現(xiàn)是目標環(huán)境的防火墻把云平臺的出口IP攔了服務平臺側配置反復修改都沒用。3.4 用Boosters快速搭建演示環(huán)境Boosters也就是加速器是Cockpit里提供給“不想手動一步步配置”的人群使用的功能。選擇對應的加速器后它會把子賬戶創(chuàng)建、服務啟用、基礎配置等前置步驟串起來通過引導式問答完成環(huán)境搭建。對第一次接觸平臺的人來說這個入口是最友好的。不過我個人的建議是第一次搭測試環(huán)境可以用Booster快速起步生產(chǎn)環(huán)境還是回到手動流程。原因是Booster幫你做了很多決定比如配額分配、服務計劃選擇這些決定默認不一定適合你的業(yè)務場景。只有自己手動配一遍才能清楚每個步驟背后的含義后續(xù)出了問題也更容易定位。其實Booster最大的價值在于“演示”和“驗證”而不是“生產(chǎn)配置”。如果Booster執(zhí)行到一半卡住了通?？梢栽谌蝿杖罩纠锟吹骄唧w失敗原因。日志會直接指出是哪一步權限不足還是配額不夠。按日志提示去子賬戶和配額界面調整通常就能繼續(xù)。不要一看到卡住就重跑先分析原因會更高效。4. 日常運維與排障Cockpit里那些能省時間的細節(jié)4.1 看日志與應用狀態(tài)Cockpit里進入某個空間的Overview能看到該空間下已部署應用的狀態(tài)和實例數(shù)量。點擊具體應用可以查看實例是否正常、資源占用情況、請求記錄等信息。這里看到的不是代碼級日志代碼級日志通常要去對應的應用運行時里查但Cockpit的作用在于快速判斷應用是否崩潰、是否頻繁重啟。我平時比較習慣先通過Cockpit做一層過濾如果應用狀態(tài)異常就再往下鉆到運行時日志看具體報錯如果狀態(tài)正常但接口返回異常再結合目的地和網(wǎng)絡配置繼續(xù)排查。這種分層排查思路比直接扎進日志里翻要清晰得多也能更快定位是資源問題還是代碼問題。4.2 排障套路先查區(qū)域、再查配額、最后查權限結合我自己踩過的坑90%的報錯都逃不出這三類區(qū)域不對、配額不夠、權限不足。如果你照著教程操作結果界面和教程對不上先看當前選中的區(qū)域是不是和教程一致區(qū)域選錯會直接影響菜單和服務列表如果服務創(chuàng)建到一半失敗大概率是配額分配不夠如果界面某些按鈕點了沒反應或者報403那就去檢查用戶的角色集合是否綁定成功。這套排查順序看起來簡單但在實際使用中真的很管用。有一次用戶反饋“我能登錄Cockpit但進不了空間的應用頁面”我先讓他確認區(qū)域沒問題再看子賬戶配額也沒問題最后才想到是不是角色集合沒有正確分配一看果然如此。如果一開始就去翻日志估計要折騰很久。4.3 用標簽和成本視圖管理資源Cockpit支持在子賬戶、空間等資源上打標簽這一點很適合多項目共用平臺的情況。一開始我也忽略了這個功能覺得多一步操作很麻煩后來項目多了資源列表變得雜亂想統(tǒng)計某個項目用了多少資源只能靠猜。后來我養(yǎng)成了習慣創(chuàng)建子賬戶時就打上項目名和環(huán)境標簽后續(xù)成本報表可以按標簽維度查看。平臺的成本報表功能能看到配額使用情況和消耗趨勢。到了月底和人核對賬單時可以很清楚地知道某個項目的資源消耗在哪一個子賬戶用在什么服務上。雖然這一步對功能開發(fā)本身沒有影響但對負責成本管理的人來說非常重要。剛開始用Cockpit時不必把標簽作為優(yōu)先事項但項目一旦超過三個這就會變成剛需。5. 個人實操心得這些細節(jié)最能看出是否真正上手5.1 盡早養(yǎng)成“從子賬戶出發(fā)”的習慣我剛上手時特別隨心所欲看到左側有菜單就直接點結果經(jīng)常在不同環(huán)境和子賬戶之間跳來跳去最后不知道自己改的是哪一塊配置。后來我給自己定了一個規(guī)矩每次做任何操作之前先在左側確認當前選中的子賬戶然后再從子賬戶的Overview頁面出發(fā)。這個習慣堅持下來之后誤操作的概率大大降低。尤其是同時管理多個子賬戶時誤操作到別的環(huán)境風險很高。給子賬戶起名的時候也要考慮可讀性比如加上項目前綴或環(huán)境后綴不要用“test1”“test2”這種只有自己看得懂的名字。團隊協(xié)作時清晰命名比想象中重要。5.2 管理密鑰與憑據(jù)要趁早規(guī)劃創(chuàng)建服務實例時順手生成的服務密鑰如果弄丟了大部分情況可以在服務實例詳情頁重新創(chuàng)建不算嚴重事故。真正值得重視的是不要把密鑰明文寫在項目代碼里更不要提交到版本庫。順便說一句平臺對憑據(jù)的輪換也有建議機制定期更新并同步到應用配置里是更穩(wěn)妥的做法。實際工作中我習慣用一個專門的位置保存密鑰文件并嚴格控制訪問權限。如果密鑰泄露第一時間重新生成并更新相關配置然后排查可能受影響的服務。這種事在開發(fā)環(huán)境里影響范圍有限一旦發(fā)生在生產(chǎn)環(huán)境就會非常麻煩。5.3 多利用文檔入口少依賴過期教程Cockpit界面里大多數(shù)模塊都帶有查看相關文檔的入口點進去能看到該功能的最新解釋和限制。有些服務在界面上會明確標注已停止維護并給出替代方案。以官方頁面和實時界面為準是使用Cockpit最靠譜的方式。我就見過有人照著一篇很早的文章操作文章里的入口已經(jīng)在新版界面中被挪到了別處結果他對著屏幕找了半天都沒找到還以為是權限問題。后來點開文檔鏈接十分鐘就解決了。網(wǎng)絡上的教程只能作為參考真正會隨著版本更新的只有官方界面和文檔。5.4 給剛起步的人一個可執(zhí)行的路線如果你剛接觸Cockpit不知道從哪里開始我建議按照這樣的順序走一遍先用試用賬戶登錄把區(qū)域切換、賬號信息看一遍然后創(chuàng)建第一個子賬戶順手啟用默認空間接著從服務市場訂閱一個輕量服務創(chuàng)建實例并生成密鑰最后配置一個HTTP目的地并成功完成連接測試。走完這一圈Cockpit的骨架就基本清楚了。后面再碰更復雜的配置無非是在這條骨架上增加細節(jié)。Cockpit的功能很多但核心操作邏輯是相通的。反復用過幾次之后你就會明白它并不神秘只是一個設計上分層清晰的資源管理臺。踩過幾次坑之后你對它的理解會完全不一樣。