摘要：是一個典型的模式架構，用戶通過終端將字符流傳遞給。仿照的工作原理，我們在協議之上設計了，見下圖真實實現中，是應用層的通訊協議。僵尸進程問題我們知道由于缺少而導致僵尸進程無法回收的問題迄今存在。進入構建環境執行命令。

Coding WebIDE 做個國內首個基于 Docker 技術的云端開發平臺于4月1日正式上線。本文主要和大家分享和探討 Docker 在 Web IDE 中運用的一些經驗。

隨著云計算技術的日新月異，云端的代碼倉庫，分工協作，演示運行已經被人們廣為接受。云端開發的出現也正是順應了這一趨勢。Docker 作為一個輕量級的隔離環境，無疑是云端開發解決資源和效率問題的秘藥良方。

記得4月份的杭州 Docker Meetup 有一與會者提問，“作為一個云主機的租戶，向主機商購買的計算資源，其獲得的配額不是真實值而只是上限，覺得不值。”這個問題似乎揭露了商家的生意經，但是本人卻有不同的看法。正是因為共享技術的發展，才讓云計算資源變得廉潔而被廣為接受，Docker 最大的價值也在這里。

從技術特性上看，VM 和 Docker 有些重合點。但是Virtual Machines 是基于 Hypervisor 技術的，而 Docker 是基于Container 技術的。Hypervisor 要比 Container 更底層，不是同一層面的競爭關系，真實的場景多是先 Hypervisor 再 Container，通俗的說法就是在 VM 里跑Container。

Hypervisor 技術讓多個操作系統共享一個CPU硬件，這些操作系統獨立運行，并不知道彼此的存在，仿佛獨占了所有的硬件資源。

Container 技術讓多個用戶空間共享一個操作系統，這些用戶空間彼此隔絕，仿佛獨占整個操作系統。

我們都知道，文件是對 I/O 設備的抽象表示，虛擬存儲器是對主存和磁盤 I/O 設備的抽象表示，進程則是對處理器、主存和 I/O 設備的抽象表示。相比之下，虛擬化將操作系統從硬件中抽象出來，容器技術將應用從操作系統抽象出來。

一個正在執行的進程，由于虛擬內存技術，就其視角來看，仿佛擁有了整個操作系統的計算資源。但是 Container 的抽象和進程抽象不是在一個層面的。簡單說，一臺物理設備可以借助于 Hypervisor 技術，運行多個 VM；而個操作系統可以借助 Container 技術，運行多個 Container；而 Container 里可以有多個進程。

上面簡單的介紹了一些 Docker 技術的背景，言歸正傳。

實現 WebIDE 首先解決的就是環境隔離，多個用戶之間不會相互干擾。物理機是相互隔離的，但是為每一個用戶分配一臺真實的物理機，顯然是不合現實的。

VM 可以提供和物理機一樣的隔離效果，由于 VM 共享硬件，所以更省資源。一個可行的方案是借助 IaaS 平臺商提供的 OpenAPI 來操作 VM。這樣對物理主機和宿主操作系統的維護工作可以完全委托給IaaS平臺商。

相比 Docker Container，VM 有一個很大的技術優勢是支持休眠。操作系統在系統級實現了休眠，這樣用戶的工作狀態，內存中的數據可以完整的持久化。作為一個常年不關機的開發者，個人覺得這個功能非常實用。可惜Docker 只提供了睡眠（類似于進程級別的掛起），而做不到休眠。隨著CRIU技術的發展，相信 Docker 很快會支持的。

另外 VM 在不同宿主機之間的遷移問題，經過多年社區的積累越來越成熟。如果選擇向 IaaS 平臺商購買 VM 服務，這部分工作也不用關心。Docker Container 數據的遷移，面臨著自制。目前Docker 官方提供遷移Container（非image）的命令，只能遷移文件，無法保留狀態（比如外部mount的目錄）。

考慮到架構的微服務化，如文件服務，Git 服務，Terminal 服務，Runtime 服務。有些服務是單例的，另一些則會隨著用戶會話狀態而動態地創建和銷毀。當應用實例很多的時候，虛擬化技術的 Overhead 是需要考慮的因素。為了某個服務而啟動整個操作系統有些負擔不起。除了過度的內存消耗，啟動耗時也存在差異，Container 只是用戶空間的一個或者一組進程，所以啟動耗時基本是毫秒級別，而 VM 至少是秒級，有的甚至是分鐘級（休眠還原的時候）。

做比較的時候總是各有優劣，但最終打動我們的除了 Docker 的輕量，還有其生機勃勃。我們相信備受社區關注的技術，許多顧慮的問題終究會有解決方案的。

一個完整的 IDE 需要具備很多功能，文件管理，版本管理，編輯器（語法高亮，自動補全），編譯器，執行環境等等。Rome was not built in a day。初次上線的最小功能集合里，我們認為 Web IDE 區別于 Web Editor 的一個功能亮點就是 Web Terminal。

