Docker正在漸漸成為開發和運行容器應用程序的標準。
很久以前，這一技術可能只對系統管理員和PaaS(平臺作為服務)才有實際意義。但幾乎沒有聽過哪家創業型公司會使用Docker，尤其是那種發展前景很明朗的公司。Datadog總部近做的研究也與這些觀念基本一致：
也許你會說對于創業型公司來說，這么做是否值得，那么接下來我們就詳細介紹一下那些友好的容器體系結構對這些創業型公司到底提供了哪些幫助。如果你還沒有使用Docker，我們會告訴你為什么需要選擇使用Docker？
如果你在一家小型的具有兩個披薩原則的公司工作，那么團隊中的每個人很有可能都是上知天文，下知地理的。一旦手頭的項目結束了或者再也不需要了，那么你就會被打回進入到開發的深淵中去。
讓我們設想一個簡單的場景，某位前端工程師需要從后端工程師那里獲取一份API，但是該API還沒有上生產。你可以通過使用模擬數據來解決這個問題，也可以部署一個預生產環境。這些方案都很不錯。但是，與后端代碼本身進行集成的敏捷性相比，它們就要遜色很多了。
類似于docker-compose這樣的工具為我們創造了奇跡。新人所要做的全部工作就是安裝某件東西。docker-compose這類工具所需要做的事情就是祈禱Docker已經為用戶安裝好了所有的東西，因此就可以跳過中間所有的步驟直接到編碼環節即可。
關于各個運行時組件之間是如何進行相互通信的，這些工具的聲明性特性都會提供一個概述。因此也使得對頂級架構的推理變得更加容易。
services:
redis:
image: redis:alpine
ports:
- "6379"
networks:
- frontend
db:
image: postgres:9.4
volumes:
- db-data:/var/lib/postgresql/data
networks:
- backend
vote:
image: dockersamples/examplevotingapp_vote:before
ports:
- 5000:80
networks:
- frontend
depends_on:
- redis
result:
image: dockersamples/examplevotingapp_result:before
ports:
- 5001:80
networks:
- backend
depends_on:
- db
worker:
image: dockersamples/examplevotingapp_worker
networks:
- frontend
- backend
networks:
frontend:
backend:
volumes:
db-data: 除了在開發中有用外，Docker還使得生產代碼打包變得更加簡單了。這是因為它使開發和生產環境更加對稱。這是12factor的dev/prod對等點的重要作用之一。
有一些很好的語言專用工具，比如rbenv(Ruby版本管理)和nvm(節點版本管理器)。這些工具使得即使在運行時版本出現錯誤匹配，也不會受到什么影響。如果代碼依賴于一些不知名的本地二進制文件或特定的文件系統結構，那么功能可能會更加強大。
這就是由于容器做得太過于出色而產生的結果。容器允許將應用程序和所需要的環境組合在一起。
這種可移植性在混合云的設置上也發揮了作用。關于這一點，我無需贅述太多，只需要告訴你目前我們也正在遷移到混合云上面。
由于混合云供應商當時無法提供穩定的可靠性，而且支持度也不夠，因此我們非常不滿。我們決定轉到IaaS(基礎設施作為服務)中出色的云上面，即AWS(Amazon Web Services)。
我們能夠預見這種遷移將會很快發生。因此已經將應用程序遷移到Docker上運行了好幾個月。當我們告別舊云的時候，整個過渡過程只花了幾天的時間。
這種范圍如此之大的遷移可能被認為是非常罕見的事件。但我也沒覺得遷移后靈活度方面存在任何問題。
需要注意的是并不是遷移了所有的應用程序。托管的turnkey解決方案也許可以解決諸如監視和日志記錄之類的橫切問題。然而，這些都可以用更容易設置的開源解決方案來代替，并也會讓你避免上云黑名單。
如果問你是否需要某個編排系統可能不太恰當。如果問該系統你是想讓它自我管理，還是希望在凌晨3點的時候叫來修理停機的人進行人工管理更恰當。
這個類比需要考慮很多運動部件。軟件系統在運行時只會比這個更加復雜和分散。當面對網絡分區時，它們就會遇到很多問題。
現在，容器本身并不能解決這個問題——事實上恰恰相反。他們短暫的天性使你的系統變得如此有活力。這使得在部署時很難在石頭上設置依賴項。
擴展到集群化的基礎設施，情況變得更糟。它達到了永遠不確定您的流程終可能運行在何處的問題。這使得定位和處理它們變得更加困難。但是，我們需要接受這種自然，從而給一整套解決方案讓路。
我們嘗試了幾個集群系統。其中包括谷歌的Kubernetes、Mesosphere的馬拉松和Hashicorp的Nomad。
我們在Docker自己的Docker集群上解決了大多數部署，使用的是AWS cloud生成模板的簡單Docker。
首先聲明表示您的系統的期望狀態，它應該運行的服務。然后蜂群會不斷監測你的容器的實際狀態。它將在節點失敗的情況下將工作負載重新調度到其他節點，從而達到預期的狀態。它還可以通過重新配置新服務器來自我修復，因為節點不能恢復。
提供您自己的容器集群可能會逃避您的需求。然而，新的Caas(容器- as-a- service)平臺正在涌現，通常沒有比基礎設施使用的額外成本。
當你有卡通鯨魚的時候，誰還需要小貓。
您將發現服務發現、負載平衡、軟件定義的網絡、持久存儲、任務調度和筏筏共識。這保證了一個可怕但有趣的旅程，通過一個聽起來很酷的行話。
你沒有必須要再去讀那些“在切換到{ { rand_language } }之后，應該如何通過{ { rand_amount } }將服務器成本削減”之類的文章了，因為本文我會提出一些不同的方法。
如今，微服務風靡一時。我們已經在Beta Labs里面把應用程序分成了幾個不同的服務。這樣就可以把不同的開發語言和框架進行整合和適配了，而且還可以隨時使用好的工具來工作。
請對我做一些包容。因為我將試著用十個或更少的字來簡單說明一下微服務的情況。
在讀完12factor的“一個代碼庫，多重部署”之后，我認為每個服務都應該作為它自己的應用程序部署在PaaS術語中。這恰好是大多數PaaS定價模型的規模。
我們來簡單算一下。在Heroku上運行一個Ruby應用程序的設置意味著至少需要運行兩個web標準的dynos。如果一個應用程序的內存限制在512MB以內，那你每個月返回$50。
每月前端服務將需要
可能還需要一些輕量級的后端服務，比如帶有自定義邏輯的中間件或代理，它可以使用1個實例。你可以輕松地超過每月100美元。
那是在我們開始討論附加組件之前。為基本的Redis和PostgreSQL實例增加每月30美元。Heroku的Logplex只是流媒體。因此，如果您想讓日志保持更長時間，您還需要添加一個可以跨應用程序共享的日志服務。
讓我們看看如何能夠做得更好。
一個VM每個(單一的)服務vs每個VM的多個(微)服務。數據提供者:Martin Fowler
讓我們借用Martin Fowler對微服務的描述。使用帶有集群系統的容器，為動態擴展服務提供了一個很贊的合適的平臺。
容器被放置在具有多可用資源的節點上。所有節點共享一個內部SDN(軟件定義網絡)。因此，服務可以在不離開集群的情況下互相通信。
一個3 -node- strong集群運行的例子- voting-app
讓我們回到前面的例子。這樣的系統適合3個節點，t2。基于微技術的Docker集群集群，每個月大約有50美元。你可以有3GB的內存。如果你敢這么大膽的話，你甚至可以有額外的空間來運行你自己的容器。
Heroku的dynos在CPU部門更有天賦，擁有8個虛擬內核。但是，除非您使用本機線程的語言運行，否則一個多進程/ dyno設置可能會使您發現512MB內存不夠快。另外，如果您的工作負載是I / O密集型的，則不會有太大的差別。
不要誤會我的意思，就像讓DevOps一個非問題一樣，它也沒有比Heroku好得多。我并不是建議你或你的團隊中的任何人單獨行動，花上幾個晚上學習如何在PostgreSQL中獲得高可用性設置。我們將把蘋果比作桔子。
盡管如此，我還是覺得很重要的一點是，你要為所有的可靠性和易用性支付額外的費用。有了這些，你就可以自己判斷什么是真正值得的，什么是你可以自己做的。
哦，當我們在這里的時候，別忘了你可以在Heroku運行你的Docker容器。
在拿Docker平臺與PaaS進行比較時，這種討論可能不會產生多大的影響。然而，你會發現，如果是跟運行多個應用程序的Ubuntu相比，某些風險漏洞會大大降低。
為什么會有所不同呢?答案就是Linux容器。這個有趣的概念是由曾經那些很喜歡使用Heroku的人在閱讀指南時提出來的，現在已經成為Docker的核心了。隨之而來的是一個廣為人知的安全特性名詞:隔離。
試想一下在服務器中遠程執行代碼的壞情況。聽起來太牽強?查看ImageTragick。應用程序趨向于與容器有一對一的關系。應該將那些能夠對該應用程序域產生破壞的進行隔離，保留選擇在主機上運行的其他內容。
這與VM(虛擬機)在相當長的一段時間內提供的特性非常類似。VM有一個比較僵化的特性，需要更長的啟動和供應時間，以及運行完整的操作系統。
人們幾乎可以原諒，給他們更長的生命周期，對待他們更像寵物而不是牛。這允許運行更多的應用程序，并可能帶來更多秘密的妥協。
在運行集裝箱化應用程序的同時，降低了這種風險，這并不是說你就是對開發商的不當行為不管不顧了。例如，您不希望妥協訪問主機的Docker守護程序。 但總而言之，集裝箱化的環境確實有助于減少攻擊面。
只要保持謹慎，不要讓你的照片公開出來。
這可能完全是由我們內心作為極客的一面而導致的，是一種偏激的鼓勵,但…
作為一名工程師，如果覺得能夠給自己帶來快樂，那么就很有可能去研究新的技術，提升自己的技能。對于創業型公司的個階段來說，這應該是它能夠吸引別人的全部理由吧?
如果你決定采用Docker了，在未來的幾年里，你肯定會發現它帶來的好處。
那么，Docker是一條通往天堂的絲綢之路嗎?不是。
在Docker把粗糙的問題解決完之前我們能不能先用更穩定的工具來解決?可能。
作為創業公司，如果沒有采用Docker，會不會肯定失敗呢?絕對不會。
是否需要再投資采用容器?我會大聲的告訴你“絕對需要”。
這些觀點遠不是初創公司獨有的。我想說這些與公司的規模無關。請放心，我的想法絕不會損害Docker在公司中的聲譽。
我們并不主張Docker是解決這些一直存在得問題的方法。我們還沒有怎么討論它的缺點。
但就目前而言，它仍然是接近我們上面提到的所有常見問題的一站式解決方案。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
