組織及管理專案的最佳作法

這些最佳實踐為您提供了在 IBM Cloud® 中成功 管理構件的集合,用來定義及管理資源和「基礎架構即程式碼」部署。 安全專案的基本要素。 專案對受管制的企業有好處,可作為最佳管理程式碼型部署的方法,同時維護合規性並與跨帳戶的團隊成員分工合作。

建立主要專案帳戶

IBM Cloud 專案的主要好處是能夠集中管理及分工合作「基礎架構即程式碼」部署。 如果您使用企業,則建立主要或首頁帳戶以儲存所有專案,有助於在一個位置管理及追蹤您的專案。

建立主要帳戶的效用取決於您的企業結構。 專案可以在帳戶中建立,並將資源部署至其他帳戶。 使用者只能檢視他們目前登入之帳戶內的專案。 此外,只能針對相同帳戶內的專案產生多個專案的報告。 這是為企業中的所有專案或具有類似事業單位的所有專案建立共用主帳戶的另一個有用好處。 透過將專案保留在主要帳戶中,並部署至每一個環境 (開發、測試及正式作業) 的個別帳戶,以簡化企業管理。

為了讓帳戶更容易讓所有使用者識別帳戶內的目的和專案,請提供帳戶一個人類可讀的名稱。 例如 Front-end UI teamBack-end API team

定義鑑別方法

當您配置可部署架構時,需要新增鑑別方法。 驗證方法會識別部署資源的目標帳戶,並授權進行部署。 您可以選擇透過授信設定檔或現有密碼進行鑑別。

使用授信設定檔

部分服務無法使用授信設定檔來完整配置及部署架構。 如需相關資訊,請參閱 專案的已知問題和限制

您可以使用授信設定檔,在您自己的帳戶或另一個帳戶中部署架構。 視您的組織而定,部署架構可能需要使用授信設定檔並與多個帳戶中的管理者協調,以存取另一個帳戶。 如果另一個帳戶中的 IBM Cloud 專案服務需要存取您的帳戶才能部署架構,請使用授信設定檔和服務 ID 來授權帳戶中的部署。 如需為專案建立授信設定檔的相關資訊,請參閱 使用授信設定檔來授權專案部署架構

使用 IBM Cloud® Secrets Manager

當部署 Infrastructure as Code ( IaC ) 時,通常需要一些秘密來設定基礎架構,例如 API 金鑰、SSH 金鑰和 SSL 憑證。 在這種情況下,建議將這些秘密儲存在一個 Secrets Manager 實例中。 專案直接支援引用儲存在 Secrets Manager 中的 API 金鑰,作為可部署架構的輸入。 如需詳細資訊,請前往 使用 API 金鑰與 Secrets Manager 來授權專案部署

在建立專案之前,請先於您的主要專案帳戶中建立一個可供該帳戶內所有專案使用的 「Secrets Manager」服務實例

您可以建立一些不同的密鑰類型。 使用任意密鑰實例來儲存專案的 API 金鑰。 如需相關資訊,請參閱 在使用者介面中建立任意密鑰

通常會將單一 Secrets Manager 實例用於帳戶中的所有專案。 該實例中的密鑰可以組織成符合存取限制的密鑰群組。 例如,您可能想要針對每個專案或一組相關專案使用密鑰群組。

使用環境來控制部署

在專案內,您可以使用環境將相關配置分組在一起。 環境也可以包含輸入值和驗證細節等屬性。 當您選取環境時,這些內容會自動新增至配置,這有助於確保精確部署至目標帳戶。 當您編輯配置時,您可以在 定義詳細資料 區段中選取配置要使用的環境。

使用環境的好處

環境可讓您更容易控制部署。 透過指定環境並新增內容,您知道在使用該環境的配置之間共用相同的值。 在組態中,您可以覆寫環境自動提供的任何值。

環境提供一種在專案內將相關配置分組在一起的方法。 假設您有一組配置,您想要部署至作為開發帳戶的相同目標帳戶。 您可以建立「開發」環境,並將目標帳戶的鑑別詳細資料新增至該環境。 鑑別方法會新增至每一個使用「開發」環境的配置。

雖然您可以建立任意數目的環境,但建議您保持專案中的環境數目較低。 針對跨帳戶的部署使用一組標準環境,可讓您更容易配置及部署架構。

如需相關資訊,請參閱 建立環境

