在本系列的第一篇文章中，您已經瞭解了一些關於如何管理Jenkins的內容，主要是為無序的人帶來秩序。在這篇文章中，我將更深入地探討我效率低下的問題，提出我們工作流中一些安全性、治理和合規性的挑戰。這不僅僅是你在網站上或展覽橫幅上看到的DevOps流行語——它們是保持軟件交付速度的關鍵。我發現，如果我們的安全協議沒有一致的治理或合規性，自動化就會變得不那麼......自動化。

以下是我發現不受管理的Jenkins的另外兩個缺點，一起來看看，説不定和你發現的一樣。

問題3：缺乏一致性

在我之前的文章中，提到過一個主題：分散控制和缺乏可見性會產生混亂。有太多的人操控太多的變量，這就很難讓每個人、每件事處於同一個起跑線。這帶來了巨大的障礙。

缺乏治理會阻礙最佳實踐。當隨便什麼人都可以啓動、配置或修改服務器時，您實際上是沒有治理能力的，並且幾乎沒有機會去持續地實施最佳實踐（例如定期安全掃描、禁止不安全插件等）。

插件劃分了服務器、工作流程和團隊。如果沒有插件管理，您的團隊可能會在服務器中放入任何數量（和質量）的插件。這將給團隊間帶來相當大的兼容性和互操作性問題，他們將不可避免地使用有衝突的插件，並按照不同的時間表來更新和共享插件。

缺乏一致性會導致更多的Bug。流水線的一致性是避免錯誤的關鍵。由於不同配置的控制器、不同的插件集、靈活變化的工作流程以及基本上互不關聯的團隊，不受管理的Jenkins會增加您的工程師尋找Bug的時間。

備份可能是零零散散的。備份數據並驗證這些備份的完整性都需要有組織、有紀律。如果缺少有意義的治理，您的備份策略可能會有漏洞，然後面臨丟失數據的風險。

問題4：缺乏安全

網絡安全是一項永無止境的挑戰。雲計算和業務轉型帶來了具有高度流動性(並不斷擴大)的攻擊範圍，快速的創新步伐要求企業時刻保持警惕來擊退潛在的攻擊者。那麼，這是如何對於已經陷入我所提到的困境的企業造成更大的影響的？

沒有授予任何人執行安全策略的權利。如果沒有集中的權力或可靠的治理，您將很難讓團隊遵守安全最佳實踐（甚至遵循基本政策）。這將會給您的流水線帶來有風險的插件、有風險的代碼和有風險的做法。

您的安全強度只達到了您最不安全的插件的水平。隨着插件在控制器中數量激增，這些插件中的任何安全漏洞都會成為您的負擔。插件開發者是否修補了這些漏洞，以及你的團隊是否為了更好地利用安全補丁而可靠地更新他們的插件，這些都是安全方面的通用常識。

漏洞修復可能會很慢，甚至根本不存在。由於廚房裏有太多廚師，而且普遍缺乏可見性和協調，因此對發現的任何安全威脅進行修復將非常麻煩。

安全性混亂且薄弱，導致合規也變得困難。合規性就是要證明您是受控的，擁有可靠的保護措施，並且可以滿足安全標準。由於上面列出的所有原因，如果想靠不受託管的Jenkins實現這一點，很難。

邁入標準化、自動化和優化的大門！

如果您閲讀了第一篇文章，就已經知道是CloudBees CI幫助我控制不受管理的Jenkins實例的混亂局面，但現在，是我認真對待提高全面效率的時候了。這意味着一致性和自動化。以下是我確定對我和我的團隊有幫助的項目：

快速上手

• 所有開發團隊一開始就有一個值得信賴、經過驗證且受到支持的Jenkins版本，和以及一套經過穩定性和安全性測試的精選插件。對我來説，支持是最重要的一點。在我有問題時，總有人在我身邊幫助解決——無論問題多麼簡單；
• 使用自定義CasC捆綁包來配置可重複組件，使團隊能夠從從單一來源管理的預配置和測試環境開始。

流水線模板目錄，用於在整個運營過程中執行一致性和穩定性

• 你擁有一個基於最佳實踐的流水線集合，讓團隊永遠不必從頭開始，並且對模板的更改會從一個點推送到所有團隊的流水線中；
• 每次運行job時都會獲取最新的模板代碼，因此job始終反映的是最新的標準。可以有選擇性的把開發人員限制在特定的模板之中，來實現治理目標；
• 想要避免從頭開始治理開發人員，可以通過修改現有模板來適應新議程；
• 自定義標記文件讓您能夠基於軟件配置管理（SCM）標識符的基礎上，即時選擇構建模板。

自動備份和恢復

• 消除備份策略中的人為錯誤。我們團隊中有很多獨立的思考者，這對於功能開發這很有利，但對於一致的環境設置卻不是很友好。所以自動備份和恢復有助於為他們創造一個可以啓動和使用的環境，而不是每次都從頭開始創建。

跨團隊協作

