Linux Namespace （實例隔離）

The purpose of each namespace is to wrap a particular global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource.

每個用戶實例之間相互隔離，互不影響。一般的硬件虛擬化方法給出的方法是VM，而LXC給出的方法是 container，更細一點講就是 kernel namespace。其中pid、net、ipc、mnt、uts、user等 namespace 將 container 的進程、網(wǎng)絡(luò)、消息、文件系統(tǒng)、UTS(“UNIX Time-sharing System”)和用戶空間隔離開。

• pid namespace

不同用戶的進程就是通過 pid namespace 隔離開的，且不同 namespace 中可以有相同 pid。所有的 LXC 進程在 docker 中的父進程為 docker 進程，每個lxc進程具有不同的 namespace。同時由于允許嵌套，因此可以很方便的實現(xiàn) Docker in Docker。

• net namespace

有了 pid namespace, 每個 namespace 中的 pid 能夠相互隔離，但是網(wǎng)絡(luò)端口還是共享 host 的端口。網(wǎng)絡(luò)隔離是通過 net namespace 實現(xiàn)的， 每個 net namespace 有獨立的 network devices, IP addresses, IP routing tables, /proc/net 目錄。這樣每個 container 的網(wǎng)絡(luò)就能隔離開來。LXC 在此基礎(chǔ)上有5種網(wǎng)絡(luò)類型，docker 默認采用 veth 的方式將 container 中的虛擬網(wǎng)卡同 host上的一個 docker bridge—docker0 連接在一起。

• mnt namespace

