過去十多年間,我的主要工作是負責搭建、部署和執行後臺系統。剛開始是搭建PHP web服務,緊接著,謝天謝地,有了Ruby on Rails。幾年後,我投入到用Ember.js建立單頁web應用,但不久,又做回後端及服務相關的工作。
由於之前所在公司在Docker 1.0版之後不久就全部使用Docker,所以團隊和我本人經歷了Docker的整個發展過程。我在那家公司做的最後一個專案是,用Kubernetes替換所有手動部署的Docker編排系統。這充滿了挑戰,但也學到了很多寶貴的經驗。現在,我想透過我的故事跟大家分享一些關於生產環境下使用、開發和執行容器的經驗。
當初選擇使用容器,主要基於兩點。第一是內部重組和自底向上重新設計產品;第二是Docker出了1.0版。我們決定使用Docker,不僅是因為Docker支援我們的多語言系統,同時還具備標準的操作工具。九個月後,新系統在生產環境上線。由於沒有可用的編排系統,部署基礎設施部分的建立工作成為了當時的難點。那期間,Docker社群主要關註的是如何改善開發流程上,還沒有涉及到生產環境。雖然我們的配置存在很多問題,但我們學會了變通。頭兩年,這套系統一直運轉良好,直到事情出現了變化。
這個變化就是對更低價的系統的需求。然而,團隊裡誰也沒有足夠的信心去修改我們定義好的這套系統。幸運的是,這時我們有了更多的選擇。生產環境下已經可以使用Kubernetes、Docker Swarm和Mesos這樣的容器編排技術。我們集中主要的精力在Kubernetes上搭建了一個Helm chart build pipeline[1]。六個月之後,我們的系統在生產環境上線。系統的更新換代讓我們充滿了成就感,但這並不意味著零失誤。
我的這個故事裡都是經驗教訓。事實上,它包含了大量的失誤、工程的妥協、成功以及徹底的失敗。當然,那時的某些決策還是很明智的,這也是系統還在生產環境執行的原因。我沒想說服誰,只想分享一個真實的故事,從Docker 1.0開始使用容器,一路走來的風雨歷程。接下來,我將分三部分說明:使用、開發流程和生產運營。
事後證明,我們當初選擇Docker是正確的,但是時間點有問題。之後,選擇遷移到Kubernetes時,我們又重蹈覆轍。無論是選Docker還是選Kubernetes,事先都沒有對所支援的工具進行充分的調查。雖然Docker和Kubernetes都執行的很好,但是我們沒有考慮到整個上流和下游的技術,它們在這個過程中的相互影響。這點,對於早期的使用者來說,必須慎之又慎。
我就是那個早期的使用者,所以有一些心得體會。在採用Rails和Ember.js時,選擇Docker吧。Rails意味著用新方法開啟CRUD應用程式世界;Ember.js則需用新方法實現新的單頁web應用,那更麻煩。選擇Docker需要一個新的策略,因為它創造了一個新的典範。
我不會再做傻事,像之前遷移到Kubernetes之類的事,下次我會提前調查清楚。在那種情形下,我認為最好的方式是等待,直到圍繞核心技術開始出現相應的支援工具。想想現在有那麼多現成的工具,諸如Docker Compose、Docker Machine、Kubernetes、Helm之類。如果你是一個早期的使用者,那你需要自己建立和測試這些工具。捫心自問:你是否真的願意付出那些額外的努力?還有,真的有這個必要嗎?
容器的使用改變了我的開發流程。對此,起初難免有些驚訝,事後想想也能理解。自從所有的開發工作都放進了容器裡,我的心理也發生了轉變。這也是必須的,因為不同的服務使用不同的語言和工具。
整合開發流程[2]極大推動了整個開發流程的改進。我可以在任何一個專案/框架/語言下,進行TDD和影響重大的冒煙測試,也可以對專案進行一連串全新的測試。現在我可以在一個容器裡啟動一個伺服器端,在另一個容器裡啟動一個測試用客戶端。當我的註意力從測試程式碼轉移到測試流程,生產環境的回歸測試也大量減少。
之所以發生這一轉變,是因為在過去的一年裡,我一直在使用容器,並將它應用到越來越多的領域。如果一個團隊只是在工作流的最後建立了映象,決不會發生這種轉變。所以,如果你剛開始接觸容器,最好全心投入,努力建立一個完全容器化的工作流。你可以問一下自己:怎樣才能把一個東西容器化?這個問題可以幫你梳理出相應的軟體和工作流程。總之記住,一定要容器化!容器化!容器化!重要的事情說三遍~
根據我的經驗,容器已經實現了它的核心價值。與以往相比,容器讓無數不同的應用、語言和框架以極其簡單的方式,毫不費力地部署到生產環境。它是如此成功,我都無法想象如果沒有容器,生產環境該如何運轉。Kubetnetes將成為分散式應用的標準平臺。現如今,3家大的雲供應商提供了各具特色的編排工具。大家的註意力開始從解決預生產環境的工作流程問題,轉移到解決生產環境問題,這點令人欣慰。事情正在一天天變好。
同時,這也說明,生產環境上使用這些工具執行容器,還處於起步階段——還得幾年吧。比較一下容器和JVM,你會明白我在說什麼。我的建議是先假設這些技術可以為你所用,然後找原型和小規模專案,對假設進行驗證。不論你喜歡與否,生產環境上用編排技術執行容器,需要理解和適應分散式系統。在開始前,確保你已經做好準備接受轉變。
選擇使用容器,絕對是我職業生涯中最重要的決定。我很開心因為我學到了一種非常有用的新技術,與此同時,也為研究、選擇和實施下一個的新興技術做好了充分的準備。在面對下個新技術的時候,我一定會保守行事。不是因為技術,而是我猜我還有別的工作要做。如果你有大把大把的時間玩新技術,感覺還是蠻不錯的,但如果有人拿槍指著你,感覺就大打折扣了。
我看到了地平線上的曙光。部署和管道管理工具,諸如Helm和Spinnaker是下一波浪潮。我希望在我跳進去之前,它們已經被擺平了。我不再著急,隨著時間的流逝,這些新技術和我,都會迎來自己的時刻,我們都將變得更好。我相信隨著它們日趨成熟,新一代的團隊在經歷持續部署和多語言環境時會更加輕鬆自如。這勢必會推動更多的團隊朝著DevOps方向發展,從而形成一股DevOps價值流,這才是它真正的價值所在。它們帶給我的,同樣也能帶給你啟發和幫助。祝好運!
-
https://engineering.saltside.se/building-our-helm-chart-e10da063581c
-
http://blog.slashdeploy.com/2016/11/06/docker-project-boilerplates/
原文連結:http://www.iamondemand.com/blog/went-containers-fails-along-way/
本次培訓內容包括:容器原理、Docker架構及工作原理、Docker網路與儲存方案、Harbor、Kubernetes架構、元件、核心機制、外掛、核心模組、Kubernetes網路與儲存、監控、日誌、二次開發以及實踐經驗等。
長按二維碼向我轉賬
受蘋果公司新規定影響,微信 iOS 版的贊賞功能被關閉,可透過二維碼轉賬支援公眾號。