DevOps is Hard、DevSecOps is Even Harder. --- Enterprise Holdi

Enterprise Holdings. 的IT團隊超過2000人，在2018年的演講中介紹了Enterprise Holdings的DevOps是如何轉型的。我們透過打造一個不只包涵了pipeline的CI/CD平臺，將其稱之為SDLC。在最開始的200+個應用中，我們挑選出5個來作為試點。當時的情況證明這次DevOps轉型計劃是成功的，我們的團隊有4+位工程師和兩位架構師，從2年半前就開始了整個平臺的開發工作，根據業務需求確保平臺可以適配各種雲服務、也要適配已有的中介軟體，我們也在不斷對CI/CD平臺進行改進，以適應所有業務場景。其的目標是讓開發人員更專注於具體的專案開發，讓工具去解決一些通用性的問題。為了達到目前的效果，我們做了很多關於平臺的需求收集及問題反饋相關的運營工作，所以在過去的一年裡，我們已經將此套平臺服務於70%的應用中，並且這個數字還在持續的增加。

在DevOps轉型過程中，我們的角色並不是軟體的開發者，但我們支撐了應用開發團隊和他們所開發的應用，我們的服務工作介於應用程式與基礎設施之間。在我們的角度來看，應用程式的開發應該是這樣的：

l   開發人員在本地開發

l   在倉庫中檢查原始碼

l   在構建伺服器上構建應用

l   執行安全掃描

l   打包釋出到JFrog的Artifactory

l   釋出應用到不同的環境測試

l   所有測試結束後，釋出到生產環境

這個模式很簡單，但是也很高效，但是為了實現這個流程做了非常多的事，我們開發了一些被稱之為共享庫的模版，並將此和打包程式、自動化指令碼、ansible指令碼等一起儲存到原始碼倉庫中進行版本管理，同時提供給應用團隊去使用。為了支撐我們的應用團隊按上述流程實踐，我們使用了很多工具。

       持續整合工具鏈包括：git、maven、gradle、Artifactory、Bitbucket、BlackDuck、jenkins

       持續交付工具包括：Ansible、jenkins、Bitbucket、Artifactory、Oracle、Tomcat等。

工具使用簡單，所以就會有人告訴你DevOps是簡單的，但這種說法是不負責任的，不能認為使用了某個工具，我們就實踐了整個DevOps理念。我們公司的it團隊由超過2000人組成，這些人開發了大量的應用程式，我們要保證整個團隊都能正常的工作。雖然每個團隊使用的技術棧不同，使用的平臺不同，但我們需要找到這些人的共同點，以便在我們的DevOps平臺上更好的適配所有團隊和開發者以及超過200個的應用。我們需要保證所有人都能應用我們的平臺，並且保障平臺實時可用，為此我們在jenkins的上面使用groovy開發了很多pipeline模版、自動化指令碼、jenkinsfile等供其他團隊使用。這樣我們就能引導開發人員使用工具的時候是按照我們指引的方式去使用的，並且在這個過程中我們設定了很多關卡，明確告訴了開發人員如果進行這些校驗、他們的應用程式是無法正常的被構建的。這樣的結果就是，開發人員使用我們定義好的模版，自動進行安全掃描，收集後設資料，並把應用包上傳到Artifactory中統一管理。之後我們的團隊就可以透過這些後設資料所收集的結果，去反查到你的應用程式包括什麼。我們在模版中維護了一個json串，告訴你這個模版會做什麼事、收集什麼資料。

上面都是說的CI的內容，接下來我們討論下CD。很遺憾，到目前為止我們仍然沒有辦法將所有的CD流程自動化，我們有太多的開發場景和平臺，有大量複雜的工作等著我們去做。在我們的CD體系中ansible負責了大量的工作，我們使用jenkins去管理我們的釋出流程、並透過ansible去執行釋出任務，最重要的是，我們收集了部署中的資料（如釋出的環境、釋出的時間、測試的結果等等），並把這些資料以後設資料的方式回寫到Artifactory中。在這個過程中你需要定製開發一些自動化的測試指令碼，並把他們應用到pipeline中。

