[置頂] Docker學習總結（7）——雲端基於Docker的微服務與持續交付實踐

本文根據〖2016 全球運維大會•深圳站〗現場演講嘉賓分享內容整理而成

講師簡介

易立

畢業於北京大學，得到學士學位和碩士學位；目前負責阿里雲容器技術相關的產品的研發工做。

加入阿里以前，曾在IBM中國開發中心工做14年，擔任資深技術專員，負責IBM企業平臺雲產品線PureApplication System的研發工做；還負責和參與了一系列IBM在Web 2.0，SOA中間件的研發和創新，也曾爲全球客戶提供SOA技術諮詢和項目實施。

日程

你們好，我演講的主題是《雲端基於Docker的微服務與持續交付實踐》，我主要分幾點來介紹：

Docker與微服務

雲端生產環境部署

應用Docker化改造

持續交付流程實踐

交付方式變革改變了全球經濟格局

不少人都是拿集裝箱的故事開始的，我也不例外。一百年前，一個叫作集裝箱的東西，改變了全球定律，如今在跨國貿易的90%的貨物都是經過集裝箱來運輸的。

一個不起眼的單，一個交付上的改變，就能夠改變整個經濟。

Docker在這個時代就是改變整個軟件交付的變革，如今幾乎在全部的運維或者架構上都在用Docker進行交付，爲何？

Docker in Alibaba

阿里巴巴Docker的使用無處不在，2011年，淘寶開始採用容器技術，配合阿里內部自身的一些架構，極大地提升了開發和運維的效率，使得整個開發效率變得更高。在「雙11」這樣的大促中，發揮了巨大的做用。

阿里百川是一個面向移動平臺的電商PaaS，它利用Docker能夠支持不一樣的編程環境，讓用戶能夠快速應用軟件在線上運行。

基於阿里的實踐，咱們從去年開始在公共雲計算平臺上推行了容器服務，你們能夠不用關心Docker底層的技術，網絡存儲、資源管理等等不用關心，你們只用關心本身Docker的應用部署就能夠了。

同時，Docker在不少領域都會發揮着巨大的做用。

好比前一段時間谷歌的AlphaGo，其實背後計算很重要的一個框架就是深度學習框架，搭建一個深度學習框架是一個很是複雜的學習，你要配置相應的深刻計算框架的各個軟件。

但是在阿里提供給客戶的服務，你們只要用Docker鏡像就能夠快速地在一組HPC的機器搭建起來，你能夠按需地得到深度學習所須要的計算能力，也許你也有一天能夠開發一款進行PK。

其實Docker在阿里巴巴的使用無所不在，你能想象，像阿里這麼龐大的一個系統，包含了虛擬化、數據庫、大數據、網絡，這麼龐大的系統，幾百個組件，咱們如今對它Docker處理，加速它開發運維以及輸出的速度。

咱們能夠把整個阿里雲在幾個小時以內就搭建起來。因此說，Docker已經完全地改變了咱們對軟件交付和運維的一些場景。

爲何Docker這麼重要？

加速應用交付，縮短夢想距離

咱們談互聯網公司，互聯網公司的核心競爭力是什麼？

就是效率，就是看你能不能最快速度地推出產品，最低的成本，最快的地迭代。

而在十年前咱們的軟件開發是什麼樣的？

咱們的應用是一個總體式的應用，它是由大的團隊來開發，這個團隊分爲開發團隊和運維團隊，開發團隊有前端團隊、後端團隊、數據庫團隊，這些團隊可能由於業務需求互相扯皮，到最後使整個軟件開發迭代的速度極爲緩慢。

在傳統企業迭代的週期在半年到一年，這個速度遠遠不能知足業務方的需求，同時更苦逼的是咱們運維人員，直到最後一刻，軟件人員講解立刻要上線，把一堆安裝腳本給運維人員，讓運維人員去安裝和部署，去保證它的高可用。

你們能想象嗎？這樣的事情怎麼可能發生！

因此說，你們頂着一個巨大的挑戰:

• 第一個就是變化緩慢，在互聯網時代誰變得慢，誰就死得快；

• 第二，爲了保證這樣大型的總體應用，它很是難伸縮，一般爲了適應大的流量，咱們只能增長新的CPU等方法來擴展。

