創業公司小團隊爲何要使用Docker

以Docker爲表明的容器技術已經持續成爲話題好幾年了，本覺得在沒有歷史包袱的創業公司中，Docker應該會成爲生產環境上部署和管理服務的標準配置，然而最近發現一些友商在得知咱們在生產上使用Docker和Kubernetes以後，竟然表現出了一些驚訝。我想對於這些團隊沒有采納Docker而是繼續使用傳統運維方案，仍是以爲即便多作一些繁瑣的運維工做，也但願對系統有更多的掌控度。

Docker所依賴的LXC容器技術，早在十多年前就被Google這類大廠使用了，國內的一些大廠也在很早開始投入研發和使用了，對他們來講，使用容器可以充分利用計算資源，節省硬件開銷。然而對於小公司來講，把10臺服務器壓縮到5臺服務器並不能幫助公司活下去。

容器技術真正開始普遍產生影響是從Docker的誕生開始，Docker剛出來的時候，官網上的slogan：「Build Ship Run」，準確的闡述了Docker的定位，從打包到部署，傳統運維的這一套流程，因爲語言，環境，平臺的不一樣在各個公司千差萬別，幾乎每一個公司都會開發一套本身的發佈系統。有了Docker以後，這些竟然均可以標準化了，而且相對於笨重的虛擬機，Docker幾乎就是一個進程簡單的包裝，只有不多的額外開銷，啓動速度也幾乎至關於直接啓動應用進程。

對於沒有專職運維的即刻團隊，很天然的從項目開始就使用Docker來作服務的發佈工具了：

第一階段：映射宿主機端口 + HAProxy轉發

因爲一個Docker容器只是一個（或一組）進程的封裝，一個容器想要向宿主機以外的網絡提供服務，就只能綁定宿主機的端口了，端口的管理也是一件大部分狀況下都不但願人去操心的麻煩事，爲了不端口衝突，對於須要暴露端口的容器，Docker會隨機綁定一個宿主機端口，這個時候咱們就須要服務發現機制來幫助不一樣機器上的服務來進行通訊了。

咱們使用了一個簡單的方案，一套開源的工具：docker-discover和docker-register，它包含兩個組件：

1. 每臺worker node虛擬機上運行一個docker-register容器，用來掃描本地容器，把他們的服務名（用鏡像名做爲服務名）和端口（包括容器內端口和宿主機端口）註冊到etcd上。

2. 一個docker-discover容器用來作中心代理，它內部包含了一個HAProxy，每隔幾秒鐘掃描Etcd上的註冊服務，並生成配置文件，刷新HAProxy，生成backend配置的模版以下

{% for service in services %}
listen {{ service }}
    bind *:{{services[service].port}}
    {% for backend in services[service].backends %}
    server {{ backend.name }} {{ backend.addr }} check inter 2s rise 3 fall 2{% endfor %}
{% endfor %}複製代碼

這個方案給咱們提供了一套系統的幾個基本功能：應用發佈，服務發現，負載均衡，進程守護，其中應用發佈是執行腳本去各個worker node上拉取最新鏡像，進程守護則是由Docker daemon的restarts=always來提供。

除了提供一致的運行環境使服務的發佈和回滾比較可控，這套簡單的系統在發佈流程上仍是像傳統運維同樣須要遠程執行腳本，功能比較簡單，隨着咱們後端系統成長起來，很快就不夠用了。

第二階段：Rancher

Docker自己只是提供了一個運行環境，除了把服務跑起來以外，要讓多個服務容器協同起來工做，咱們還須要一個容器編排（Orchestration）系統，通常來講咱們指望編排系統能幫咱們實現幾個目的：

基本發佈自動化功能：

編排過程包含分配機器，拉取鏡像，啓動／中止／更新容器，存活監控，容器數量擴展和收縮

聲明式定義服務棧：

提供一種機制，能夠用配置文件來聲明服務的網絡端口，鏡像及版本，在須要的時候經過配置可再現的建立出一整套服務。

服務發現：

提供DNS和負載均衡，一個容器啓動以後，須要其餘服務可以訪問到它，一個容器終止運行以後，須要保證流量不會再導向它。

狀態檢查：

須要持續監控系統是否符合配置中聲明的狀態，好比一臺宿主機掛了，須要把上面運行的容器在其餘健康的節點上啓動起來，若是一個容器掛了，須要把它從新啓動。

從設計思路，社區活躍度等因素來看，Kubernetes無疑是編排工具最好的選擇，但因爲組件較多，學習成本並不低，還有牆的因素，在國內甚至安裝都不是件容易的事。

這個時候咱們發現Rancher正式發佈了，雖然沒有kubernetes那麼熱門，但它提供了全部咱們須要的功能，還有一個簡單容易上手的Web UI。在早期咱們的機器和服務數量都比較少，又急需一個編排工具好把有限精力都投入到開發上，因此迅速的把服務都遷移到Rancher上了。

