如何更好地使用容器技術實現不可變基礎設施
不可變基礎設施的構想
不可變基礎設施（Immutable Infrastructure）是由 Chad Fowler 于2013年提出的一個很有前瞻性的構想：在這種模式中，任何基礎設施的實例（包括服務器、容器等各種軟硬件）一旦創建之后便成為一種只讀狀態，不可對其進行任何更改。如果需要修改或升級某些實例，唯一的方式就是創建一批新的實例以替換。這種思想與不可變對象的概念是完全相同的。
實現這種模式的好處是顯而易見的，這意味著配置工作可實現重復性，減少了配置管理工作的負擔，讓持續集成與持續部署過程變得更流暢。同時它也更易于應對部署環境間的差異及版本管理，包括在部署出錯時可進行快速回滾 —— 只要舊版本的鏡像文件還有備份，就可以快速地生成舊版本的實例進行替換。否則的話，就只能老老實實地重新構建舊版本的實例，并且祈禱能夠趕在老板掀桌之前完成回滾。
實現這一模式需要滿足兩點基本需求，首先應用程序必須是 無狀態的 ，不可依賴于本地的文件上傳、會話與緩存。基本上，如果應用程序要實現負載均衡，都必須滿足這一點。而更重要的一點是，能夠通過某種 模板 （或指令）將實例快速地部署到生產環境中。后一點無疑是關鍵所在，也是這一模式的最大挑戰。
雖然這種模式能夠帶來很大的好處，但實現它的難度也是很高的，傳統的虛擬化技術在應對這一模式時顯得有些力不從心。幸運的是，DevOps社區發現Docker（或者說容器）正是實現這一模式的優秀選擇。
使用容器實現不可變基礎設施
來自Tutum的 Fernando Mayo 近期在一篇博客中詳細地論述了使用容器技術實現不可變基礎設施的優點。他首先指出，容器并不是實現這一模式的唯一選擇，使用虛擬機模板、或者通過Chef 與Puppet這樣的配置管理工具同樣可以實現這一目的。但這些方式都面臨著一些負面因素，前者需要為不同的云環境創建針對不同版本的大量虛擬機模板，后者則需要對配置管理腳本進行持續地測試，其負擔是顯而易見的。
Fernando推薦使用容器作為實現不可變基礎設施的途徑，因為通過它進行實例創建、測試與部署比起虛擬機與配置腳本快得多。而且使用容器能夠消除應用程序依賴的問題，因為所有的依賴都與應用程序一起封裝在容器中，因而進一步縮短了整體部署時間。同時，容器也解決了對特定云環境的依賴，只要能夠運行 Docker，無論是哪種Linux環境都可以一視同仁（ Windows Server也快了 ）。
接下來要做的是使用容器實現自動化的部署，包含兩個步驟。第一步是創建容器鏡像文件，Fernando推薦使用 經優化 的Dockerfile，這種方式非常簡便快速，可以在持續集成或持續交付平臺中對其進行測試后再進行部署。第二步就是最后的部署工作了，常見的做法是手動將容器部署到服務器上，然后將負載均衡器指向這些服務器以接受用戶訪問。這一點可在實例級別實現（例如在每個AWS EC2實例中配置一個應用程序的容器，通過Elastic Load Balancer在實例間進行切換），也可以在容器級別實現（通過Haproxy或Nginx容器將訪問轉發到應用程序容器）。那么如何通過自動化方式完成第二步呢？Fernando在此推薦了自家的產品 Tutum ！
使用Tutum實現容器的自動化部署
Tutum為Docker容器提供了托管服務，通過使用Tutum，部署應用程序的新版本變成了一件非常簡單的任務，只需在服務定義中修改鏡像的標簽，然后點擊“ 重新部署 ”即可。
而在非生產環境中（例如QA或UAT環境），回滾到應用程序的某個特定版本并不是非常重要的任務，這種情況下甚至可以選擇對“重新部署”進行自動化，可以通過使用Tutum的“ 自動重新部署 ”特性，或使用DockerHub的重新部署 觸發器 。
在重新部署流程啟動之后，Tutum將會逐個地用新的容器替換舊的容器，隨后通過 tutum/haproxy 鏡像實現訪問的轉發，這個鏡像會根據所鏈接的容器進行自動配置。這種方式還能夠實現新版本與舊版本的服務的同時運行，只需在tutum/haproxy服務中添加一個到新鏡像的鏈接就可以將訪問同時轉發給新版本與舊版本的服務。
Tutum還能夠實現數據卷的重用，因為在多次部署之間的數據卷是持久化的。如果你重新部署了一個 tutum/mysql 容器，它就會自動在/var/lib/mysql路徑下創建一個數據卷，Tutum將重用這個數據卷，并保持所有數據不會丟失。
來自社區的其它聲音
雖然Docker為代碼的部署與不可變環境的創建提供了一個堅實的基礎，但人們也開始反思：絕對的不可變性是否能夠應對應用程序的復雜性與多樣性？就在去年，Docker 推出 了一個新的特性，允許“可寫的 /etc/hosts，/etc/hostname，以及/etc/resolv.conf”，這就意味著可以對運行中的容器進行修改。這不由令人心生疑惑，難道Docker打算遠離“不可變基礎設施”這一思想，還是說這一思想本身尚有不足之處？
對此，VisualOps的創始人兼CEO趙鵬在 一篇博客 中表達了他的觀點，他認為Docker雖然能夠跨多個不同的部署平臺保證一致性，但許多配置信息是特定于上下文的，因此不必死守純粹的不可變性這一思想。而Docker的這一特性能夠避免配置信息對于代碼及應用程序產生的侵入性，可以通過某種編排工具使用這一特性，在運行時對應用程序進行特定的配置。
而來自Chef的產品經理 Julian Dunn 也 表達 了類似的看法，他認為純粹的不可變性既不實際，也并非一種理想狀態，在使用應用程序的過程中仍然會產生可變的部分。在這種情況下，配置管理工具（例如Chef）仍有用武之地，它可以對其中“可變”的部分配置進行有效地管理。