你們都知道，若是要保證線性計算性能的增加，可能須要花費的代價更高。另外，整個系統持續運營能力也是很差的，越大越不穩定，其中一個組件壞掉，就會產生雪崩效應，整個系統就會宕掉。

這個過程很是痛苦，阿里通過這樣的過程，如今的互聯網公司包括阿里都已經演變成以下的結構。

底層是一個基於雲服務或者虛擬化的計算架構，每一個業務好比電商，能夠有用戶管理、商品管理，咱們的購物車、導購、廣告。

這些都是不一樣的模塊，每一個模塊是由一個小組，每一個圖片均可以獨立部署，組件之間是經過標準化的協議互相通訊。

只有這樣才能保證速度，才能保證在競爭中咱們可以活下來。

Docker 與虛擬化技術

Docker的出現進一步地推進這件事，Docker是一種輕量級的操做系統虛擬化方案，更加敏捷地進行交付。

Docker自己具備良好的可移植性，這一點更爲重要，咱們可以在開發、測試、生產中用統一的方法、統一的介質來交付軟件。

想象一下，若是是在一個混合雲場景，好比說「雙11大促」，不少如今的計算力已經移到公有云上，由於是按需分配，很快地能夠把應用擴展到整個數據中心。

結合Docker容器和虛擬化技術

不少人說「Docker革了虛擬化的命」，咱們認爲Docker和虛擬化在不少程度上也是互補的。

Docker技術依然有自己的限制，好比Docker在系統的安全隔離方面作得並很差，像虛擬化這些Docker不能作，目前一個最成熟的方案是把虛擬化的技術和容器技術結合在一塊兒。

在公有云上很是不建議你們採用多租戶的方式，由於有大量的安全漏洞。

Cloud Native Computing

隨着微服務和容器技術的發展，在去年穀歌牽頭成立了一個Cloud Native Computing基金會。

它定義了將來的原生應用的一些基本要素和框架，以微服務架構以容器方式交付，支持DevOps，這個平臺是動態本身管理的，不是手動的。

爲何作這件事？

咱們要以持續發展的眼光來看，單體應用遲早會碰到天花板，它的複雜性、可伸縮性必定撞到牆。

因此，咱們才採用微服務，微服務不是免費的午飯，它帶來好處的時候也帶來複雜性，之前我運維一個應用，如今要運維幾十個服務。

之前也有同事跟我說是二十個服務，分解成微服務以後是將近四百個，他的管理數量多了一個量極。

如何讓服務和服務之間監控它的健康情況？

一旦一個服務掛掉，咱們要對它進行隔離、熔斷、降級，而後咱們怎麼對這個微服務進行版本更新，保證之前的產品不會受到中斷？

這些都是巨大的影響。

這些事情若是讓人手動來作的話，確定不行，必定要用平臺、用自動化的方式。因此，這就是爲何你們在強調須要一個平臺來支撐。

雲端漫步：開始 Docker 之旅

其實在雲上使用服務器並不複雜，你們已經很是習慣於在本身的開發、測試、數據中心使用Docker技術，可是在雲上你們爲何不呢？

你們以爲要虛擬機、配各類東西很麻煩，可是其實不是這樣的。

Docker在2014年末推出了Docker Machine，利用Docker Machine就能夠快速地在雲上建立一個Docker的雲環境。

要作的事情很簡單，下載Docker Machine以後尋找雲的供應商的驅動，好比如今的阿里雲、亞馬遜、Aure這樣的一些Driver，經過Driver，經過命令行就能夠在上面部署個人容器化應用，很是簡單。

生產環境中使用Docker

可是若是真的在雲上、在生長環境選Docker，你要面臨的挑戰遠不只如此。

一個Docker的實力確定不夠，必定是一個集羣，這個集羣怎麼管理，網絡怎麼橋接，存儲怎麼辦，如何進行資源調度，怎麼安排，這是一個很是複雜的事情。

爲了這件事，不少互聯網企業都提供了所謂的產品，我找幾個給你們介紹一下。

• Docker Cloud，Docker在去年11月收購了tutum.co在今年2月份推出了Docker Cloud，它基本上提供了Docker自身原生的一個編排的API。

• 亞馬遜在2014年11月份推出了 EC2 Container Service，它最先是基於一個本身的私有API提供了容器描述的服務，可是在去年逐漸開始支持更加普遍的Docker，來描述一個組合的容器化應用。

