采用DevOps方式實現軟件交付的原因之一是為了消除生產部署過程中的瓶頸，對于服務器端軟件，通常涉及以下部分：
應用程序環境，如操作系統參數第三方組件，如應用程序服務器，web服務器和數據庫頂部運行的應用軟件為了消除部署瓶頸，DevOps旨在打破開發人員和IT運營人員之間的障礙（也是DevOps得名的原因），以促進協作的工作環境。因此，需要確保生產環境與開發環境保持同步，并且所有部署過程一起執行。實現這一目標的方式之一是通過使用容器，如Docker或Kubernetes。事實上，很多人將容器和DevOps理解成了同義詞，并且將這兩者建立了依賴的關系。
但是，這兩者不需要依賴關系：完全可以在非容器環境下實現DevOps。
容器是管理運行軟件的操作系統的輕量級的抽象，它能夠將進程彼此隔離，對資源使用加以限制，并幫助打包軟件依賴。容器不會替代虛擬化，因為容器的操作更接近應用程序級別，而不是物理級別。
容器的高效率使得它應用非常廣泛，通過容器用戶可以快速部署并實現軟件組件聯機，與虛擬化相比它能夠以較低的成本啟動新的應用案例，用戶可以更緊密地控制應用程序環境。例如，如果開發人員在容器中編寫和構建軟件，則容器及其中的一切都可以被打包并傳輸到生產服務器。效率和自動化使得DevOps和云運行良好。
容器中好的DevOps用例始終圍繞著快速上線新服務器連接的需求，這通常是微服務部署的案例。容器可以非常有效地快速啟動和破壞微服務和開發/測試環境，除此以外，在DevOps中使用容器更多的是一個選擇，而不是一個需求，DevOps遠不止目前這些。
非容器環境下無痛部署不管容器能帶來多少好處，有很多理由支持我們不采用容器化的方法來進行軟件部署。包括：
缺乏容器技能或相關知識特殊應用性能要求（即實時系統）實用軟件環境下不支持的硬件（即嵌入式系統，專用或傳統操作系統）公有云部署等等不依賴容器來實現DevOps的成功，需要關注以下3點：
1、自動化：通過工具盡可能地實現自動化，無論是大型機應用程序還是微服務，都可以通過工具來減少手動工作量及其失誤。
2、持續集成：連續測試軟件模塊、組件、服務等，不要等到開發結束之后才集成和部署系統。
3、連續測試：通過持續集成，確保系統始終可用、可測試且理論上可釋放，測試開發工作的結果是反饋循環的一部分。
特定的構建和部署工具是有幫助的，并且通常需要達到使部署簡化的自動化水平。然而，DevOps的最大成就主要來自于三個方向的努力：
持續開發構建和測試周期更頻繁地部署到生產服務器直接和即時反饋給開發人員通過這三個努力，軟件永遠不會被孤立地構建，組件不斷地進行集成，而且每個人都能知道需要改進的地方一切正常。因此，開發和IT部門可以保證正在構建的內容將按照預期的方式進行部署和運行。業務上線的過程中就在不斷地突破瓶頸，因為在部署過程和生產環境中伴隨著軟件的測試，因此在開發周期結束時可以正常使用。
人員是DevOps成功的關鍵成功的關鍵不是工具集，而是人員、溝通和度量。因為使用DevOps實踐，當開發新版本的軟件時間被限制在幾周或者幾個月內，在最終期限到來的時候，用戶不用擔心軟件的部署對生產造成的影響，因為在開發過程中一直在進行測試。
這就是為什么它被稱為DevOps實踐，而不是DevOps過程、DevOps組、DevOps工具集或DevOps環境。容器可是成為DevOps實踐的一個補充，幫助管理生產環境，但它不應該是DevOps必須的。相反，專注于DevOps實踐，并在這個過程中使用容器才有意義。
原文鏈接：http://www.informationweek.com/devops/implementing-devops-without-containers/a/d-id/1328336
京公網安備 11010502049343號