組織配置

請考量將所有相關配置組織成單一專案。 這樣,您可以從一個位置管理部署,並協助確保部署安全且符合標準。 這可能包含一個以上可部署的架構,以建立必要的基礎架構,然後需要抄寫這些基礎架構,以支援多個地區及環境,例如開發、測試及正式作業。

請對您的配置使用命名慣例,以便使用者可以瞭解每一個配置的功能。 例如,在使用 VPC Base 可部署架構及根據 VPC Base 的 Kubernetes 叢集可部署架構的部署中,您可以將配置命名如下:

配置名稱範例
名稱 可部署的架構 環境 附註
開發-VPC-全球 VPC 基本程式 開發 建立開發環境的基本 VPC
德夫-庫布-達拉斯 Kubernetes 叢集 開發 在達拉斯建立叢集以進行開發
德夫-庫布-倫敦 Kubernetes 叢集 開發 在倫敦建立叢集以進行開發
正式作業-VPC-廣域 VPC 基本程式 正式作業 建立正式作業環境的基本 VPC
Prod-Kub-達拉斯 Kubernetes 叢集 正式作業 在達拉斯建立用於正式作業的叢集
普羅-庫布-倫敦 Kubernetes 叢集 正式作業 在倫敦建立用於正式作業的叢集
Prod-Kub-東京 Kubernetes 叢集 正式作業 在東京建立用於正式作業的叢集
Prod-Kub-雪梨 Kubernetes 叢集 正式作業 在雪梨建立用於正式作業的叢集

您可以複製 project.json 檔案中的開發配置,並視需要修改它,以從其測試的開發部署快速建立正式作業部署。

建立專案的存取群組

專案存取權由 Identity and Access Management (IAM) 控制。 建議每個專案建立兩或三個存取群組,並將使用該專案的使用者指派給其中一個存取群組。 例如,您可以建立一個專案名- 讀者存取群組,為需要監控成本或可用性的使用者提供對專案的唯讀存取權限,以及專案名- 編寫者存取群組,適用於需要變更專案和部署資源的操作使用者。 必要的話,您可以建立兩個寫入者存取群組,一個用於可新增配置及完成輸入值的使用者,另一個用於可部署資源的使用者。

專案訪問群組和角色
存取群組 角色
專案名-讀者 讀者,檢視者
專案名-作家 經理、操作員

若要建立新專案,必須為使用者指派特定存取權。 如需相關資訊,請參閱 指派使用者對專案的存取權

監視需要注意項目

需要注意項目最適合用來監視驗證、核准、失敗及版本更新。 透過定期檢查需要注意項目,您可以確保專案及配置保持最新且符合標準。

將標籤新增至專案

您可以套用標籤來組織、追蹤及管理您的專案。 為相關專案添加標籤可能有所助益,甚至可為臨時專案添加標籤以作標識,例如用於客戶演示的基礎架構,或是已不再需要的原型。 這可讓您輕鬆找到並管理暫時專案。

標籤不會區分大小寫,並且標籤的長度上限為 128 個字元。 允許的字元為 A-Z、0-9、空格、底線、連字號、句點和冒號。

專案中的資源會自動獲得服務標籤,以及它們相關聯的專案 ID 和配置 ID。 如需相關資訊,請參閱 追蹤專案的使用情形和支出

取消部署專案所建立的資源

當您部署配置時,所建立的資源可以作為專案內的群組來管理。 這些資源是根據 Terraform 計劃建立的,可以在 Schematics 工作區中個別管理。

雖然您可以從 Schematics 工作區毀損個別資源,但不建議對使用專案建立的資源執行此動作,因為它會導致漂移。 相反,您只需單擊即可從專案 UI 立即取消部署與配置關聯的所有資源。 這樣做會將部署從您配置部署至的任何目標環境中移除。 如果您將來需要再次部署配置,取消部署資源而不刪除配置會很有幫助。

預設情況下,當您刪除專案或設定時,已部署的任何資源都會自動取消部署。 建議保持啟用此設定,但您可以透過開啟專案並移至 管理 > 設定來停用它。 如果您停用該設定,當您刪除配置或專案時,資源會保持已部署狀態,但您無法輕鬆管理專案內的那些資源。 如果已部署的資源在刪除專案或配置之後仍然可用,則可以繼續增加目標帳戶的成本。 有關更多信息,請參閱 取消部署資源