• 谷歌的Compose template，它也是在2014年7月開源的，它是集成了之前的不少思想，相應的一些調度的不少歷史。推出來以後獲得很大的歡迎，可是它提供了一套本身特有的對容器化應用抽象。

容器集羣管理 - Docker Swarm

爲了更好地闡述咱們的一些內容，我今天會介紹一下阿里容器服務。阿里容器服務爲了解決用戶在開發、測試環境無縫遷移，咱們徹底兼容了Docker原生編排方案。

Docker原生編排方案包括哪些內容？

• 首先是Docker Swarm，它是一個很精巧的設計，我能不能把一組Docker engine變成一個虛擬的Docker engine，我都向這一個虛擬的Docker engine下發指令，由它的控制節點真正調動到一個實際的節點來執行。

• 它的架構很是簡單，在每臺節點上只須要一個Docker engine以後再安裝一個Agent就行了，Agent經過上報就可以實現一個機器的自動註冊，經過這個功能上面有一個節點可以發現裏面的節點信息，就可以自動地構建集羣。

• 它是一個很是精巧的抽象，由於它幾乎99%地支持了全部Docker原生的API。

它帶來兩個好處：

它能夠和如今三方全部和Docker鏈接的工具集成在一塊兒，不作任何改變；

它有另一個好處是提供了一個能夠插拔的架構，好比說它的調度器、存儲和網絡均可以很是容易地進行擴展。

另外它有一個很大的缺點：

Swarm和Docker同樣，它自己的抽象基本單位是容器，並無站在服務的角度去思考。

容器編排 - Docker Compose

Docker Compose源於Docker的一次收購，Docker Compose是描述如何將一組容器和這個容器相關的資源組合在一塊兒。

好比咱們拿Wordpress來舉例，而後Mysql，一個簡單的編排模板就能夠把它描述出來，經過Wordpress鏡像在一塊兒，經過連接鏈接到Mysql，經過volume來建立。

經過這種方式能夠很是優雅地描述一組容器是怎麼關聯工做在一塊兒的，並且經過一鍵就能夠把整個應用站啓動起來。若是咱們對它進行一些伸縮的話，也很是簡單。

優勢

• 簡單好用，便於開發。它是一個很是好的開發工具，在Docker的開發社區中已經有超過70% 的人在使用Docker Compose進行鏡像開發。

• 擴展了對網絡、存儲的支持。不但能夠描述和容器，還能夠描述容器和它對應的基礎資源的一些關聯。

不足

面向開發和部署，不支持自動化運維。好比說，怎麼跟運維進行監控，是否是可以進行彈性收縮，它都沒有作，由於它自己就是一個開發工具。

阿里容器服務

咱們理想中的一個容器開發平臺是什麼呢？

咱們的阿里雲容器服務提供的一個能力，首先底層是公共雲計算平臺或者企業的專有云。在此之上是容器層，除了Docker以外，Docker倉庫，還有相應的存儲和網絡。

原生的Docker是遠遠不夠的，它提供了相應的機制，咱們也建議這種機制把雲端的塊存儲、對象存儲、網絡存儲都可以很是容易地集成進來。

在容器層之上就是集羣管理和調度層，咱們作了大量的優化和改進，好比說剛纔你們談到一個應用，咱們要保證它的遷移，咱們要作那麼多事情，咱們不能保證它不宕掉，咱們可以保證什麼呢？

咱們可以保證資源調度，哪怕一個數據中心斷電，一個地區的數據中心斷電，也能夠保證資源調度。

另外，在容器編排的角度，咱們怎麼很容易地把一個服務暴露出去，很容易地對容器進行日誌採集和監控？咱們作了大量的擴展，依然能夠作到很是好的容器應用的管控。

在此之上就是咱們的服務層，阿里自己的微服務架構作了好久，在開源界是很是流行的，咱們把這些經驗都內化到咱們的支持能力中來。

其中的一個很大關鍵是如何作服務的發現、服務的路由，咱們擴展了不少，經過BNS發現，經過負載均衡來實現服務節點之間的動態的負載均衡，經過這些東西，讓您的微服務作得很好。

在服務層之上就是接入層，讓Web應用能夠很是容易地接入到你的自身應用上。

