Docker和Kubernetes如何讓DevOps更具效力
縮短time-to-makrt對於任何一家企業都至關重要，這直接決定了客戶滿意度、市場競爭力乃至盈利能力。但在部署應用時，大多數企業內的IT團隊都或多或少會遇到Dev和Ops之間的問題，這兩個部門圍繞著同一個應用工作，但工作方式卻截然不同。
很多管理者都在思考如何能讓Dev和Ops能夠在沒有任何“誤解”的情況下共同努力縮短time-to-market，也就是DevOps。
下面我們將談一談，Docker和Kubernetes如何幫助DevOps發揮更大效力。
傳統的DevOps
在傳統的DevOps方法中，開發人員編寫程式碼並將其提交給Git儲存庫，然後檢查它在本地和開發環境中的工作方式。
我們會使用像Jenkins這樣的CI工具啟動程式碼的構建過程，該工具也在構建期間執行功能測試。如果測試成功通過，我們將更改合併到釋出分支中。
運維會使用一些工具為應用程式部署生產準備指令碼，並最終將更改投入生產環境（更新版本）。
傳統DevOps的問題
第一個問題是運維和開發者使用不同的工具。例如，大多數開發人員不一定知道如何使用指令碼工具，而準備釋出的任務落在運維身上，但運維通常又不瞭解應用如何工作。
第二個問題是開發環境通常手動更新而沒有自動化。結果導致開發環境非常不穩定，一個開發人員所做的更改可能會中斷另一個開發者的更改，而解決這樣的衝突問題通常需要花費很多時間，time-to-market變長也就不足為奇了。
第三個問題是開發環境可能與staging環境、生產環境有很大不同。這可能會導致開發人員準備的發行版可能無法在暫存環境中正常工作，或即使測試在暫存環境中成功通過，生產中也可能會出現一些問題，生產中的回滾過程也並非易事。
第四個問題是編寫指令碼非常耗時，而且容易出錯。
利用Docker優化DevOps
Docker之於DevOps的主要優點是開發人員和運維都使用相同的工具——Docker。開發人員在開發階段，在本地計算機上從Dockerfiles建立Docker映象並在開發環境中執行。
運維使用相同的Docker映象，使用Docker對staging和生產環境進行更新。需要注意的是，在更新到軟體的新版本時，我們不是要對Docker容器進行patch，換句話說軟體的新版本採用一個新的Docker映像和Docker容器的新副本，而不是對舊的Docker容器進行修補。
基於以上，我們可以建立不可變的開發、staging和生產環境。
使用這種方法有幾個好處：首先，對所有更改都有很高的控制權，因為使用不可變的Docker映象和容器進行更改，我們您可以隨時回滾到以前的版本；與指令碼工具相比，開發、staging和生產環境變得更加相似；使用Docker，我們可以保證如果某個功能在開發環境中有效，它也可以在staging和生產中使用，這也就是我們常說的一致性。
那麼，Docker和Kubernetes如何讓DevOps變得更具效力
- 使用Docker建立包含多個相互連線元件的應用拓撲的過程變得更容易理解
- 由於內建的service和ingress概念，負載均衡配置的過程大大簡化
- 由於Kubernetes的Deployments、StatefulSets、ReplicaSets等功能特性，滾動更新或是藍綠部署的過程變得非常簡單
- 更多強大的CI/CD工具可用
- Kubernetes通過Service Mesh工具提供開箱即用的多雲部署場景
關於Rainbond
>Rainbond （雲幫）是"以應用為中心”的開源PaaS， 深度整合基於Kubernetes的容器管理、ServiceMesh微服務架構最佳實踐、多型別CI/CD應用構建與交付、多資料中心資源管理等技術， 為使用者提供雲原生應用全生命週期解決方案，構建應用與基礎設施、應用與應用、基礎設施與基礎設施之間互聯互通的生態體系， 滿足支撐業務高速發展所需的敏捷開發、高效運維和精益管理需求。