自Docker诞生之初，就采用了aufs做为唯一的存储驱动。但因为aufs一直没有进入内核主线，所以各大发行版只有Ubuntu默认包含了aufs支持，这让Docker某种程度上成了专用于Ubuntu的容器技术。

直到后来红帽工程师为其实现了devicemapper存储驱动，其它发行版上使用Docker的技术门槛才低了许多。但是受内核的devicemapper机制的限制，Docker的devicemapper驱动在性能和资源消耗上相比aufs驱动都仍有差距。

直到内核版本3.18，另一个unionfs文件系统实现overlayfs并入了内核主线。而Docker（自1.4.0版本开始）在很短的时间内就提供了对overlayfs存储驱动的试验性支持。从此在各大发行版上使用unionfs做为Docker的存储驱动才成为了可能。

而我本人由于Docker+devicemapper驱动在使用中的种种问题，当然是盼望着尽快试用Docker的overlayfs驱动。

$ docker save -o /media/Storage/dockers/centos.tar centos:centos6
$ docker save -o /media/Storage/dockers/debian ...

话说上次利用Docker建立Oracle测试环境之后，环境创建和销毁都成了很轻松的事情，我似乎从此过上了幸福快乐的日子。无奈美梦从来最易醒，在这段时间的使用过程中，理想与现实的差距却逐步暴露了出来。其中一些问题甚至直接影响到Docker的可用性，让人实在不吐不快。

# cat /lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target docker.socket
Requires=docker.socket

[Service]
ExecStart=/usr/bin/docker -d -H ...

最近一直在研究Docker，尝试拿它做一些小型的开发试验环境，确实是相当好用。

某日突发奇想，打算将我的Oracle实验环境迁到Docker中来。虽然最终得到的镜像有点头重脚轻，不太符合Docker推荐的使用方式，但相比虚拟机好歹也节省了些开销。

实验过程中各种方式折腾了好几轮，感觉都不太完美。先将过程做个记录，期望将来能找到更好的办法。

OS: Arch Linux (内核3.16.4-1)64位
Docker: 1:1.3.0-1
容器OS: CentOS 6 ...