這是咱們整個容器平臺的核心，可是你們知道，一個不開放的平臺是遠遠不夠的，由於容器不能解決全部的問題，容器必定要跟現有企業的應用或者雲服務打通。

咱們作了很好的集成能力，可以很是容易地跟雲服務集成，咱們可以跟第三方工具集成，把容器這個技術融合到您本身開發的流程中，同時咱們提供雲管控。

管控能力，除了自身接入咱們的雲監控日誌以外，實際上咱們整個系統裏全部的管控框架都是能夠隨便擴展的，由於咱們認爲一個不夠開放的平臺基本上就是耍流氓，容器不是你的信息孤島，必定要跟現有的IT管控結合在一塊兒。

咱們也提供了不少範例怎麼利用開源的框架，迅速地搭建一個您本身須要的雲監控的能力，這些咱們在後面的文檔中有一些示例，你們能夠去看。

什麼應用能夠運行在容器中

講了這麼多，實際上你們必定會關心：

個人應用怎麼跑在容器裏？

我哪些應用能夠被容器化？

你們都會問這些問題。

這是我節選的一個很著名的分類方法，它能夠幫助你們去挑選什麼樣的應用適合在容器裏跑、什麼樣的應用不適合。

它是根據兩個維度：

一個維度是長壽仍是短命的應用；

另一個是看它是有狀態仍是無狀態。

• 容器化的應用最擅長的使用就是左面的短命且無狀態的應用，由於這樣的應用最容易部署。

好比一個Web應用，咱們能夠很容易地快速把它幹掉，咱們不在意它，能夠很是快速地部署一個Web應用。

• 另一個維度就是那些短命，像高性能計算、批處理。

對一個視頻進行渲染必定是大量有狀態的信息，可是這些信息能夠經過Web對象存儲來保存，這樣的計算密集型任務也很是適合在上面去作，由於咱們能夠快速地識別一大組集羣，經過這樣的容器來跑這樣的任務。

• 還有一類是長壽可是無狀態的，好比說咱們的開發測試環境一直在用或者咱們的監控，它會一直跑在那裏，可是它自己的狀態依賴度是很是小的，這樣的應用咱們也能夠考慮。

• 只有左下角這個維度通常來說是最有挑戰的，它是有狀態的服務，通常有狀態的服務須要一些調整，包括對存儲調整、對網絡調整，你們依然須要DBA作很複雜的工做，也不徹底作到自動化。

對於這樣的一些應用，咱們的建議是在測試與開發中可使用容器技術，可是在生產上很是不建議使用這樣的技術。

Docker化應用實戰: Ghost 博客

接下來就拿一個特別喜聞樂見的例子跟你們解釋怎麼樣把一個應用容器化。

Ghost 博客是我很是喜歡的一個博客應用，很是簡單，很是輕，鏡像也很是好用，用很簡單的方式就能夠把Ghost鏡像起來。

可是還有不少問題：

• 不是可伸縮；

• 不是高可用的。

它全部的數據是保存在本地的Database裏面的，若是虛擬機節點宕掉以後，遷移到另一個節點之上，數據狀態都丟掉了。

咱們怎麼解決？

其實你們能夠去參考THE TWELVE-FACTOR規範，這個規範獲得了居多廠商的支持，它是如今很重要的一個編程規則。

它有幾個核心原則：

• 應用要和運行的環境解耦

• 應用要和外部調用服務解耦

• 應用要和配置解耦

經過這些解耦咱們纔能有一些應用變成無狀態的，可以快速在雲上進行部署和運營。

Ghost 博客 高可用集羣1

咱們只須要增長一個MySQL，讓它支持MySQL的驅動就能夠了，啓動一個ghost+MySQ，經過MySQL進行鏈接，它們是共享狀態的，咱們的容器服務也作了不少的優化。

Ghost 博客 高可用集羣2

咱們不建議在生產環境中使用數據庫這樣有狀態的服務，咱們該怎麼作？

咱們看到不少文章都說Docker很是很差用，說它不能運行數據庫，Docker原本也不是運行數據庫的。

爲何我不直連到個人數據庫的實例上呢？

固然，這有不一樣的作法，可是我以爲最好的作法是咱們作一個最小的改動，可以讓應用層不作任何的感知就能夠把一個數據庫的鏡像，把一個Docker的運行使用變成一個Web，咱們增長了一個拓展的能力。

