LXC
有了前兩節的基礎，我們已經可以，創建出一個隔離環境了，也就是有了所謂的名稱空間，有了名稱空間，我們應該往名稱空間內放什麼東西呢。。。
假如我們在一個centos的機器上，想創建出一個ubuntu的名稱空間，最起碼我們應該將ubuntu的文件樹這類的東西拿到我們本地來，在本地的一個目錄下面找一個節點，將其初始化爲根節點，將這個東西全都放進去，那麼這些東西從何而來呢，這個時候就有了一個工具LXC，使用LXC的時候，LXC將會給我們創建一個名稱空間，並且再此基礎上，從他的倉庫中，將所對應的文件全部拉到本地，然後進行一系列的初始化，最終將該名稱空間下的6的命名空間全部寫出來，此時我們就可以像虛擬機一樣使用這個容器了。但是問題又出現了，我們如何將我們這個創建的名稱空間遷移，如果我們要創建很多很多這樣的名稱空間，又該如何！在資源使用這方面，LXC確實比虛擬機要好，但是如何大規模使用，目前看來也沒有什麼好的解決方式，此時docker就出來了
docker
docker說白了其實就是一個工具，使用這個工具來操作內核，由內核來創建隔離空間，docker也是一個類似與LXC的工具，只不過比他功能更加強大，而容器技術是linux本身就有的。但是有了docker，我們可以更加方便的使用容器，而docker讓這一切變得簡單的原因就在於他的一個初始化過程的變化，他使用了鏡像這種技術，不在從官方那邊拉文件，而且將所有需要的東西全部打包成一個鏡像，當名稱空間初始化完成了之後，使用這個鏡像文件，將該名稱空間初始化掉，並運行相應的進程。
我們可以將一個最純淨的centos或者ubuntu做成一個鏡像，放在互聯網上，大家就可以依靠這種基礎鏡像，在基礎鏡像之上再構建自己的應用，再將其打包成新的鏡像，有了這個鏡像我們就可以實現大規模部署，遷移之類的了，或者類似於nginx這種的，也可以做一個純淨版的。
早期的docker版本都是使用lxc作爲docker引擎的，在後面的版本中過渡到了自己的libcontainer引擎，再後面就使用了runC。
在2013年Docker剛發佈的時候，它是基於LXC的開源容器管理引擎。Docker把LXC複雜的容器創建與使用方式簡化爲自己的一套命令體系。
隨着Docker的發展，原有的LXC不能滿足Docker的需求（比如跨平臺），於是Docker公司把底層實現都抽象化，底層容器的實現方式變成了一種可變的方案，這就是libcontainer的誕生。從此之後，無論是使用namespace、Cgroups技術或是使用systemd等其他方案，只要實現了libcontainer定義的一組接口，Docker都可以運行。
在DockerCon 2015期間，Docker牽頭成立了OCI（Open Container Initiative開放容器計劃）組織，這個組織的目的是建立起一個圍繞容器的通用標準。
容器格式標準是一種不受上層結構綁定的協議，即不限於某種特定操作系統、硬件、CPU架構、公有云等，這樣做的目的是減少因爲行業內的惡性競爭，提供一個標準，允許任何人在遵循該標準的情況下開發應用容器技術，這使得容器技術有了一個更廣闊的發展空間，OCI下的容器技術不屬於任何公司或個人。
早期libcontainer是Docker公司控制的一個開源項目，隨着OCI的成立，Docker把libcontainer項目移交給了OCI組織，目前可以在https://github.com/opencontainers/runc中查看libcontainer的源代碼，目前libcontainer作爲runC項目的一個子項目。
runC就是在libcontainer的基礎上進化而來，Docker已經表明未來會使用runC替代libcontainer作爲容器runtime的工具。
從名字上可以看出runC是一個runtime工具，而libcontainer只是一個lib庫，不是runtime管理工具。runC通過調用libcontainer提供的接口來管理容器。早期runC沒有出來之前，libcontainer有一個內置的小工具nsinit，可以用這個內置小工具來管理容器。後來runC基於這個小工具做了改動，並改名爲runC。隨着runC的不斷髮展，目前runC已經成爲一個功能強大的runtime工具。當前，我們只需要知道runC的核心依舊是libcontainer就可以了。
moby
docker-ee，docker-ce，moby是docker三個不同的版本
moby是繼承了原先的docker的項目，是社區維護的的開源項目，誰都可以在moby的基礎打造自己的容器產品
docker-ce是docker公司維護的開源項目，是一個基於moby項目的免費的容器產品
docker-ee是docker公司維護的閉源產品，是docker公司的商業產品