作者 | Vishnu Vasudevan
譯者| 趙青窕
審校 | Noe
? 根據ActiveState 2020年CI/CD狀態調查結果，Jenkins是目前市場上使用最多的CI/CD工具。作為市場上發展較早的持續集成工具，它有足夠的時間來進行推廣，并一直是推動DevOps構建和軟件交付方法的關鍵組成部分。
得益于逾1800個插件，使用正確的插件集就很容易對Jenkins進行擴展，通過擴展我們幾乎無所不能。Jenkins用戶可以基于不同的插件獲得個性化體驗。
插件可能是Jenkins的核心，但它們也很快成為使用Jenkins的團隊的負擔。當下管理Jenkins平臺已慢慢成為成長型團隊和公司的瓶頸，不會提高反而會降低敏捷性。
在本指南中，我將更多地介紹Jenkins的一些缺點，以及一些替代方案。
什么是Jenkins插件
插件對于使用 Jenkins 非常重要，以至于在安裝過程中會要求你從選擇一個插件開始。默認安裝附帶大約 20 個插件，以及你在安裝期間選擇的任何插件。 這些插件負責將你的 CI/CD 同 GitHub 或 Bitbucket 等外部工具集成以進行版本控制。插件還擴展了 Jenkins 的功能及其工作方式。即使是編排構建的管道系統(pipeline system)也是一個插件，可以使用其他插件進行修改。
你可以通過市場向 Jenkins 添加新插件。市場中的所有插件都是基于社區且開源的，這意味著任何人都可以創建符合他們需求的自定義插件并將其釋放到市場上。通常情況下，在選擇插件時，你需要注意以下三個重要事項：
●插件的受歡迎程度可以通過安裝次數來評估
●它的維護情況如何，可以通過查看最近一次更新的時間來估計
●所需的依賴關系，比如你是否需要安裝其他的插件
為什么 Jenkins 插件可能存在弊端
雖然大量可用的插件曾經被視為是平臺的優勢，但現在經常被視為一個缺點，助長了許多人與 Jenkins 之間的愛恨情仇。當它第一次發布時，Jenkins 感覺就像一個美妙的自助服務環境，一個可靠的開發團隊幾乎可以使用 Jenkins 管道和正確的插件集做任何事情。然而，今天，你需要真正的 Jenkins 專業知識來維護 Jenkins 服務器，這是一個劣勢，尤其是與市場上較新的 SaaS CI/CD相比較時。
有很多與 Jenkins 插件生態系統相關的常態問題。首當其沖的就是升級和依賴的無休止循環。一個簡單的項目可能需要超過 25 個不同的插件，且你安裝的每個插件又需要其他的插件來保證其可以正常工作。這會導致你陷入進退兩難，比如你安裝了兩個插件，每個插件都需要相同的第三個插件才能工作，并且每個都依賴于第三個插件的不同版本，從而導致安裝問題或錯誤。
當你發現插件存在安全漏洞時，就會出現更大的問題。如果你發現某個插件不安全或有漏洞，你可以在 GitHub 上提交問題并等待該插件被打補丁，但如果補丁永遠不會到來怎么辦？你可以忍受安全漏洞，可以找到替換插件并修改所有管道以適應新插件，或者復制插件并修補它，然后成為該插件的新維護者。鑒于每天都會發現新的安全漏洞并且插件需要經常修補，這很快就會觸發大量的工作。
這也導致了 Jenkins 插件的另一個問題。即使是非常流行的插件也經常被原始維護者隨意地維護或放棄。從維護者的角度來看，這是完全可以理解的。插件是為了解決問題而創建的，大多數維護者并不打算在他們的工作之外成為專業的插件維護者。但是在用戶方面，這會導致插件的支持很差，因為維護者是社區成員，沒有義務無限期地維護插件。
Jenkins 插件的最后一個問題是缺乏透明度。 如果不仔細檢查代碼，你將無法知道插件的范圍，并且你無法根據需要來限制插件的一些訪問和操作權限。因此，在選擇插件時，信任因素非常重要，需要小心減少潛在的攻擊面。
Jenkins 插件如何影響你的組織
當你考慮在單個團隊中使用 Jenkins 時，這些問題看起來可能不是一個大問題。他們可以使用他們最喜歡的插件集構建相應的管道，并且假設沒有安全問題，一切都會工作地很好。但是隨著公司的發展，更多的開發人員加入進來，創建了新的團隊，并且有多個應用程序和服務，Jenkins 插件就不能很好地工作。如果你讓每個人都使用他們想要的任何插件，你很快就會遇到依賴和升級問題。另一方面，如果你限制開發人員可以使用的插件，整個開發團隊的士氣可能都會變得低落。
Jenkins 只允許一個主節點，因此，在設計時根本沒有考慮到高可用性。由于這些設計選擇，必須重新啟動服務器以更改配置或安裝新插件，但這類操作會導致服務器停機并中斷組織中依賴 Jenkins 的每個人的工作。目前這個困境沒有簡單的解決方案。為每個團隊創建 Jenkins 服務器純粹是浪費財力，并且會逐漸形成一個個的小團體。擁有獨立 Jenkins 服務器的團隊將基于不同的插件集構建不兼容的管道，從而無法為你的團隊間彼此共享自動化工作的情況做好準備。
你不能讓Jenkins成為一個真正的自助服務平臺，因為它操作起來會很復雜，而且會減少團隊之間的合作。但是反對Jenkins插件的最大論點是插件是安全隱患。如前所述，幾乎所有插件都是社區創建和支持的。你需要相信維護人員使用了有利于安全的最佳方式，并針對新發現的漏洞都會對插件進行了修補，如果要正確地完成這些工作，可能需要每周進行一次。CI/CD平臺通常可以訪問許多系統，并擁有修改基礎設施和與生產環境交互所需的憑證。這使得任何CI/CD平臺都成為基礎設施中非常敏感的一部分，而安全性應該是這些工具的首要任務。
如何停止依賴Jenkins插件?
到目前為止，你已經可以很好地理解Jenkins插件的一些問題。如果你正在考慮停止依賴，轉向一個更安全的開發環境，你可以采取下面的方式。
1.仔細地管理插件
創建一個精心挑選的插件列表，并堅持使用這些插件。這個列表應該同時考慮安全性和可維護性的問題。一般來說，最好堅持使用如GitHub或Amazon Web Services等云提供商集成的插件，因為它們通常會得到相應云提供商的社區和開發者的大力支持。例如，GitHub插件是一個維護良好的插件，你可以依賴它。在主服務器上運行升級并運行新插件之前，先在輔助Jenkins服務器上測試它們。
避免更改Jenkins管道工作方式的插件，因為如果這些插件工作異常，不再被維護，或者存在安全漏洞，你將需要重做整個管道。
通過檢查插件的GitHub庫，主動關注插件的健康狀況，看看它們是否正在積極地被維護。如果發現異常，你應該尋找替代插件。這可以防止將來升級Jenkins服務器或發現安全漏洞時導致的停機。插件是具有潛在漏洞的獨立軟件，攻擊者可以利用這些漏洞來訪問你的構建系統，以及Jenkins出于必要時授予讀寫權限的其他部分，如代碼存儲庫、云提供商和網絡連接。正如在SolarWinds供應鏈攻擊事件中，攻擊者通過構建管道將惡意軟件注入，不久后，受污染的軟件又被交付給公司的數萬個客戶。這表明，CI/CD管道是構建流程中被信任的一部分，只需要一段惡意代碼，不僅能讓你的公司受到攻擊，還可以讓你的客戶受到攻擊。這一領域的極端敏感性使得插件的監控和管理至關重要。
2.實用容器
容器技術使你能夠對環境的所有依賴關系進行打包，多虧了Docker插件，你可以在Docker容器中運行Jenkins。Docker容器可以使用為任務創建的映像并充當Jenkins代理，完成構建所需的所有依賴項，從而無需在服務器上安裝插件。
3.使用更少的插件
Jenkins插件問題的一個最簡單的解決方案就是使用更少的插件。使用的插件越少，問題就越少。為了達到該目的，你可以選擇腳本而不是插件。例如，發送Slack通知就像發送一個HTTP請求到一個API一樣簡單，并且可以避免依賴第三方插件。腳本可能比插件更可靠，因為你可以在本地使用它們來執行相同的操作。雖然這看起來比使用插件需要更多的工作，但你可以在公司內部共享你的自動化腳本，并在任何管道中使用它們，且不影響Jenkins服務器。
第二種方法是盡可能多地使用Jenkins模板(Jenkins templates)。模板允許你定義可重用的管道(任務)片段，并添加一個抽象層，使開發人員更容易配置和使用Jenkins。使用模板為你提供了一種識別所需插件的簡單方法，因為你需要的插件是模板中引用的插件。這為你提供了一個協作構建管道的地方，并減少了跨組織使用的插件數量。
總結
Jenkins及其插件生態系統對于尋找項目中CI/CD解決方案的人非常有吸引力。然而，不利的插件維護、多種不同的依賴關系和安全風險已經使許多人對該工具產生了反感。
Jenkins插件管理將會影響你的企業，而管理不善的插件會使你的企業處于危險之中。實施緩和策略非常重要，比如通過定義標準作業或管道來最小化插件數量，仔細管理插件，在單獨的實例上測試插件和升級，以及使用基于容器的作業來減少對Jenkins插件的依賴。
如果你厭倦了管理你的CI/CD生態系統，包括你的Jenkins服務器，你可能會對一個無代碼的DevOps平臺感興趣，它可以取代許多Jenkins插件。這樣的平臺還可以連接你現有的工具，提高你團隊的敏捷性和響應性，并允許你專注于創建優秀的軟件，而不是管理你的管道。
譯者介紹
趙青窕，51CTO社區編輯，從事多年驅動開發。研究興趣包含安全OS和網絡安全領域，發表過網絡相關專利。
原文標題：Why You Should Stop Relying on Jenkins Plug-ins
鏈接：?https://dzone.com/articles/why-you-should-stop-relying-on-jenkins-plugins-2??