咱們增長拓展去引用Web的服務，咱們就能夠部署在生產環境，而你的應用層不作修改。

Ghost 博客 高可用集羣3

在這個過程當中依然還有一個問題沒有解決，用戶上傳的附件，好比說圖片，依然保存在本地存儲中，這確定不行。爲了要作這件事情，咱們有另一件事情。

咱們能夠經過Docker的 Volueme Plugin來解決，它提供了一個很是靈活的機制來支持不一樣的存儲類型，如今已經支持了塊存儲、對象存儲、網絡文件系統。

並且更加好玩的事情是，咱們全部的網絡驅動和Volume的驅動其實都是運行在容器裏面的，由於只有經過這樣的方式，咱們才能對整個系統進行統一的運維和統一的管理。

可是Docker在這方面依然有缺陷，Docker不能區分這樣的一些網絡驅動，會致使重啓Docker Engine的時候，有可能先殺掉你的Volume Driver，你的數據沒有保存就壞掉；

或者說，你的網絡也是同樣，它可能會沒有等你的應用殺掉就把你的網絡驅動殺掉，這樣你的應用和網絡完全中斷，這樣也是不行的。

咱們其實也在社區中提出了改動，咱們能夠對不一樣的守護進程進行分級，能夠啓動一些容器，它能夠有更高的系統級別，在啓動的時候被優先加載，被中止的時候會被最後中止，在社區1.11版本中會有相似的工做，社區會解決這樣的工做。

經過把網絡驅動和卷驅動都做爲容器處理，還能夠給咱們帶來更大的好處。

咱們的整個系統很是可擴展，好比說咱們在和一個第三方的網絡存儲公司談合做，它如今就是拿一個容器來交付存儲驅動，咱們不用修改一行代碼就能夠把存儲驅動跑在服務器上，這樣可使咱們的系統有更大的可擴展性。

容器化持續集成和交付

Docker的一個重要好處就是可移植性，經過可移植性能夠在開發、測試和生產的整個軟件生命週期中，以一樣的方式交付咱們的軟件產品。

好比說，咱們如今的開發人員就是這樣的，只要一鍵就能夠啓動本地的開發環境，代碼完成之後提交，提交的時候是相應的自身代碼和原件。

有了這個之後，相關的Docker基礎設施，好比容器、鏡像倉庫，就能夠把相關的代碼編譯成Docker鏡像， 而且在整個測試、生產中一直用這個鏡像，全部的步驟能夠重複，並且保證一致性。

在這個過程當中，全部的東西都是能夠支持Docker管理的，並且能夠快速更新和管理。

這件事情作完之後有什麼好處呢？

開發者在第一天就想着「個人代碼怎麼上線」，這是一個巨大的文化上和時間上的改變。

之前咱們講DevOps，光運維的人員講沒有用，必需要讓開發者在開發的第一天就在思考「軟件怎麼交付、怎麼可以在雲端爲高可用、可伸縮」，這是必需要改變的一個文化和思想。

若是這個改變不了，你用任何技術都改變不了。

之前咱們阿里也是同樣，開發人員很牛逼，運維人員很苦逼，開發人員開發出來，運維人員熬夜上線，出了故障就回滾，很是低效。

可是咱們如今要求開發人員每一個功能必須交付一個Docker鏡像，把你的前置條件、後置條件、檢查的腳本、健康檢測的東西在一開始就交付出來，不交付的話，咱們運維人員中止接受這樣的代碼。

經過這樣，咱們能夠快速地去演進。

簡化的持續交付流程

源代碼管理，咱們能夠有一個鏡像服務，它能夠訂閱源代碼倉庫的通知，咱們的容器服務也能夠訂閱鏡像變化的通知。

當您的代碼變動，好比修改一個網頁，把兩欄變成三欄，它會通知鏡像服務拉取相應的代碼構建，打包成鏡像以後，自動通知相應的容器服務更新現成的應用。

幾分鐘以後，變動上線，咱們也能夠和其餘的服務集成在一塊兒。

完整的持續交付流程

阿里社交平臺何以監控源代碼倉庫的變動，代碼發射變動以後，它拉取代碼進行鏡像，單元測試經過以後打鏡像，通知持續交付服務器進行下一步操做，它是流水線。

