先進的DevSecOps管道定制
在您上線第一個應用程式或微服務後,瞭解 DevSecOps 採用的進階功能。
確保您查看了 的基礎知識DevSecOps管道定制。 在那裡,您可以了解可用的不同模板、支援選項以及其他重要資訊以幫助您開始使用DevSecOps。
設計選項
當您加入更多應用程式和微服務時DevSecOps,您可能有以下設計問題:
- 每個微服務需要一個工具鏈嗎?
- 每個微服務需要一個管線嗎?
- 我需要使用共享嗎DevSecOps庫存和問題的存儲庫還是我需要單獨的存儲庫?
下列資訊及最佳作法旨在協助您進行這些設計選擇。
工具鏈及管線考量
大部分應用程式都是由多個具有不同來源儲存庫的微服務所組成。 通常會使用單一工具鏈來管理邏輯分組的微服務。 一般而言,請使用一個工具鏈及一個管線,或盡可能使用較少的管線,但使用多個觸發程式。 在每一個管線內,您可以視需要複製及配置任意數目的觸發程式,每個管線最多 1024 個觸發程式。 此策略有助於施行一般處理程序、Script 及配置檔。 如需相關資訊,請參閱 在一個 CI 工具鏈上配置多個應用程式。
此方法具有下列優點:
- 使用較少管線可避免重複,並減少錯誤。 例如,新增、編輯或刪除環境內容或密鑰時,也更容易維護更新項目。
- 使用此方法更快速地上線服務。 為您的微服務新增 Git 整合,複製 Git 和手動觸發程式,並視需要加以修改。 然後,確保針對微服務實作
.pipeline-config.yaml檔案及 Script。
此方法有下列缺點:
- 一次編輯可能會影響每一個使用相同管線的團隊。
- 使用者存取權是使用 Identity and Access Management(IAM) 進行管理,並在工具鏈層次而非管線層次進行設定。 因此,如果您對多個服務使用單一工具鏈,則團隊的每個成員都可以檢視其他團隊的管線。 視使用者在 IAM 中的存取權而定,他們可能可以編輯、刪除或觸發管線。
計費考量
Continuous Delivery 服務根據每個 CD 實例的授權使用者數量,以及您的工具鏈使用多少個資源群組來決定計費。 對儲存庫具有存取權的使用者也會被視為授權使用者。 如需相關資訊,請參閱 授權使用者。 為了降低成本,您應該在相同的資源群組中組織所有的工具鏈,或是在企業帳戶層級中設定 Continuous Delivery 整合計費。 如需詳細資訊,請參閱 綜合帳單。
DevSecOps儲存庫注意事項
如果您正在創建一個由多個微服務組成的應用程序,那麼大多數DevSecOps儲存庫(證據儲存庫除外)可以在微服務之間共用。
有關更多信息,請參閱 如何DevSecOps管道使用儲存庫。
共用配置儲存庫考量
這DevSecOps範例應用程式帶有一個位於相同位置的 .pipeline-config.yaml設定檔和相應的腳本。 加入多個微服務時,最佳實踐是將原始碼儲存庫與DevSecOps設定檔和腳本。 將這些儲存在可供 CI、CD 或 CC 管線使用的個別專用共用配置儲存庫中。
這包括:
- 專用的 Git 儲存庫,用於管理一般 Script 程式庫及。pipeline-config.yaml 檔案。
- 所有服務共用的單一.pipeline-config.yaml 檔案。 如果太複雜或無法使用,請使用不同的pipeline-config.yaml 檔案。
- 每個資料夾的自訂作業。 實作pipeline-config.yaml 檔案,以指向配置儲存庫中的不同 Script 資料夾。 在個別 CI、CD 及 CC 資料夾中組織 Script,或根據服務語言 (Go、Python、NodeJS)、服務、應用程式名稱或任何最符合您需求的項目來組織 Script。
將 pipeline-config-repo 管道屬性的值(可選的 pipeline-config-branch )設為共用組態儲存庫 URL,以變更您的管道使用此共用組態儲存庫。
庫存儲存庫考量
單一庫存儲存庫可以在許多管線和工具鏈之間共用。 數個 CI 工具鏈、管線及觸發程式可以提供給相同的庫存儲存庫。 CI 管線會將更新項目推送至庫存儲存庫,通常是在發行階段期間。 然後會使用庫存儲存庫作為 CD 管線的來源輸入。 一般而言,最佳作法是將庫存儲存庫分組到相同的工具鏈中,以減少最終建立的變更要求數目。
使用共用庫存儲存庫是在開始上線微服務之前需要做出的架構決策,因為此決策會影響管線執行時所建立的變更要求數目。 例如,假設您想要加入 10 個微服務DevSecOps。 您可以有 10 個不同的 CD 工具鏈,以及 10 個不同的庫存儲存庫,這會在每次執行 CD 管線時產生 10 個不同的變更要求。 如果這 10 個不同的微服務共用一般庫存儲存庫及一般 CD 工具鏈,則更容易管理這些微服務。 這只會導致一個變更要求,即使您對多個微服務進行更新也一樣,因為它們都共用庫存儲存庫及工具鏈。
問題儲存庫考量
您的問題儲存庫是追蹤微服務所有漏洞問題的位置。 如果您決定使用共用庫存儲存庫,您也可能想要使用共用問題儲存庫。
在管線或觸發層次設定 incident-assigness 和 incident-labels,有助於自動將問題指派給正確的團隊。 如需相關資訊,請參閱 連續部署參數。
IBM Cloud Object Storage 考量
如果使用共用的庫存儲存庫,也可以使用 IBM Cloud® Object Storage 的共用實例。 請完成下列步驟:
- 建立 IBM Cloud Object Storage 的實例 以跨工具鏈及管線使用。
- 設定管線及觸發程式 (如果適用的話),以透過設定
cos-bucket-name環境內容來使用 IBM Cloud Object Storage 儲存區。
不論部署環境為何,相同 CI、CD 和 CC 管道中的所有微服務都共用一個 Object Storage 桶。 Object Storage 儲存桶的功能與證據儲存庫相似,但沒有大量證據儲存庫可能出現的效能問題。 因為大量的 Object Storage 儲存桶不會發生效能問題,所以您不需要從 Object Storage 儲存桶中修剪證據。
Object Storage 水桶粒度
DevSecOps 管道對於 Object Storage 桶的粒度並無意見。 技術上來說,您可以在整個組織中使用單一 Object Storage 桶。 但是,粒度不應該小於庫存,因為庫存是可以一起移動的微服務的最小邏輯群組。
實際上,粒度的大小取決於您的法規遵從團隊想要管理法規遵從資料的作業模式:
- 如果合規團隊能夠自如地管理多個 Object Storage 資料桶,並將資料分門別類,這是一個可行的模式。
- 如果他們偏好管理單一較大的 Object Storage 資料桶,且不分割資料,也是可以的。
關鍵考量:Object Storage 儲存桶(證據櫃)的目的是系統可讀,而非人類可讀。 它不支援,而且在可預見的未來也不會支援依儲存庫、微服務、產品或組織組織的資料夾結構。 它仍然是資產和證據的扁平化結構。
安全性與存取考量
粒度較低的 Object Storage 儲存桶可在發生安全漏洞時增加爆破半徑 (例如,暴露 Object Storage API 金鑰)。 這也會造成交叉可見的問題,如果某個垂直產品共用相同的資料桶,就有可能讀取另一個產品的合規資料。
移轉考量
若有需要,可透過 Object Storage 儲存桶進行遷移。 這通常包括設定備份 Object Storage 桶的某些環境屬性,以及重建 CI 元件。 如需詳細資訊,請參閱本 文件。 不過,這些作業的目的是作為一次性的遷移活動,而不是設計成日常作業工作流程的一部分。
建議方法
每個邏輯產品群組使用一個 Object Storage 桶,其合規性資料需要一起移動。 例如:
- 服務小組 A(包括其內的所有小隊)共用 Object Storage 桶 A
- 服務小組 B(包括其內的所有小隊)共用 Object Storage Bucket B
此方法可在操作簡易性與安全性及存取控制需求之間取得平衡。
部署至多個環境
使用 CD 管線部署至多個目標環境可以透過數種方式來達成。
每一個 targeted environment 在庫存儲存庫中都應該有對應的分支,其中會將變更從 source 調升至 target 分支。
下列選用設計可能適合您的架構:
- 每個目標環境使用一個手動觸發程式。 複製觸發程式,然後編輯環境內容以適合新環境。
- 將 Git 配置儲存庫用於每個目標環境一個資料夾,其中特定配置設定儲存在檔案中。
使用預設及自訂 Script
大部分安全及相符性 Script 都隨附 預設 Script,如果沒有為階段提供自訂 Script,則會執行這些 Script。 有時很難判斷要執行哪一個 Script、在何處尋找對應的來源 Script,以及如何置換預設 Script。
識別要執行的 Script
若要識別針對階段執行的 Script,請開啟管線執行 (最好是 CI 管線)。 展開作業,然後按一下 run-stage 以開啟日誌。 run-stage 日誌的開頭提供暫置中所使用 Script 的相關資訊,包括 Script 所在的儲存庫。 在日誌中,您可以捲動以尋找已執行 Script 的更多詳細資料。 例如,code-compliance-checks 作業在 run-stage 日誌中可能具有下列資訊,其中包括階段的環境內容:
compliance-checks:
image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
dind: true
abort_on_failure: false
image_pull_policy: IfNotPresent
script:
#!/bin/sh
"/opt/commons/compliance-checks/run.sh"
在該範例中,所執行的 Script 是 /opt/commons/compliance-checks/run.sh,位於 commons library 中。 使用此共用程式庫作為來源,以複製可針對特定邊緣案例自訂的程式碼。 在此範例中,compliance-checks/run.sh 位於 compliance-commons 程式庫。
置換預設 Script
若要置換預設 Script,請完成下列步驟:
- 在階段日誌中,複製識別預設 Script 的 Snippet:
compliance-checks:
image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
dind: true
abort_on_failure: false
image_pull_policy: IfNotPresent
script:
#!/bin/sh
"/opt/commons/compliance-checks/run.sh"
- 將 Snippet 貼到
.pipeline-config.yaml檔。 - 在呼叫 Script 之前或之後新增自訂程式碼。 此片段會啟用預設的 符合性檢查腳本
- 視需要編輯、刪除或新增內容。
下列範例顯示 .pipeline-config.yaml 檔中已更新的 Script:
compliance-checks:
image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
dind: true
abort_on_failure: false
image_pull_policy: IfNotPresent
script: |
#!/bin/sh
# run some custom script here
./scripts/my-custom-script1.sh
"/opt/commons/compliance-checks/run.sh"
# then some additional work
./scripts/my-custom-script2.sh
如需相關資訊,請參閱 自訂 Script。
要使用的 Terraform 模板DevSecOps工具鏈即程式碼
以下工具鏈提供了創建程式碼DevSecOps使用 Terraform 的 CI、CD 和 CC 工具鏈:
依現狀提供對這些 Terraform 工具鏈的早期存取。 這些工具鏈處於作用中開發狀態,因此變數及變數名稱可能會變更。