本文主要從docker的編排技術，docker在一個大規模生産環境中的使用開始切入，圍繞docker應用的深化，像谷歌，aws，阿裡雲都推出了這樣的容器服務，分享并分析了新的概念——container as a service，着重講解了微服務支援和devops，并談及了容器服務解決了哪些問題，最後介紹了docker的最新發展趨勢。
以下為整理内容：
docker編排技術
大家都已經了解了docker是什麼樣的技術，<b>docker</b><b>是标準化的建構、傳遞、運維手段。</b>但直到今天還有很多人在質疑，docker隻不過是容器技術的一種實作，為什麼會這麼火呢？
<b> </b>
<b>docker</b><b>最大的價值不在于技術，而在于它使人們達成了某種共識，</b>以一種标準化的方法來開發、傳遞和運維軟體，使得把我們的應用和應用運作過程中的依賴打成docker鏡像，通過docker鏡像，我們可以在開發、測試、線上等各個階段來使用，我們也可以在筆記本、測試機或是雲上來運作程式。通過這個标準化，催生了一個巨大的生态，讓docker具有巨大的價值。
docker的核心亮點有以下幾個方面：
<b>靈活</b>：秒級應用啟動、輕量級隔離、細粒度資源控制、低性能損耗。
<b>可移植性</b>： 環境無關的傳遞、部署方式；可用于軟體生命周期中不同運作環境。
<b>可控</b>：标準化推動自動化，提高運維效率和規模；隔離性提升應用安全性；版本管理可追溯。
docker與虛拟化技術
docker不是虛拟化技術的颠覆者，docker容器和虛拟化技術是互補、雙赢的。docker是一種輕量級的作業系統虛拟化方案，利用虛拟機提供彈性基礎架構，更好的安全隔離，動态熱遷移，可以更好的保證業務的安全性和連續性，而利用容器技術也可以簡化遷雲之路，實作無邊界的雲計算。
docker本身巨大的成功是根據幾個巨大的趨勢結合在一起才凸顯了它的價值。docker重點介紹3個方向，docker在雲計算上扮演着重要的工作，還有（microservices）微服務架構，企業最關心的是it部門的效率，最快速度的傳遞産品、最低成本的試錯，才能快速的疊代、快速的演進，微服務架構可以幫助企業走向這步，微服務架構給底層的基礎設施和部署帶來巨大的挑戰，利用docker可以解決這個問題。devops，開發人員和運維人員了解的devops是不一樣的，docker可以使二者結合在一起。
<b>容器編排</b><b> </b><b>——</b><b> docker compose</b>
docker引擎是把應用包裝在一個docker鏡像裡，然後啟動docker鏡像變成一個容器，但是它帶來的幫助是有限的，任何一個複雜的應用不是一個容器就能完成的，一定是一組容器互相協同才能完成一個完整的應用棧。docker compose是docker推出來的一個對多容器的編排技術，簡單好用，便于開發。使用docker compose，可以一鍵建構本地開發環境，在團隊中可以共享一份配置檔案。
docker compose面向開發和部署，不支援自動化運維，隻是面向單機的一個環境。docker compose目前還隻是一個開發工具，能夠幫助部署一個docker化的多容器應用，部署後它就置之不理了。
<b>容器叢集管理</b><b> </b><b>——</b><b>docker swarm</b>
docker swarm的優點：<b>相容标準的</b><b>docker api</b><b>，靈活、可插拔的容器排程</b>。
在生産環境中，我們希望有一個叢集。從流量的角度，我們希望有更大規模能夠部署更多的應用，在高可用的情況下，不可能把應用部署在隻有一台節點的機器上。docker swarm把一組docker引擎抽象成一個docker引擎，以前所有在單機上對一個docker引擎的工作，都可以透明的變成對一組docker叢集上的節點的操作。在docker swarm叢集中，有兩類節點，一是docker swarm managers，這些managers負責接收使用者的請求，并且根據叢集的狀态來做一些任務的下發，真正的任務是在work節點完成的，每個work上都會安裝一個agent,work會上報到一個分布式的kv裡，告訴這個節點的狀态是死是活，有了這些資訊，manager就可以做決策。
docker swarm也有它的不足，它的抽象級别太低，<b>面向容器、缺少微服務支援。</b>
我們在把容器技術應用到大規模生産環境中時，依然會有衆多的挑戰。在生産環境中還需要考慮很多，比如，叢集怎麼管理，怎樣更有效的排程來充分利用這些資源，怎樣解決在這個叢集中容器和容器互相的網絡通信，不同應用對存儲的需求等等。
containers as a service (caas 容器服務)
caas一方面提供容器化的環境，運作支撐環境來覆寫容器化應用的整個生命周期，從建構到傳遞到運維，它面對的目标使用者不僅是開發者，也包括運維人員。在建構到傳遞階段是持續內建和持續測試的能力，傳遞階段一定是以容器的方式傳遞應用，在傳遞到運作階段，也是使用容器化的方法進行應用的部署和運維。caas另一方面是以服務化的能力來提供docker的運作支撐環境，對于企業客戶來說，使用者隻需關心容器的應用自身即可，而整個應用支撐的環境是由雲平台提供出來的。
傳統雲計算金字塔中，paas層帶來的簡化性是以犧牲整個對環境控制的靈活性為代價的，導緻paas平台的市場接受度很低。而docker和caas的出現恰好填補了這個缺口，在paas領域進行了重新定位，<b>實作了簡潔性和靈活性間的完美平衡。</b><b> </b>
caas的主要服務提供商既有谷歌、亞馬遜以及docker自身，也有國内的阿裡雲和很多其他的創業公司，每一家的caas都有自己的一些特色。
阿裡雲容器服務概念模型
容器服務上有三個層面的概念：
資源層面——叢集，節點。
内容層面——compose模闆，鏡像。
應用層面——應用，服務，容器。
<b>內建容器和雲服務</b>
完全相容 docker compose/swarm
聲明的方式支援容器及雲服務
支援微服務架構<b> </b>
<b>阿裡雲容器服務</b>
阿裡雲容器服務為圖中中間部分，最底層為容器層，阿裡雲容器層可以支援不同雲環境下的基礎設施，包括公共雲、專有雲以及混合雲，利用docker自身很好的可移植性，可以實作無邊界的雲計算，除了docker引擎外，我們更加關注存儲和網絡的不同需求，所有的支援我們都可以通過聲明的方式利用起來，我們也支援第三方的擴充。在容器層之上是排程層，排程層的概念是如何在容器叢集上使得容器和下面資源能更好的協作來完成一個應用棧需要的各種各樣的能力。排程層之上還需要做更高層的抽象，沒有人在乎容器，大家在乎的是自己的應用是怎樣建構的，是怎麼對外提供服務的，我們就提供了很好的對微服務架構的支援，支援服務的注冊發現、彈性伸縮、灰階釋出和不間斷更新。
有了這樣的容器化平台，我們還可以對接現有的中間件服務和阿裡雲上的其它服務，以及內建ci/cd這樣的三方工具，可以完整的支援軟體的開發的過程。容器也不該成為企業it治理的孤島，它會與現有的it流程、現有的it平台的管控進行一個良好的內建。
<b>跨主機容器網絡</b>
在雲上搭建網絡有其自己的特殊性，阿裡雲的跨主機容器網絡有如下幾個特性：
每個容器在這個網絡上都有一個獨立ip
容器跨主控端直接通信
容器網絡可以通過dns解析容器位址
<b></b>
微服務架構
微服務就是把一個大而全的單體應用拆分成一組解耦的、自治的、協同工作的服務，這些服務通過标準化的借口互相通訊，每一個服務都是由一個團隊單獨的運維，它可以被獨立的部署，每個服務的部署更新不會影響到其它的服務。
微服務在實際操作過程中會遇到種種問題，比如當應用拆分後，從運維一個服務變成運維多個服務，而這些服務又是被動态的分布在分布式環境裡的，對這些服務進行管控、通路就變得比以前更加複雜。容器服務提供了兩種彈性路由的方案，如下：
彈性web路由方案1
我們可以為每一個容器服務取一個二級域名，讓服務能夠通過二級域名的方式進行通路。我們提供了一個分布式路由服務，它會根據發現服務裡定義的各種各樣的路由規則，去生成相應的haproxy路由規則，當發生修改的時候能夠動态的重新啟動haproxy，讓規則生效。路由服務之上對接的是slb，在slb上隻要綁定一個根域名，下面部署的各種各樣的服務就可以通過二級域名的方式動态的接進來。
彈性web路由方案2
有時候使用者希望對slb端有更靈活的配置，方案2就是利用聲明式的機制讓不同的容器服務挂載到不同的slb上，發現服務裡記錄了整個叢集上所有服務對外的路由的資訊，cluster master會去偵聽發現服務上整個路由的變化，并根據這些變化，自動的修改slb後端的伺服器配置。
<b>實作無關的服務發現與負載均衡</b>
隻是利用dns這樣的發現機制是不夠的，我們通過一種聲明化的方法，能夠讓一個服務通路另外一個服務，和dns服務發現相比：
支援靈活的負載均衡政策
避免ttl問題
支援健康檢查
<b>監控與</b><b>autoscaling</b>
聲明式方式定義彈性伸縮政策。
内置雲監控內建。
提供插件機制支援開源、三方監控內建。
devops
devops最重要的有兩點。一是“在一起”，開發和運維應該是一體化來考慮的過程，開發人員傳遞的産品必須是運維人員能夠部署上線的東西。二是要有快速持續的回報。
<b>利用容器實作持續內建和傳遞 build once and deploy everywhere</b>
docker可以在一處建構，就可以在各個地方部署。docker鏡像在開發中可以使用，可以在測試中使用，可以進行驗證，可以進行上線，一切都是以docker鏡像為傳遞物的。此外，利用compose模闆，可以開發出部署的資源，标準化一緻的在各個環境複用，以便進行持續的內建和部署。通過docker鏡像和compose模闆，可以把一個應用對外界的依賴，以及服務和服務之間的關聯，全部變成可追蹤的代碼，這可以通過非常好的版本管理進行更好的管控，以便快速上線和復原。
<b>完整的容器化持續傳遞流程</b>
未來發展趨勢
<b>最好的方式來編排docker</b><b>就是docker</b><b>自身。</b>
docker engine已經内置編排能力，更新後的docker将具備以下四點特性：
<b>swarm mode</b>
<b>cryptographic node</b>
identity
<b>service api</b>
<b>built-in routing mesh</b>
<b>docker swarm </b><b>模式</b>
docker swarm mode是由一組docker
engine構成，每個docker engine都可能扮演兩種角色中的一種，manager和worker。在一個叢集上可以有多個manager，多個manager可以自己通過分布式的同步協定實作一個高可靠的state store。
<b>服務</b><b></b>
services
新的docker提供了一個services api。如果出現節點失敗，在這個節點上的容器将會被自動遷移到其他節點之上。docker swarm mode采用狀态逼近的模式，它定義了服務的期望狀态，它會在運作過程中不斷檢查目前的狀态是否和期望的狀态保持一緻，如果不一緻，它就會自動修複。
<b>routing mesh</b>
在一個叢集中，整個服務容器的部署是根據排程規則去進行動态排程的，任何一個服務的容器可能部署在叢集中的任意一個節點上，新docker提供了routing mesh的能力，其特性如下：
每個服務一個vip
ipvs實作負載均衡
動态/手工配置設定publishedport
每個worker參與路由
<b>distributed application bundle </b><b>與</b><b> stack</b>
一個dab部署後就會生成一個相應的stack，一個完整的應用棧。dab實際是一個json檔案，用與docker compose類似的方式描述了一組服務，通過一個dab就可以一鍵的通過一個deploy指令來生成一個相應的docker stack。