• 使用一個強大的發佈者/訂閲者模型跨多個控制器管理事件，無論身處何處，團隊都訂閲流水線事件並對其採取行動；
• 流水線同步工作，不同的團隊能夠使用同步的自動化執行跨流水線的協作；
• 團隊可以通過控制器分開工作，但他們仍然可以協同工作，實現流水線自動化；
• 每個團隊都應該能夠安全地使用不同的插件和技術，而不會有影響其他團隊的風險。

提升開發人員的工作效率

• 直接在GitHub和Slack中接收細化的、可操作的構建數據。

輕鬆實現安全性和合規性

安全性和合規性對我們來説是一個巨大的挑戰。畢竟，如果您不能完全控制開發環境，那麼就很難實現這兩個目標，但目前很少有開發人員能夠做到。幸運的是，隨着CloudBees的集中化和標準化，安全性和合規性變得相對來説更容易了。隨着每個團隊都使用安全的構建和批准的流水線配置，我的SDLC有了全面的護欄支持（guardrails supporting）。以下是一些使我的工作變得更輕鬆的項目：

集中管理的安全策略

• 授權控制器僅運行經過測試、驗證且安全的Jenkins版本。如果構建中出現問題，可以更輕鬆地全局複製、修復和更新該構建。

• 從單一位置管理身份驗證和授權功能：

  • 在所有控制器上使用單點登錄（SSO）；
  • 使用基於角色的訪問控制（RBAC）模型定義安全憑據，並在控制平面、文件夾或單個控制器級別對訪問權限進行分組定義；
  • 使用文件夾層次結構實施對控制器、代理或項目的訪問；
  • 將RBAC與文件夾限制相結合以提高安全性，並確定誰可以在文件夾層次結構中的每個位置創建、修改、刪除和使用憑據。
• 基於每個團隊確定安全的範圍。
• 使用模板化的工作流程，將安全性落實到您的流水線中。

• 簡化合規性

  • 只需使用CasC捆綁包和流水線模板即可構建合規性。

• 將插件的風險降至最低

  • 限制團隊只能使用一組精心挑選過的插件（CloudBees保障計劃 - CAP），這些插件經過穩定性和安全性測試，並確認符合合規性目標。

隨着您團隊的擴大而擴展

大規模自動化是Jenkins的追求。不受管理的Jenkins在自動化方面可能表現出色，但在大規模管理部分則不然。這裏指的不是管理一個團隊，而是管理很多團隊。我需要為團隊提供成長的空間和所需的支持，並計劃隨着我們投資組合的擴大創建新的團隊。首先，需要考慮的就是對着人員的擴大而擴展，因為如果沒人使用它，那麼這個軟件被開發出來的目的是什麼呢？需要有一個人來確保所有人擁有他們完成工作所需的一切事物。在上述對我有用的功能中，有一些對擴展也有所幫助。

• 通過自動配置新團隊/控制器、傳播最佳實踐（流水線模板、CasC等），以及為規模合適的基礎設施管理資源，來實現大規模交付Jenkins。
• 團隊能夠自行快速啓動新的控制器和工作區，同時確保SDLC保持一致、受管控、合規且安全。
• 如果您使用的是Kubernetes，請在擴展時利用Kubernetes配置來優化基礎架構資源。這樣，控制器可以根據需要啓動，然後在不使用時可以休眠。

企業級支持

最後，要真正讓使用Jenkins企業做好準備，我們必須解決房間裏的大象：Jenkins缺乏結構化的支持。社區援助是非常好的解決方案，但是當災難發生時，您是沒有時間在論壇上挖掘出解決方法的。您要將彈性融入您的計劃，您需要堅如磐石的專業支持，這樣您才可以專注於構建應用程序，而不用為修復讓步。

讓CloudBees團隊的Jenkins專家為您提供指導。你不必再依賴Rick——你可愛的Jenkins專家，他收集了1980年代的限量版星球大戰人物（我們有着同樣的熱情，Rick）。相反，您要依靠專家的幫助，讓Rick在其他地方大展拳腳吧。

CloudBees CI建立在Jenkins之上，並添加了額外的功能來滿足企業的需求。我們瞭解Jenkins，並且因為我們為開源項目貢獻了大量代碼，所以我們在解決問題方面具有獨特的優勢——如果出現問題。

此外，CloudBees會主動解決Jenkins構建中的漏洞，確保它們在安裝前就被搞定，而且我們還創建了Jenkins健康顧問。健康顧問在整個Jenkins環境中提供運行狀況監控，在問題（安全漏洞、性能瓶頸、插件缺陷等）影響用户之前發送通知。健康顧問適用於所有Jenkins用户，而不僅僅是CloudBees CI用户，所以如果有專門支持Jenkins的精英團隊，您也可以使用它。

在下一篇文章中，我將解決可怕的基礎設施問題。基礎設施就像地基，您房子下面的地下室。我既想知道什麼時候有問題，又不想知道——因為解決這些問題需要做很多工作。我就是這樣的人，在我們團隊一瘸一拐的前進時，我否認自己有基礎設施問題。就有點像我知道天花板上有一隻蜘蛛......但也許如果我忽視它，它就能自行消失。但事實上是沒有這種運氣的——那些小生物會再次在某個地方出現。

作者：薩曼莎·弗羅斯特（Samantha Frost），CloudBees公司產品營銷經理。
文章來源：https://www.cloudbees.com/blo...