在流水線中拿着Docker鏡像和Docker文件在測試環境、預發環境、生產環境上部署。

咱們一樣的一個Docker鏡像，一樣的一份Docker模板，能夠在不一樣的環境中使用，這樣我就可以保證從開發、測試、上線全部東西的一致性。

你們必定要堅持這樣的一些理念，由於DevOps不少東西你們都懂，缺的就是堅持。

不可變架構（immutable infrastructure）

Docker出來以後爲何獲得DevOps領域人士的歡呼？

其實它符合了咱們所指望的運維方式。

瞭解OOpenStac都知道這個很著名的寓言股市，你的應用究竟是像一隻寵物須要你成天呵護，還像牛羣的一頭牛，能夠隨時殺掉毫無傷心，你能夠隨時有另一頭牛補充上來。

讓這個系統變成自維護，很是健壯，不會由於任何節點的失效而致使整個系統終止。

利用不可變性來運維基礎架構： 一旦實例化後，永不改變；只會用另外的一個實例正確的取代它。

優勢

• 避免環境間的不一致。這在咱們平常生活中佔了很大的比重，超過30%的線上錯誤都是由於開發環境和測試環境與線上環境不一致致使的。

若是我不可變架構就能夠保證全部代碼除了門都是如出一轍的，永遠按照你預期的方式來運行，測試和上線、生產是一樣的東西。

• 簡化部署複雜度。在原地打補丁升級很是難，尤爲是不少系統軟件，有不少副多少。

• 低成本回滾。寫個回滾代碼複雜不少，並且很難保證正確，由於你們歷來不測回滾。

其實這個事情並不新奇，之前有個虛擬機，在家配個自動化的工具也能夠，可是Docker讓這件事情作得更快，變得更簡單。

就等於說，每一個Docker鏡像其實是不可變的，它就是一個進程，隨時能夠替換出來一個新的鏡像。

Docker啓動速度特別快，之前拿虛擬機作回滾可能須要幾分鐘時間，可是若是用Docker回滾時間在秒級，用戶是感受不到中斷的。

Docker：不可變架構夢想成真

要達到這一點也須要你們注意，由於我知道不少人依然在今天把Docker容器當成輕量級虛擬機來使用，這個沒有什麼很差，只是你們的場景不同。

可是，我請你們在作這件事情的時候必定要三思，當你把當容器看成輕量級虛擬機的時候，你必定要再次思考一下，您這樣作可能會喪失掉Docker不少好的特性，最重要的就是不可變性。

爲了達到這一點，咱們須要作一些正確的工做：

• 永遠不要手工修改容器中的內容，你的容器應該永遠是拿代碼構建出來的。

• 儘可能不要使用latest做爲鏡像標籤，生產中你要回滾，你要知道回滾哪些問題、哪個版本，一個最簡單的方法是在你的鏡像中用Git Commit做爲鏡像tag一部分，便於追蹤，保證你線上的產品清楚地知道運行什麼版本。

• 不要把任何可變數據保存在鏡像中，要經過Volume抽象，能夠把應用變化的部分跟您容器的生命週期進行良好的結合，它帶來的好處遠遠大於懶、省事帶來的好處。

跨主機容器網絡 雲端實踐

在網上你們看到不少關於Docker網絡的不少討論，大部分討論是基於本身的數據中心，由於在本身的數據中心很簡單，你甚至能夠控制交換機。

可是在公有云上這件事很難，咱們要選擇在雲上Docker容器互聯的話，必定是按照雲廠商的配置最大的優化去適配。

一般在雲上有兩種方案能夠實現跨虛擬機的容器網絡之間的互聯：

• 經過Overlay的方法，只要三層是通的，經過Overlay實現虛擬網絡。

Overlay這種方式是很是通用的方式，它能夠在不一樣的網絡環境使用，甚至跨不一樣的雲供應商均可以使用。可是它也有弱點，它自身的性能是有限的。

咱們在亞馬遜、阿里雲、IBM的雲上都測過，經過Overlay容器互聯性能和容器經過原生虛機之間通訊，只有帶寬的70%，也會增長20%-30%的延遲，對於網絡性能敏感的人咱們是很是不建議這樣作的。

• 經過雲供應商網絡自身的網絡特性，好比VPC，VPC和今天網絡很大的不一樣，在VPC中咱們能夠控制一些IT分配、路由規則。

