在容器化落地的实践过程中，难免会遇到很多坑。其中一个坑是就是graph driver的选择问题。当时使用的CentOS的devicemapper，遇到了内核crash的问题。这个问题在当时比较棘手，我们一开始没能解决，于是我们自己写了一版graph driver，命名为vdisk。这个vdisk主要是通过稀疏文件来模拟union filesystem的效果。这个在实际使用中，会减慢创建速度，但是益处是带来了极高的稳定性，而且不再有dm的data file的预设磁盘容量的限制了。因为容器创建后，还需要启动公司的工具链，运维确认，然后切流量等才能完成上线，所以在实际中，该方式仍然有着极好的效果。
不过我们没有放弃dm，在之后我们也解决了dm带来的内核crash问题，这个可以参见蘑菇街对此的分享记录使用Docker时内核随机crash问题的分析和解决。配置nodiscard虽然解决了内核crash的问题，但是在实际的实践中，又引入了一个新的问题，就是容器磁盘超配的问题。就比如dm的data是一个稀疏问题，容量为10G，现在有5个容器，每个容器磁盘预设空间是2G。但是容器文件实际占用只有1G。这时理论上来说，创建第6个2G的容器是没问题的。但是如果这个5个容器，虽然实际文件只占用1G，但是容器中对于某个大文件进行反复的创建、删除(如redis的aof)，则在dm的data中，会实际占用2G的空间。这时创建第6个容器就会因为dm的data空间不足而无法创建。这个问题从dm角度来说不好直接解决，在实际操作中，通过与业务的沟通，将这种频繁读写的文件放置到外挂的volume中，从而解决了这个问题。
从这个坑中，我们也对于后来的业务方做了建议，镜像和根目录尽量只存只读和少量读写的文件，对于频繁读写或大量写的文件，尽量使用外挂的volume。当然，我们对外挂的volume也做了一些容量和写速度的限制，以免业务之间互相影响。规范业务对于容器的使用行为。
docker版本选择在开始研究docker时，docker的稳定版本还是1.2和1.3。但是随着docker的火热，版本迅速迭代。诚然，新的版本增加了很多的新功能。但是也可能引入了一些新的bug。我们使用docker的基本理念是新技术不一定都步步跟上。更多的是考虑实际情况，版本尽量的稳定。落地是第一要务。而且我们的容器平台1.0更偏向于基础设施层，容器尽量不进行重启和迁移。因为业务混合部署在集群中，当一个宿主机上的docker需要升级，则容器需要迁移，那么可能涉及到多个业务方，要去与各个业务方的运维、研发等进行沟通协调，相当的费时费力。我们在充分测试之后，定制了自己的docker版本，并稳定使用。docker提供的功能足够，尽量不再升级，新增功能我们通过其他的方式进行实现。
监控与巡检这里所指的监控主要指对资源，如CPU、内存等的监控。如前文中所述，由于容器的隔离性不足，因此容器中使用top等看到的信息，也不完全是容器内的信息，也包含有宿主机的信息。如果用户直接在容器中使用工具获取资源监控信息，容易被这些信息误导，无法准确判断资源的使用情况。因此我们自己研发完成了一套容器平台监控系统，负责容器平台的资源监控，对于物理机和容器的资源使用情况进行采集和整理，统一在前端呈现给用户。并集成了资源告警、历史查询等功能。
由于容器平台系统，包含了多个子系统，以及许多的模块。系统庞大，就涉及到了诸多的配置、状态检查等等。我们对应开发了一套巡检系统，用于巡查一些关键信息等。巡检系统一方面定时巡查，以便核实各个组件的工作状态；另一方面，当出现状况时，使用巡检系统对于定位出现问题的节点，分析问题产生的原因有极多的帮助。
标准化的工具在没有容器化之前，公司内部逐渐形成了自己的一套工具链，诸如编译打包、自动部署、统一监控等等。这些已经为部署在物理机和虚拟机中的应用提供了稳定的服务。因此在我们的私有云落地实践中，我们尽可能的兼容了公司的工具链，在制作镜像时，将原有的工具链也都打入了镜像中。真正实现了业务的平滑迁移。