我們的構建任務執行在一個jenkins中、測試任務執行在另一個jenkins裡，這樣的方式保證我們的應用有一點點安全性。

在部署過程中我們存在的最大的一個問題就是，每次部署不僅僅部署一個應用，可能會涉及到很多應用同時釋出，我們為了處理這個問題，讓應用運維團隊去梳理了應用程式間的依賴關係，以及部署的順序。並且維護了一個清單來對整個釋出進行說明。Jenkins會按照這些事先定義好的清單來進行釋出 ，並收集到過程中的問題、哪個stage失敗、是否影響到了其他的任務等等。並把這些問題同步到pipeline中以及Artifactory的後設資料上。我們給了所有開發者對jenkins的只讀許可權，這樣可以確保所有的相關開發者都可以看到這些問題，並及時對問題進行修復。我們透過這種方式，把一次釋出由4小時縮減到1小時。

那麼接下來，我們要保障的就是每個人都按照這個標準去執行就可以了。

接下來我們談論一些安全的話題

安全是我們組織中非常重要的一部分，實施起來也有很多困難。在我們缺乏安全意識的時候，我們都使用普通使用者。這些普通使用者，實際上擁有這些流程執行的許可權。應用程式的團隊甚至可以隨意去使用有漏洞的元件，每當我們檢查到這些問題的時候，往往這些問題已經被引入到測試環境和生產環境了，我們需要使用到很多開源軟體，但是引入這些開源軟體需要花費至少一個月的時間去評估它的安全問題是否會對我們的應用程式帶來影響，這樣的流程是與敏捷開發模式不符合的。

每一天都有非常多的漏洞被提交到公網上，所以我們希望我們的安全問題不應該僅僅由安全團隊負責，開發、測試、運維團隊的所有工程師都應該對安全重視起來，所以我們選擇把安全掃描放到我們的CI/CD流水線裡。我們強制所有應用流水線中必須增加安全掃描，如果沒有這個stage，那麼這條流水線是無法透過的。雖然開始的時候大家不願意接受，但是過了一段時間，開發人員發現安全團隊找他們修復漏洞的這種事變得越來越少，大家也就慢慢常態化了安全掃描這個步驟。這樣安全團隊也將專心的把時間花費在研究漏洞對應用程式的影響上，減少了與開發團隊測試團隊的溝通成本。另外我們制定了流水線安全的SLA，來定義一個構建的所有依賴是否滿足上線需求。在這個過程也不是完全順利的，我們發現每條流水線裡都進行安全掃描非常花費時間和資源，所以我們改進了方案，每次掃描只掃描一些新的依賴、元件以及新的漏洞特徵，這樣也大大的提高了安全掃描的效率。

            未來工作中，我們會繼續與我們所有支援的團隊保持持續的溝通，我們要隨時瞭解支援的團隊的所有想法和產品，結合實際情況，向他們展示我們的CICD平臺是如何給他們帶來收益的，確保最終每個團隊都可以採用我們的最佳實踐，主動來接入我們的平臺。總結來說，你所知道完整的CI CD應該是這樣的，它不僅是開發，不僅是安全，更是運維、測試。所以pipeline基本等同於一切。我們真的想確保我們所有的過程的設計是安全的，這是我們團隊每個人的目標，我們真正專注於在基礎設施團隊內部全面整合。整合內容包括伺服器環境、網路、技術棧等等，而實際上這些整合都是依賴於我們的CICD平臺建設的。

 

更多技術分享請關注 JFrog傑蛙線上課堂

1 月14日線上課堂：《JFrog免費社群版容器映象倉庫JCR—功能介紹及實踐》

課堂收益：

1. 瞭解JCR的優良特性和強大能力

2. 透過示例演示，掌握如何利用JCR更好地支援微服務及Kubernetes應用的開發和部署

報名連結：

 

抽獎活動：

課堂結束前五分鐘，進行抽獎活動

第一名：小愛音響

第二名：JFrog傑蛙新版T恤

第三名：JFrog傑蛙新版T恤