經過這種方式咱們獲得不少好處，由於在一個VSwitch以內整個二曾是通的，咱們甚至能夠不用Web技術，在相應的節點上配相應的路由表就能夠實現容器之間互通。

可是在一個VSwitch要作的話要承擔一個後果，當一個數據中心掉鏈的話應用就掛了。

通常生產上咱們建議這樣的作法，經過一個VRouter把你的應用部署在不一樣的VSwitch上，而後在 VRouter上配路由規則，這種方式很通用，不管是在亞馬遜仍是阿里雲上，咱們都採用這種方式。

它的好處，容器和容器之間通訊的帶寬，在阿里雲和亞馬遜上，大概帶寬基本和原生的速度沒有區別，可是時延會稍微多一點，可能會在10%左右。

因此，若是你們追求性能可能會考慮，固然它也是受限於在一個 VRouter上到底有多少條路由表的限制，最後限制到您的集羣節點的最大規模。

你們都知道，世界上沒有最好的方案，必定根據本身的狀況挑選合適的方案。

今天個人演講結束了，這是個人博客地址（雲棲社區Docker團隊博客），在這個社區中常常有不少和Docker相關的示例，並且這些示例不見得是要運行在阿里雲上，咱們的很大的個目標是任何使用Docker鏡像、Docker模板的應用均可以跑在雲端。謝謝你們的時間。

提問：我想問一下，在咱們平常運維中，您以爲Docker使用有什麼困難的地方？或者說咱們想使用的同窗，有哪些坑是能夠避免的？

易立：有人說過，「經驗是無法壓縮的」，就是說，你聽別人分享沒有用，你必須得本身實際練起來，並且要結合本身的實踐狀況。

一般來說，你要說坑吧，也談不上，你要尋找一個很合適的容器配置多是第一步，這裏面有不少細節。因此，我很差直接回答您的問題，咱們線下具體聊。

提問：阿里雲提供了一個託管雲的服務，介紹是Docker技術，可是它沒有像雲虛機同樣提供直接管理的功能，是出於哪方面的考慮，是運維仍是安全？

易立：其實這是產品形態，由於對於不少中小站長來講，他真的不會容器。

他可能上傳本身網站的圖片，可能把網站夾上傳去，它是面向很是小規模的站長或者中小企業，就想在互聯網有一個域名綁定站點就行了，不是像您這種專業人員來作的，這是產品定位問題。

提問：老師您好，最近我也作一個應用的自動化發佈平臺，也涉及用Docker作應用發佈，這個平臺的設計思路和你剛纔講的差很少。

如今遇到了一個問題是你剛纔說的一個鏡像能夠跑在測試環境、預發佈環境、生產環境，可是咱們通常狀況下這三個環境，打個比方說，數據庫帳戶密碼和配置不同，容器中的應用怎麼根據這幾個環境來生成這些信息呢？

易立：在咱們的環境中，實際上去交付的服務器，咱們會關聯內部的CMDB，一個配置服務器，根據不一樣的環境去修改環境界面或者生成一個相應的配置文件。經過這種方式和相應的服務器配合起來，可是鏡像都是同樣的。

提問：這個CMDB有分享出來嗎？

易立：這個東西其實挺多的，由於這件事情其實不復雜，取決於您怎麼作，一個簡單的數據庫也行，由於咱們阿里內部有不少現成的資產管理平臺，這些東西很差分享出來。可是CMDB很簡單。

提問：還有一個是關於鏡像倉庫的問題，本身搭建了一個鏡像倉庫，發現上傳鏡像，裏面的鏡像不能刪除了。

易立：這是一個比較老難的問題。若是您使用Docker，應該是2.3以後提供了定向刪除的一些功能。

可是還有一個能夠值得參考的思路，您後端能夠掛一個對象存儲，你刪除錯了有的時候還麻煩，在雲上你能夠用阿里雲或者其餘亞馬遜的對象存儲，成本很低，並且它能夠幫您作帶寬的節省。

Checklist是停機維護前梳理的本次停機維護操做的事項，執行時嚴格按照次序執行，最簡單的Checklist是基於EXCEL，好一點是把Checklist線上化，再好一點是有一套自由編排的停機維護系統，流程走到那一步時自動執行對應的操做。