類似chroot，將一個進程放到一個特定的目錄執(zhí)行。mnt namespace允許不同namespace的進程看到的文件結(jié)構(gòu)不同，這樣每個 namespace 中的進程所看到的文件目錄就被隔離開了。同chroot不同，每個namespace中的container在/proc/mounts`的信息只包含所在namespace的mount point。

• uts namespace

UTS("UNIX Time-sharing System") namespace 允許每個 container 擁有獨立的 hostname 和 domain name, 使其在網(wǎng)絡(luò)上可以被視作一個獨立的節(jié)點而非Host上的一個進程。

• user namespace

每個 container 可以有不同的 user 和 group id, 也就是說可以以 container 內(nèi)部的用戶在 container 內(nèi)部執(zhí)行程序而非 Host 上的用戶。
有了以上6種 namespace 從進程、網(wǎng)絡(luò)、IPC、文件系統(tǒng)、UTS和用戶角度的隔離，一個 container 就可以對外展現(xiàn)出一個獨立計算機的能力，并且不同container從OS層面實現(xiàn)了隔離。 然而不同 namespace 之間資源還是相互競爭的，仍然需要類似 ulimit 來管理每個 container 所能使用的資源——LXC 采用的是 cgroup。

cgroup（資源配額）

cgroups 實現(xiàn)了對資源的配額和度量。cgroups 的使用非常簡單，提供類似文件的接口，在 /cgroup目錄下新建一個文件夾即可新建一個 group，在此文件夾中新建task文件，并將pid寫入該文件，即可實現(xiàn)對該進程的資源控制。具體的資源配置選項可以在該文件夾中新建子subsystem，{子系統(tǒng)前綴}.{資源項} 是典型的配置方法， 如memory.usage_in_bytes就定義了該group 在 subsystem memory 中的一個內(nèi)存限制選項。
我們主要關(guān)心 cgroups 可以限制哪些資源，即有哪些 subsystem 是我們關(guān)心的。

• cpu

在cgroup中，并不能像硬件虛擬化方案一樣能夠定義CPU能力，但是能夠定義CPU輪轉(zhuǎn)的優(yōu)先級，因此具有較高CPU優(yōu)先級的進程會更可能得到CPU運算。 通過將參數(shù)寫入cpu.shares,即可定義改cgroup的CPU優(yōu)先級 - 這里是一個相對權(quán)重，而非絕對值。當然在cpu這個subsystem中還有其他可配置項，手冊中有詳細說明。

• cpuacct

產(chǎn)生cgroup任務(wù)的cpu資源報告

• cpuset

cpusets 定義了有幾個CPU可以被這個group使用，或者哪幾個CPU可以供這個group使用。在某些場景下，單CPU綁定可以防止多核間緩存切換，從而提高效率

• memory

設(shè)置每個cgroup的內(nèi)存限制以及產(chǎn)生內(nèi)存資源報告

• blkio

block IO相關(guān)的統(tǒng)計和限制，byte/operation統(tǒng)計和限制(IOPS等)，讀寫速度限制等，但是這里主要統(tǒng)計的都是同步IO

• net_cls

標記每個網(wǎng)絡(luò)包以供cgroup方便使用

• devices

允許或拒絕cgroup任務(wù)對設(shè)備的訪問

• freezer

暫停和恢復(fù)cgroup任務(wù)

LXC（LinuX Container）

LXC (LinuX Container) is an operating system-level virtualization method for running multiple isolated Linux systems (containers) on a single control host. This is accomplished through kernel level isolation.

借助于namespace的隔離機制和 cgroup 限額功能，LXC 提供了一套統(tǒng)一的 API 和工具來建立和管理 container，LXC 利用了如下 kernel 的特性：

• Kernel namespaces (ipc, uts, mount, pid, network and user)
• Apparmor and SELinux profiles (security)
• Seccomp policies
• Chroots (using pivot_root)
• Kernel capabilities
• Control groups (cgroups)
  LXC 旨在提供一個共享 kernel 的 OS 級虛擬化方法，在執(zhí)行時不用重復(fù)加載Kernel，且 container 的 kernel 與 host共享，因此可以大大加快 container 的 啟動過程，并顯著減少內(nèi)存消耗。

這篇ctackoverflow上的問題和答案很好地詮釋了 Docker 和 LXC 的區(qū)別，能夠讓你更好的了解什么是 Docker， 簡單翻譯下就是以下幾點：

Portable deployment across machines

Docker提供了一種可移植的配置標準化機制，允許你一致性地在不同的機器上運行同一個Container；而LXC本身可能因為不同機器的不同配置而無法方便地移植運行；

Application-centric

Docker以App為中心，為應(yīng)用的部署做了很多優(yōu)化，而LXC的幫助腳本主要是聚焦于如何機器啟動地更快和耗更少的內(nèi)存；

Automatic build

Docker為App提供了一種自動化構(gòu)建機制（Dockerfile），包括打包，基礎(chǔ)設(shè)施依賴管理和安裝等等；
Versioning
Docker提供了一種類似git的Container版本化的機制，允許你對你創(chuàng)建過的容器進行版本管理，依靠這種機制，你還可以下載別人創(chuàng)建的Container，甚至像git那樣進行合并；

Component reuse

Docker Container是可重用的，依賴于版本化機制，你很容易重用別人的Container（叫Image），作為基礎(chǔ)版本進行擴展；

Sharing

Docker Container是可共享的，有點類似github一樣，Docker有自己的INDEX，你可以創(chuàng)建自己的Docker用戶并上傳和下載Docker Image；

Tool ecosystem

Docker提供了很多的工具鏈，形成了一個生態(tài)系統(tǒng)；這些工具的目標是自動化、個性化和集成化，包括對PAAS平臺的支持等。
注：stackoverflow（http://stackoverflow.com/questions/17989306/what-does-docker-add-to-lxc-tools-the-userspace-lxc-tools）

AUFS

Docker 對container 的使用基本是建立在 LXC 基礎(chǔ)之上的，然而 LXC 存在的問題是難以移動——難以通過標準化的模板制作、重建、復(fù)制和移動 container。在以VM為基礎(chǔ)的虛擬化手段中，有 image 和 snapshot 可以用于VM的復(fù)制、重建以及移動的功能。想要通過 container 來實現(xiàn)快速的大規(guī)模部署和更新, 這些功能不可或缺。Docker 正是利用AUFS來實現(xiàn)對container 的快速更新——在 docker0.7中引入了 storage driver, 支持 AUFS, VFS, device mapper, 也為 BTRFS 以及 ZFS 引入提供了可能。

AUFS (Another Union FS) 是一種 Union FS，簡單來說就是支持將不同目錄掛載到同一個虛擬文件系統(tǒng)下(unite several directories into a single virtual filesystem)的文件系統(tǒng), 更進一步的理解, AUFS 支持為每一個成員目錄（類似Git Branch）設(shè)定readonly、readwrite 和 whiteout-able 權(quán)限, 同時 AUFS 里有一個類似分層的概念, 對 readonly 權(quán)限的 branch 可以邏輯上進行修改(增量地, 不影響 readonly 部分的)。通常 Union FS 有兩個用途, 一方面可以實現(xiàn)不借助 LVM、RAID 將多個disk掛到同一個目錄下, 另一個更常用的就是將一個 readonly 的 branch 和一個 writeable 的 branch 聯(lián)合在一起，Live CD正是基于此方法可以允許在 OS image 不變的基礎(chǔ)上允許用戶在其上進行一些寫操作。Docker 在 AUFS 上構(gòu)建的 container image 也正是如此，接下來我們從啟動 container 中的 linux 為例來介紹 docker 對AUFS特性的運用。

典型的啟動Linux運行需要兩個FS: bootfs + rootfs：

bootfs（boot file system）主要包含 bootloader 和 kernel, bootloader主要是引導(dǎo)加載kernel, 當boot 成功后 kernel 被加載到內(nèi)存中后 bootfs就被umount了。rootfs (root file system) 包含的就是典型 Linux 系統(tǒng)中的 /dev, /proc, /bin, /etc等標準目錄和文件。

由此可見對于不同的linux發(fā)行版, bootfs基本是一致的, rootfs會有差別, 因此不同的發(fā)行版可以公用bootfs 如下圖：

典型的Linux在啟動后，首先將 rootfs 置為 readonly，進行一系列檢查，然后將其切換為 “readwrite” 供用戶使用。在 docker 中，起初也是將 rootfs 以readonly方式加載并檢查，然而接下來利用 union mount 的將一個 readwrite 文件系統(tǒng)掛載在 readonly 的rootfs之上，并且允許再次將下層的 file system設(shè)定為 readonly 并且向上疊加，這樣一組readonly和一個writeable的結(jié)構(gòu)構(gòu)成一個 container 的運行目錄，每一個被稱作一個Layer。如下圖：

得益于AUFS的特性，每一個對 readonly 層文件/目錄的修改都只會存在于上層的 writeable 層中。這樣由于不存在競爭，多個 container 可以共享 readonly 的layer。所以docker 將 readonly 的層稱作 “image”——對于container而言整個 rootfs 都是 read-write 的，但事實上所有的修改都寫入最上層的writeable層中，image不保存用戶狀態(tài)，可以用于模板、重建和復(fù)制。

上層的image依賴下層的image，因此docker中把下層的image稱作父image，沒有父image的image稱作 base image。

因此想要從一個image啟動一個container，docker會先加載其父image直到base image，用戶的進程運行在writeable的layer中。所有parent image中的數(shù)據(jù)信息以及 ID、網(wǎng)絡(luò)和lxc管理的資源限制等具體container的配置，構(gòu)成一個docker概念上的container。如下圖：

由此可見，采用AUFS作為docker的container的文件系統(tǒng)，能夠提供如下好處:

節(jié)省存儲空間：多個 container 可以共享 base image存儲
快速部署：如果要部署多個 container，base image可以避免多次拷貝
內(nèi)存更?。阂驗槎鄠€container共享base image, 以及OS的disk緩存機制，多個container中的進程命中緩存內(nèi)容的幾率大大增加
升級更方便：相比于 copy-on-write 類型的FS，base-image也是可以掛載為可writeable的，可以通過更新base image而一次性更新其之上的container
允許在不更改base-image的同時修改其目錄中的文件：所有寫操作都發(fā)生在最上層的writeable層中，這樣可以大大增加base image能共享的文件內(nèi)容。

以上5條 ，1-3 條可以通過 copy-on-write 的FS實現(xiàn)，4可以利用其他的union mount方式實現(xiàn), 5只有AUFS實現(xiàn)的很好，這也是為什么Docker一開始就建立在AUFS之上。

由于AUFS并不會進入 linux 主干 (According to Christoph Hellwig, linux rejects all union-type filesystems but UnionMount.), 同時要求 kernel版本3.0以上(docker推薦3.8及以上)，因此在 RedHat工程師的幫助下在 docker0.7版本中實現(xiàn)了 driver機制, AUFS只是其中的一個driver, 在RHEL中采用的則是Device Mapper的方式實現(xiàn)的 container文件系統(tǒng)。

全文參考

http://tiewei.github.io/cloud/Docker-Getting-Start/
https://docker.cn/a/1
http://blog.dotcloud.com/category/under-the-hood
http://www.slideshare.net/BodenRussell/realizing-linux-containerslxc
轉(zhuǎn)載
作者：seanlook
來源：http://seanlook.com/2014/12/18/docker-core-technology-preview/

運維自動化班 6 期火熱報名中

課程概述：

理論結(jié)合實戰(zhàn)，使學(xué)員既可掌握快速從零構(gòu)建一套實用、完整、可擴展的運維自動化平臺。
1
深度結(jié)合使用流行的 Zabbix、Ansible、Git、Docker、Rancher、ELK 等開源框架與工具， 以為應(yīng)用最廣泛的 Django 框架為基礎(chǔ)，構(gòu)建一站式運維自動化平臺。
2
通過深度剖析與二次開發(fā)定制，結(jié)合 REST API、運維流程化、運維可視化、運維平臺化 思想來構(gòu)造企業(yè)級的運維自動化解決方案。
3
在老師帶領(lǐng)下大戰(zhàn) Zabbix、CMDB、集群自動化部署上線、ELK 日志大數(shù)據(jù)分析、Docker 容器管理平臺等多個最新實戰(zhàn)，天天實戰(zhàn)，招招實用。

上課模式：

網(wǎng)絡(luò)直播班 線下面授班

咨詢報名：

QQ：979950755 小月
WeChat : 1902433859 小月

開課時間：

12月24日（周日）

課程大綱