採用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實踐，並在這個過程中使用容器才有意義。
在非託管環境中呼叫託管物件
如果要在mfc專案中支援託管擴充套件，可以使mfc工程通過開啟專案的託管擴充套件屬性開關。在開啟託管擴充套件編譯開關以後，你就可以在mfc專案中使用託管物件了，通常的做法是 為每個重要的mfc物件匹配乙個託管物件以形成乙個對偶對，彼此匹配的物件包含指向對方的指標，這樣，其他.net物件可以通過對偶對...
在Docker構建的容器中實現安裝ping工具
因為用docker拉取的base映象如centos和ubuntu的話都是最簡版本，不包含ping工具，而對docker進行docker network和docker鏈結操作時往往要用到ping工具測試兩個容器間的網路，此時就要用到ping工具了，下面是ubuntu下安裝ping工具的命令 sudo ...
在docker容器中手工部署go環境和專案
方案分析 1.docker環境部署 2.go環境部署 3.go專案部署 4.測試 1.docker環境配置 1.1 獲取乙個ubuntu的模板檔案 1 進入模板映象 2 找到ubuntu模板 ubuntu 16.04 x86 64.tar.gz 178m 1.2 啟動docker容器，容器名叫go ...