在不重启动容器的情况下，允许从外部访问到容器内部的端口

有时启动了容器，花了好久才启动完成（例如有的db启动要花几分钟分析巨大数据文件），忽然想起来，忘了加-p port:port选项，无法从Docker主机外访问容器里的端口了。在不退出容器的情况下，找了几个方法。

目前的docker,还没有实现好热备份，一旦退出容器，即使commit到image里再启动那个image，也只不过省了文件状态恢复的时间，却不会省下db启动时分析巨大的数据文件所需的时间。

所以有必要，在不退出容器的情况下，设法让人通过访问Docker主机的某个port来访问到容器里面的某个port。目前有两个方法：

• 在Docker主机里用iptables加个端口转发规则。

  sudo iptables -A PREROUTING -t nat -p tcp --dport Docker主机port -j DNAT --to 容器ip:容器port
  

• 如果是在用VirtualBox里的docker-machine做Docker主机，那么还有一个方法是物理主机上加上个路由使得能够直接访问到容器的ip。

  sudo route -n add 容器ip/32 Docker主机ip
  

  这时Docker主机ip是指docker-machine ip default的结果。这样一来，可以直接访问容器ip:容器port了。

都做过实验，具体的在Docker启动容器时的port公开方式，破除一些含糊的地方

操作系统对应用的包围圈在逐渐缩小，VM->Container->Unikernel

一个有趣的趋势。

很多年前，还没有OS，各App都是裸奔。

后来造出了Unix等OS,于是多个App共享OS这个衣服。

后来零星的，出现了chroot之类的原始容器技术，给各App穿上了虚拟的衣服，但是很不堪使用。

后来出现了VMWare之类的虚拟机,于是多个App共享VM这个厚重的衣服。

后来各系统都在有意无意的完善VM，chroot,zone，Container等衣服。

iOS为各App都罩上了一层轻巧而且越来越结实的外套(chroot+MAC+...)。

Android为各App加上了一层疏松的外套（所以在不断用selinux等新招来补洞）。

最近三年来，Docker公司和一批有志者，把这件Container这种虚拟衣服做得愈来越轻巧结实。

在OS和VM里，很多个App一起磕磕碰碰，不能尽兴。 在Container里，App觉得自己充满力量，拥有整个世界，怎么折腾都行。 但在OS或者VM看来，Container是如来佛手里的孙悟空。

Unikernel这就近似于变态，includeOS令人震撼，一个App和OS编译成一个整体。OS这个衣服融合到App身体里去了。

哈哈哈。