DevOps is Hard、DevSecOps is Even Harder --- Enterprise Holdings.
Enterprise Holdings. 的IT團隊超過2000人，在2018年的演講中介紹了Enterprise Holdings的DevOps是如何轉型的。咱們經過打造一個不僅包涵了pipeline的CI/CD平臺，將其稱之爲SDLC。在最開始的200+個應用中，咱們挑選出5個來做爲試點。當時的狀況證實此次DevOps轉型計劃是成功的，咱們的團隊有4+位工程師和兩位架構師，從2年半前就開始了整個平臺的開發工做，根據業務需求確保平臺能夠適配各類雲服務、也要適配已有的中間件，咱們也在不斷對CI/CD平臺進行改進，以適應全部業務場景。其的目標是讓開發人員更專一於具體的項目開發，讓工具去解決一些通用性的問題。爲了達到目前的效果，咱們作了不少關於平臺的需求收集及問題反饋相關的運營工做，因此在過去的一年裏，咱們已經將此套平臺服務於70%的應用中，而且這個數字還在持續的增長。git
在DevOps轉型過程當中，咱們的角色並非軟件的開發者，但咱們支撐了應用開發團隊和他們所開發的應用，咱們的服務工做介於應用程序與基礎設施之間。在咱們的角度來看，應用程序的開發應該是這樣的：json
- 開發人員在本地開發
- 在倉庫中檢查源碼
- 在構建服務器上構建應用
- 運行安全掃描
- 打包發佈到JFrog的Artifactory
- 發佈應用到不一樣的環境測試
- 全部測試結束後，發佈到生產環境
這個模式很簡單，可是也很高效，可是爲了實現這個流程作了很是多的事，咱們開發了一些被稱之爲共享庫的模版，並將此和打包程序、自動化腳本、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裏，這樣的方式保證咱們的應用有一點點安全性。maven
在部署過程當中咱們存在的最大的一個問題就是，每次部署不只僅部署一個應用，可能會涉及到不少應用同時發佈，咱們爲了處理這個問題，讓應用運維團隊去梳理了應用程序間的依賴關係，以及部署的順序。而且維護了一個清單來對整個發佈進行說明。Jenkins會按照這些事先定義好的清單來進行發佈 ，並收集到過程當中的問題、哪一個stage失敗、是否影響到了其餘的任務等等。並把這些問題同步到pipeline中以及Artifactory的元數據上。咱們給了全部開發者對jenkins的只讀權限，這樣能夠確保全部的相關開發者均可以看到這些問題，並及時對問題進行修復。咱們經過這種方式，把一次發佈由4小時縮減到1小時。微服務
那麼接下來，咱們要保障的就是每一個人都按照這個標準去執行就能夠了6工具
接下來咱們談論一些安全的話題
安全是咱們組織中很是重要的一部分，實施起來也有不少困難。在咱們缺少安全意識的時候，咱們都使用普通用戶。這些普通用戶，實際上擁有這些流程運行的權限。應用程序的團隊甚至能夠隨意去使用有漏洞的組件，每當咱們檢查到這些問題的時候，每每這些問題已經被引入到測試環境和生產環境了，咱們須要使用到不少開源軟件，可是引入這些開源軟件須要花費至少一個月的時間去評估它的安全問題是否會對咱們的應用程序帶來影響，這樣的流程是與敏捷開發模式不符合的。
每一天都有很是多的漏洞被提交到公網上，因此咱們但願咱們的安全問題不該該僅僅由安全團隊負責，開發、測試、運維團隊的全部工程師都應該對安全重視起來，因此咱們選擇把安全掃描放到咱們的CI/CD流水線裏。咱們強制全部應用流水線中必須增長安全掃描，若是沒有這個stage，那麼這條流水線是沒法經過的。雖然開始的時候你們不肯意接受，可是過了一段時間，開發人員發現安全團隊找他們修復漏洞的這種事變得愈來愈少，你們也就慢慢常態化了安全掃描這個步驟。這樣安全團隊也將專心的把時間花費在研究漏洞對應用程序的影響上，減小了與開發團隊測試團隊的溝通成本。另外咱們制定了流水線安全的SLA，來定義一個構建的全部依賴是否知足上線需求。在這個過程也不是徹底順利的，咱們發現每條流水線裏都進行安全掃描很是花費時間和資源，因此咱們改進了方案，每次掃描只掃描一些新的依賴、組件以及新的漏洞特徵，這樣也大大的提升了安全掃描的效率。
將來工做中，咱們會繼續與咱們全部支持的團隊保持持續的溝通，咱們要隨時瞭解支持的團隊的全部想法和產品，結合實際狀況，向他們展現咱們的CICD平臺是如何給他們帶來收益的，確保最終每一個團隊均可以採用咱們的最佳實踐，主動來接入咱們的平臺。總結來講，你所知道完整的CI CD應該是這樣的，它不只是開發，不只是安全，更是運維、測試。因此pipeline基本等同於一切。咱們真的想確保咱們全部的過程的設計是安全的，這是咱們團隊每一個人的目標，咱們真正專一於在基礎設施團隊內部全面整合。整合內容包括服務器環境、網絡、技術棧等等，而實際上這些整合都是依賴於咱們的CICD平臺建設的。
更多技術分享請關注 JFrog傑蛙在線課堂
1月14日在線課堂：《JFrog免費社區版容器鏡像倉庫JCR—功能介紹及實踐》
課堂收益：
1. 瞭解JCR的優良特性和強大能力
2.經過示例演示，掌握如何利用JCR更好地支持微服務及Kubernetes應用的開發和部署
報名連接：https://www.bagevent.com/event/6334008
抽獎活動：
課堂結束前五分鐘，進行抽獎活動
第一名：小愛音箱
第二名：JFrog傑蛙新版T恤
第三名：JFrog傑蛙新版T恤