Web Terminal 和 SSH 的工作原理類似，通過架設在 TCP 之上的應用層協議實現對主機的遠程控制。相信大多數開發者都有 SSH 的使用經驗，理解其工作原理的僅占少數。開始研究之初，我們也和大多數人一樣搞不清楚terminal, tty, pty, shell, bash 之間的區別，所以先來理理概念。

從用戶的角度來看，Terminal 是鍵盤和顯示器的組合，也稱為TTY(TeleTYpewriter,電傳打字機的縮寫)。鍵盤輸入字符，顯示器顯示字符。從進程的角度來看，終端是字符設備，可以通過 read,write,ioctrl 等系統調用來讀寫和控制該設備。

TTY 早已進入了博物館，桌面系統上字符界面基本被 GUI 界面替代。取而代之是一個稱之為 Terminal Emulator（終端模擬器）的窗口程序，該程序顯示的字符界面就是曾經物理顯示器里的完整內容。

Terminal 作為真實的物理設備已經不復存在了，但是為了和面向終端的程序（比如 Bash）進行通信，于是就了發明了 pty（Pseudoterminal，偽終端）。pty 是一對 master-slave 設備，master 設備表現得像一個文件，slave 設備表現得像一個終端設備，當 Terminal Emulator 作為一個非面向終端的程序不直接與 pty slave 通訊，而是通過文件讀寫流與 pty master 通訊，pty master 再將字符輸入經過線路規程的轉換傳送給 slave ，slave 進一步傳遞給 bash。

Bash 一個命令行的解釋器，通常也是進程會話的主進程，其職責是解釋執行終端設備（或者偽終端的 slave 設備）傳遞過來的字符串和控制字符，執行命令。

理解了上面背景知識之后，再看 SSH 的原理圖。

SSH 是一個典型的 server-client 模式架構，用戶通過終端將字符流傳遞給SSH client。SSH client 和 SSH server 之間通過 TCP/IP 協議進行通訊。遠端的 server 創建一對 pty，并且 fork+exec 一個 bash 進程，server 進程通過 pty 對與 bash 進行交互。

仿照 SSH 的工作原理，我們在 HTTP 協議之上設計了 Web Terminal，見下圖

真實實現中，socket.io 是應用層的通訊協議。Terminal Emulator 是一個純JS的實現，nodejs 后端使用 pty.js 模塊來創建 pty 對。

當解決了 Web Terminal 的整體架構以后，嵌入 Docker Container 已是水到渠成。

我們知道 Docker 由于缺少 init 0 而導致僵尸進程無法回收的問題迄今存在。Terminal 作為控制終端，會在使用過程中執行若干命令，這些命令對應進程如果與其父進程脫離父子關系，那僵尸進程問題就來了。

Docker 官方推薦的一個 Container 只跑一個進程。如果 Container 與進程同生共死，僵尸進程的問題基本不會遇到。但是 Web Terminal 所在 Container 里啟動了bash，而 bash 可以隨意執行命令啟動進程，僵尸進程問題很難避免。好在社區提供了更好的解決方案：phusion/baseimage。在Dockerfile里將的 FROM ubuntu改為FROM phusion/baseimage,再按照文檔說明做些調整基本就好了。

通常，我們都是把 App 部署到 Docker 里去。大致步驟就是編寫 Dockerfile ，再構建成 image，然后借助 private registry 在分布式的集群中分發。由于開發環境、測試環境和生產環境存在差異，往往構建交付物涉及到大量參數和環境變量的設定，過程非常繁瑣，一般都會腳本化。所以IDE項目基本都是 Dockerfile 旁邊放置了一個 Gemfile 和 Rakefile。通過 Ruby Rake 來驅動整個構建過程。

作為腳本語言與 Shell 相比，Ruby 的好處是

隔絕了 Darwin，Linux 平臺之間某些命令的細微差異；

對于 Shell 擅長的部分，可以通過"`"符號方便的嵌入調用；

具備完備正則等字符串處理功能；

方便調用 Docker api 的

可以集成 Capistrano 等分布式管理工具

但 Ruby 不像 Shell 那樣信手拈來，需要進行適當的配置，比如，RVM 安裝指定版本，修改 gem source 之類的。

從前配置這些基礎環境，都是記錄成 Markdown 文檔，一堆 apt-get，sed 指令。但是引入 Docker 以后，有更好的選擇。

我們的方式如下：

編寫一個配置構建環境的 Dockerfile，構建成 image。

docker build --rm -t="ide-docker-registry.coding.local/ide-builder:0.0.5" .

push 到 registry 里。

docker push ide-docker-registry.coding.local/ide-builder

在構建服務器創建構建所需的builder,通過mount外部目錄的方式，構建環境和外部環境交互文件。

docker run --name coding_ide_builder -d -t -v $CODING_IDE_HOME:/data/coding-ide-home  --net=host --restart=always ide-docker-registry.coding.local/ide-builder