準確的說，Rancher是一套容器管理打包方案，支持三種編排引擎：Kubernetes，Swarm，還有Rancher本身開發的Cattle（最近好像換成了Mesos）。從功能的完整性和易用性來看，Rancher甚至能夠算得上一個商業軟件了，部署極其簡單，這也是咱們選擇它做爲入門級容器管理平臺的緣由。

Rancher組件圖，中小企業經常使用的軟件功能都能找到：

後來圍繞Rancher，也使用了一些Catalog裏提供的服務棧，咱們逐步搭建起來了一套完整的容器運維繫統，包含了日誌收集，性能監控，配合AWS的Auto Scaling Group，應用擴展也是很方便的事情。

第三階段：Kubernetes

雖然Rancher很是的易用，但隨着咱們後端機器和項目數量的增長，它的一些問題也暴露出來了，UI卡頓，發佈速度愈來愈慢，1.3以後甚至常常出現服務的預期狀態（容器數量，版本）沒法被保證，卡在發佈中或者完成中狀態，真正讓咱們下定決心要遷移的是一次重大故障，疑似網絡雪崩引發，集羣全部機器都在重複斷開鏈接，原本按通常編排系統的設計，worker node上的容器之間經過overlay網絡通訊，node和Rancher server的鏈接即便斷開也不會影響已經啓動的容器運行。但在1.3以後的Rancher中，不知是有意設計仍是bug，worker node從新鏈接上Rancher server以後，節點上全部的容器會被從新schedule，這就致使集羣中全部容器都不斷的被銷燬又從新建立。

在Rancher上碰到大大小小的問題，咱們發現大部分都很難找到社區提供的解決方案，咱們極可能是不幸比較早踩坑的人，雖然Rancher是開源的，但技術上的文檔相比使用文檔明顯欠缺不少，想經過了解他的實現來排查問題比較困難，也不多有Rancher公司以外的contributor，這點是和Kubernetes很明顯不一樣的。

和Rancher提供了一整套解決方案不同，Kubernetes提供的是一個框架，對於Rancher，即便不熟悉其中各個組件，也能夠直接用預設的配置安裝，拿來當一個發佈工具使用，Kubernetes則要求使用者對他的組件有必定程度瞭解，社區提供了不少幫助部署的installer，但使用前都須要很多配置工做。

DevOps同事畫的Kubernetes架構圖：

在Rancher上積累了一些容器編排的經驗以後，咱們對使用Kubernetes作編排也有了一些信心，因而開始遷移到性能更好，社區更活躍的kubernetes上。

咱們將線上服務一點點從Rancher上把流量切換到Kubernetes集羣，起初發現流量稍微增漲便丟包嚴重，定位到問題是DNS解析緩慢，觀察kernel log發現宿主機conntrack count到達上限，出現丟包。

這裏解釋一下iptable裏的conntrack：咱們在使用iptable作面向鏈接的防火牆時，要容許與一個ip地址創建特定鏈接，除了讓該鏈接下的包能進來，還要讓回覆的包能出去，因爲ip是個無狀態協議，這個時候就須要一個session表來記錄有狀態的鏈接，conntrack就是用來記錄這些session的。在微服務下，服務間調用頻繁，會產生大量DNS查詢，linux默認的conntrack_max很容易突破限制，因此在部署有DNS service的機器上設置一個較高的conntrack_max值基本上是必須的。

容器生態

前面介紹了咱們使用容器來作服務編排，除了這些，相對於傳統架構，使用容器咱們還得到了一整套日誌和監控的解決方案，好比日誌採集，部署在容器中的日誌能夠直接打印到標準輸出中，Docker自己支持多種logging driver，能夠將日誌直接發到Graylog，AWS CloudWatch等日誌平臺，也可讓Fluentd等日誌採集工具來採集Docker默認輸出的json-file，相比之下傳統架構可能須要在應用中使用專門配置的logger輸出到收集系統，或者配置專門的採集器去採集不一樣的日誌文件。

小公司對基礎設施的投入不足，通常沒有專人去熟悉Kubernetes這種大型開源項目，但即刻算是一個對技術持開放態度，願意讓工程師去踩坑、嘗試的公司。相對於採用傳統架構，由於容器編排系統都是以提升自己的複雜性來覆蓋繁瑣的配置和腳本編寫工做，自己複雜了就會致使出現問題的時候會比較難排查。但作過運維工做的應該瞭解，通常本身編寫的腳本很難具備通用性，極可能環境稍有改變就不能使用了，運維是比較枯燥的工做，有了編排系統幫助處理這些，咱們能夠把更多的精力放到更有意義的工做上。

題圖By：蒙天放

參考：

jasonwilder.com/blog/2014/0…

thenewstack.io/containers-…

rancher.com/rancher/

conntrack-tools.netfilter.org/manual.html