得先了解配置管理和持續部署工具的演變，便於更清晰直觀看到Docker毆打傳統持續交付的場景 – Girish Shilamkar

21世紀的第1個10年是一段有趣的光輝歲月，當時很多組織機構正著眼於基礎設施自動化的發展以及在不斷搭建持續整合/交付的體系。當時Chef（成立於2008年）和Puppet Labs（成立於2005年）在基礎設施自動化早期的演變階段獨領風騷。

雖然Jenkins出來有一些歲月了，但較於持續整合，它在持續交付方面倒是發展得晚一些，不過並不影響它的廣泛應用。Jez Humble在2010年出版的《持續交付》像一本行業聖經，你可以清楚看到企業級CD工具的興起。

比如前幾年，考慮到IBM在2013年收購UrbanCode平臺，CA於2013年收購了Nolio，Xebia Labs在2008年成立……等等都彰顯這是PaaS平臺崛起的時代。不過，後面發生可一件有趣的事：CloudFoundry，GAE App Engine，DotCloud，Heroku以及更多組織機構聯合起來卻在提升交付效率上撞了一鼻子灰。

俗話說，命中有時終會有。2013年，並行發展（parallel development）橫空出世並KO了IBM和CA等一票玩家。這個歷史程序極其重要，它徹底改變了軟體開發和部署方式。

沒錯，就是Docker元年。從那時起，經過幾年摸索，容器成了今天部署應用的公認方式。（其實我覺得，像Kubernetes，Mesos和Swarm這樣的專案正在領跑規模化運營新規則）

基於CD pipelines的配置管理跑Nolio設計的Chef cookbooks / Puppet模組和工作流程會怎麼樣？這是我們要在文章中更深層次瞭解的一些疑問。

一、配置管理和持續部署工具的演進

對於部署任何的應用，都有兩件事至關重要：應用程式碼/執行應用的執行態和平臺。

通過基於使用者介面（UI）或基於特定語言（LAN）的持續部署（CD）工具和相關配置管理工具提供的底層基礎架構解決了各種元件的工作流和編排。

基礎設施程式碼基於一些DSL（領域專用語言），並且將為執行應用程式所需的各種堆疊/執行時編寫指令碼/手冊。只不過相應的，在相當複雜的企業設定中，為給定應用程式設定執行時間所需的指令碼/手冊數量可能很多。

二、DevOps：我們支援到位了嗎？

根據我們在配置管理專案中的經驗，開始和開展統一工作的出發點並不一定能夠解決所有問題。我們來看一些具體的例子。

管理依賴關係：現在用於基礎架構：

配置框架採用DSL語法編寫模組，因為它們經常被呼叫。對於一個相當複雜的企業來說，這些執行手冊的數量級很容易跑到幾百個，甚至更多。

現在，要組合應用程式，您可能要有多個規範 – 而且管理依賴項及其版本又會變成新的問題。

一些新的解決方案（像Berkshelf）在Chef中管理依賴項，但這意味著要學習和實施另一套工具……自然而然，開發就會有一個陡峭的學習曲線。這也導致一些公司建立了特殊的“DevOps”團隊，這對於DevOps本身來說就很“反進化、反直覺”。

基礎設施即程式碼

編寫和除錯基礎設施程式碼與應用的程式設計差異很大。論呼叫難度可能不是很具體公正，但編寫基礎設施的程式碼就挑戰滿滿。例如，少了成熟工具、需要很細化的基礎設施細粒度知識等…往往就是這些雞毛蒜皮的小需求，讓程式碼變得亞歷山大。而且，諸如失敗的依賴應用程式包轉儲的錯誤就很具有隱藏性，如果不瞭解，就像自駕遊缺了個地圖。

而且經過實踐，我發現一個不太好的訊息，從頭開始設定應用比除錯更加明智，尤其是需要快速解決問題的時候。可能這就是所謂重灌大法的魅力吧。

三、到毛線！

基礎設施自動化工具的發展確實有助於基礎設施實現自助，但並沒有解決孤島問題。且基礎設施有一定專業門檻，這意味著至少有部分團隊得專門處理基礎設施。

問題以轉變做事方式（基礎架構自動化的DSL）的形式從一個團隊轉移到另一個團隊。但是對於開發一方來說，基礎設施仍然是一個難以透徹的地方，但現實逼迫著你不精不行。

在基本層面上，應用程式仍然要打包，因為它依賴這個形式。例如，JAR，Gem或Py包 – 由單獨工具和打包格式建立。

四、大一統的力量：Docker (容器)

容器和Docker的成就之一是應用和基礎設施需求的統一包裝。無論是本地還是在生產叢集上執行的應用程式，都能擁有相同的Docker映像。

使用Docker，應用終於實現自包含，也就是能以簡單的宣告方式打包應用程式程式碼以及基礎架構依賴。再者從開發人員的角度來看，這個技術既不費力又討巧。

這麼看來，容器幾乎是自帶光環來到人間，它更加輕巧和分層，使得layers也能被快取起來。一旦開發完成，它可以簡單地將影象推送到登錄檔。從操作的角度來看，這是一個更簡單的格式：不需要執行容器影象所需的長文件或cookbooks……而這所有，你只需要的是一個容器映象和一些元資料，如環境變數等其他相關的東西。

使用Docker，大量的配置管理程式碼被Docker映象和Dockerfiles取代，同時也簡化了對應用程式依賴關係的管理，因為無需編寫大量的應用配置程式碼，哪怕這幾乎不會出現改變。

從可操作性的角度來看，新操作可以專注於構建一個可以執行容器和管理平臺的“地基”。至於建立和維護平臺，則可以將配置管理平臺跟用於容器的新平臺結合使用。這也對Mesos，Kubernetes，Swarm等容器造成一定影響，甚至以及Rancher，OpenShift等容器平臺。

五、最後還要說點什麼？

上面說了容器那麼厲害，那是不是採用容器之後我們就解決了軟體交付的所有問題？那當然不是！但是，我們已經更接近應用的可移植性和自主持續的CD管道，這將真正實現DevOps的目標。

當然，這裡也會有一些新挑戰，例如怎麼在一組大型虛擬機器上編排容器？當一個容器短暫轉移動到另一個機器時，一個服務怎麼樣去發現另一個服務？怎麼通過容器移動來管理持久儲存？

文章來自微信公眾號：DevOps研究院