進入構建環境執行命令。

docker exec -i -t coding_ide_builder bash

或者直接構建。

docker exec -i -t coding_ide_builder rake

資源限制主要針對CPU、內存、磁盤和網絡帶寬等共享資源的限制。一方面，我們提倡共享，事實上不是所有的用戶都需要長時間的占滿所需的資源配額，不需要的時候可以釋放出來分享給其他用戶，因為共享才會更便宜。另一方面，也需要對可共享資源設定一個最大的限制配額，以防止某些用戶過度占用而影響其他用戶的使用體驗。

Docker 提供了兩個參數來控制 cpu 的分配策略，--cpuset 和 --cpu-shares 。

--cpuset="0" [...] 將Container限定于某幾個CPU核心上。針對這一特性，我們制定的策略是將重要的 Container 服務分配在獨立的核心上，以保證服務的質量。

--cpu-shares 可以調節Container獲得的時間片。我們通過這個配置來調節 Web Terminal 所創建進程對CPU的占用率。

Web Terminal 里用戶的自由度是很大的，對內存限制可以減少惡意破壞。Docker 配置內存限制相對簡單。另外，我們禁用了swap分區，以減少對磁盤的壓力。

由于用戶可以完全自由的訪問磁盤，我們最希望 Container 磁盤鏡像文件具備 thin provisioning 特性，不需要預分配所有空間也可以限定其大小。

對于 Container 的磁盤限制分為兩部分，對最上層可寫 layer 的限制和對被 mount 的可寫目錄的限制。

限制可寫layer

Docker Daemon 提供了四種 storage-driver: aufs, devicemapper, btrfs, overlay。aufs 在其被支持的 linux 發行版上，是默認的 storage-driver。否則 Docker 會啟用 devicemapper。aufs 最早被 Docker 支持，而且支持共享二級制文件和動態庫文件所占用的內存，btrfs 和 overlay 不支持此特性，但是比aufs速度更快。devicemapper 的特點是支持 thin provisioning 和 copy on write。

限制 layer 的大小，devicemapper 是目前唯一的選擇。啟動 devicemapper 后，Docker 會為所有的 Container 創建一個共享存儲池，其實質上是一個大文件，另外也會限定每個 Container 的大小。這兩個數字的制定需要慎重，因為考慮到數據遷移，修改很不容易。

限制被 mount 的可寫目錄

Docker run 的時候 mount 進 Container 的可寫目錄是不受 devicemapper 的限制，所以需要額外處理。WebIDE 場景中 workspace 目錄是被多個 Container 實例中共享讀寫的，作為用戶工作目錄，需要設定一個最大的空間限制。

談到 linux 磁盤空間限制，最先想到 quota。quota 常用于ftp服務，限定用戶最大可用空間。但 quota 有一個技術限制，僅僅適用于整個文件系統而無法針對單個目錄。所以 quota 方案在共享目錄的場景不可行。

linux 支持將一個磁盤鏡像文件 mount 成目錄，磁盤鏡像文件可以限定大小。當鏡像文件撐滿的時候，目錄就不可寫了。這是我們目前找到最靠譜的方案。

Docker 沒有直接提供限制網絡帶寬的命令行參數，但借助 Docker 的底層技術 cgroup 可以實現。創建一個 Network classifier group，對 cgroup 進行帶寬限制的設定，將 Container 都指定到該組里去。Traffic Controller(tc) 和 Netfilter(iptables) 都支持針對 cgroup 指定規則。

base 在 Docker 之上，更容易實現架構的微服務化。借助于 Docker 的 link 特性和 fig 工具，Container 可以像樂高積木一樣把所有的組件都組合起來。Nginx，Jetty，MySQL，Redis 等一系列服務可以封裝到獨立的Container 里去。

全面 Dockerize 的最大好處是整個體系都是一致的，所有的組件都是Container。WebIDE 在架構初期，考慮全面 Dockerize 的方案，比如把 MySQL 分成兩個 Container ，一個存放安裝文件，另一個存放數據文件。應用服務器自不必說也在 Container 里。但是當考慮 Nginx 是否也要放進 Container 里，大家想法有些分歧，Container 的好處在 Nginx 上是否明顯值得探討。也正因為存在不同的聲音，我們放棄了全面 Dockerize。個人的覺得已有的經驗和腳本不應該放棄，節省出更多的精力來做更重要和緊迫的事情。

Hypervisor - Wikipedia

Operating-system-level virtualization - Wikipedia

User space - Wikipedia

Basics – Docker, Containers, Hypervisors, CoreOS

devicemapper - a storage backend based on Device Mapper

Resizing Docker Containers with the Device Mapper plugin

Network classifier cgroup

  

  
  Vangie Du
  
  
將來的你，一定會感謝現在拼命努力的自己！
本文出自 Coding 官方技術博客，如需轉載請注明作者與出處。