編譯自：
http://blog.pivotal.io/cloud-foundry-pivotal/features/cloud-foundry-container-technology-a-garden-overview
http://underlap.blogspot.com/2014/06/warden-meets-libcontainer.html
CloudFoundry（CF）中很早就使用了VMware研發的Warden容器來負責應用的資源配置設定隔離和執行個體排程。可惜的是，這一本來可以成為業界标準和并掀起一陣革命的容器PaaS技術卻因為Pivotal的方針路線上的種種原因被後來居上Docker吊打至今。最近CFer有醒悟的迹象，在Warden上進行了大量改進和更新，本文就來一窺CF新容器技術的一些要點。
Warden和Garden
Warden背景：
"CloudFoundry’s container technology is provided by Warden,which was created by VMware’s Pieter Noorduis and others.Warden is a subtle combination of Ruby code, a core written inC, and shell scripts to configure the host and containers."
在此前的WardenDEA中，在每個安裝好的DEA上都會運作Warden服務（Ruby寫的，調用大量shell來配置host），用來管理Cgroup，Namespaces和以及程序管理。同時，Warden容器的感覺和狀态監控也由此服務來負責。作為一個C/S結構的服務，Warden使用了谷歌的protobuf協定來負責互動。每個容器内部都運作一個wshd daemon（C語言寫的）來負責容器内的管理比如啟動應用程序，輸出日志和錯誤等等。這裡需要注意的正是由于使用了protobuf，warden對外的互動部分強依賴于wardenprotocol，使得warden對開發者的易用性大打折扣。
Wardenstructure
在CloudFoundry的下一代PaaS項目Diego中，Pivotal團隊對于Warden進行了基于Golang的重構，并建立了一個獨立的項目Garden。在Garden中，容器管理的功能被從server代碼裡分離出來，即server部分隻負責接收協定請求，而原先的容器管理則交給backend元件，包括将接收到的請求映射成為Linux（假如是Linux backend的話）操作。值得注意的是：這樣backend架構再次透露出了warden跨平台的野心，可以想象一旦Windowsbackend被社群（比如IronFoundry）貢獻出來後的威力。更重要的是，RESTful風格的API終于被引入到了Garden裡面，原作者說是為了實驗和測試，但實際上Docker最成功的一點正是友好的API和以此為基礎的擴充能力。
Gardenstructure
Namespaces
容器化應用依然通過namespaces來定義它所能使用的資源。最簡單的例子，應用的運作需要監聽指定的端口，而傳統方法中這個端口就必須在全局的host網絡namespaces上可見。為了避免應用互相之間出現端口沖突，Garden服務就需要設定一組namepaces來隔離每個應用的IP和port（即網絡namespace）。需要再次強調，容器化的應用資源隔離不同于傳統的虛拟化技術，雖然我們在講容器，但是我們并沒有去建立“什麼”，而是為實實在在運作着的應用程序劃分屬于它自己的“命名空間”。
Garden使用了除使用者namespace之外的所有namespace技術。具體實作是使用挂載namespace的方法來用使用者目錄替換原host的root檔案系統（使用pivot_root指令），然後unmount這個root檔案系統使得從容器不會直接通路到該目錄
備注：Linux在很早之前就支援了namespaces技術，從一開始為檔案系統挂載點劃分namespace，到最新的為使用者添加namespace，具體演化參見：Articles on Linux namespaces
ResourceControl
被限制在運作在namespaces中的應用可以在這個“匿名的作業系統環境“中自由的使用類似于CPU和MEM這樣的資源，但是應用仍然是直接通路系統裝置的。Linux提供了一系列controlgroups來将程序劃分為層級結構的組然後将它們限制到不同的限制中。這些限制由cgroup中的resourcecontrollers來實作并負責與kernel子系統進行互動。舉個例子：memoryresource controller可以限制一個controlgroup中的程序能夠在真實記憶體中使用的頁數，進而確定這些程序在超出限制後被停止。
Garden使用了五種資源控制：cpuset(CPUs and memory nodes) , cpu (CPU bandwidth), cpuacct (CPUaccounting), devices (device access), and memory(memoryusage)，并通過這些資源控制堆每一個容器設定一個controlgroup。是以容器中的程序将被限制在resourcecontrollers指定的資源數下運作（嚴格地說cpuacct僅統計CPUusage，并不做出具體限制）。
此外，Garden還使用setrlimit系統調用來控制容器中程序的資源使用；使用setquota來為容器中的使用者設定配額。這一點上也同Warden相同。
NetworkingFacilities
簡單來說，每個容器都運作在獨立的網絡namespace中，Garden負責控制進出容器的網絡流量。Garden會建立一對veth（虛拟網卡）裝置，為它們配置設定IP，然後将其中的一個放到容器的網絡namespace中。接下來Garden會設定IP路由表來保證IP包能夠正确地傳入或傳出容器。最後，網絡包過濾規則會為容器建立防火牆來限制inbound和outbound的流量。這一點上與Warden原先的網絡相同。
Containernetworking
RootFile System
Warden是允許使用者自己指定一個root檔案系統來供容器使用的。而Garden不僅繼承了這個功能，更重要的是還能支援從Docker image來建構rootfs。同時，Garden在rootfs中引入了rw權限的層，是以容器可以疊加自己的rootfs而不影響其他容器（比如container A是warden rootfs，而container B是docker rootfs）
GardenAPI
新的Garden API同樣是基于Google protobuf的，包括如下所有操作：
- Capacity– returns the memory and disk capacity of the host machine
- Create– creates a container and returns its handle (a string which identifies the container)
- Info –returns information about a specified container such as its IPaddress and a list of processes running in the container
- Run –spawns a process in the container and streams its output back to theclient
- Attach– starts streaming the output of a specified process ina specified container back to the client
- List –lists all container handles
- LimitBandwidth,LimitCpu, LimitDisk, LimitMemory – adjusts the limits of aspecified container for network bandwidth, CPU shares,disk usage, and memory usage, respectively
- NetIn –maps a port on the host machine to a port in the specified container
- NetOut– whitelists outbound network traffic from the specified containerto a specified network and/or port
- StreamIn– copies data into a specified file in the specifiedcontainer’s file system
- StreamOut– copies data out of a specified file in the specifiedcontainer’s file system
- Ping –checks that the garden server is running
- Stop –terminates all processes in a specified container but leaves thecontainer around (instopped state)
- Destroy– destroys the specified container
Merge Warden with Docker?
與此同時，Pivotal還計劃通過更通用的驅動層來将Docker直接merge到現有的系統中。主要實作方式是為前面所說的backend添加libcontainer-specific backend，如下圖所示：
這樣，使用者的請求将通過這個backend翻譯成libcontainer API來啟動Docker鏡像——比如将使用者的應用run在Docker而不是Warden容器中。但是這個feature是作為一個長期計劃與Garden并行的，主要原因應該是libcontainer的API并沒有完全ready，目前還在采用很初級的替代方案。
綜上，CF的新容器技術向後來者Docker展示了友好的一面，并且把握住了Docker image這一核心value而不是費力不讨好地支援所有Docker feature。但是這此的改動還是一次被動的應對，恐怕隻有Windows backend和libcontainer backend的及時release才能迅速扭轉局面。