八月15日（话说Docker官方真会挑日子），Docker CE发布了17.06版本的第一个修复版本。该修复版本似乎并没有大张旗鼓的宣传（不过怎么才算“大张旗鼓”呢？）。但是修复了两个重要的BUG，值得在此一记。

copy --from和force pull冲突

这个BUG是怎么回事儿呢？话说17.06这个版本，Docker发布了非常给力的Multi-Stage Build新特性，解放了一众先编译后打包的docker用户。我也在第一时间修改了项目中的dockerfile，合并了两个编译和打包的dockerfile。然而当我像往常一样调用CI工具编译时，却发现报错了。

报错的原因是什么呢？原来是我的CI工具每次编译，都会强制docker engine去pull基础镜像，以确保基础镜像最新。然而在17.06这个版本里，这个选项和Multi-Stage Build特性冲突了。

这个版本修复了这个问题。目前据我亲测两者可以友好的一块儿玩耍了。

overlay网络IP重叠

相关的PR请参阅：[17.06] vndr libnetwork to bring in fix for overlay network ip reuse。

先说句题外话，Docker真是不靠谱。同一个版本把修改记录从Github誊到release note，都能誊掉（一看就不是个作弊的好人才）。掉了的刚好就是这个修复overlay网络IP地址重绑定的问题。

这个问题具体是什么，可以看看Github中PR的描述，内容如下：

libnetwork IPAM recycles the IP address when a task goes down on a node and brought up in another node. For remote tasks overlay network namespace has one static fdb entry programmed by the driver and one dynamic entry learned by the bridge from the data path when a packet is received from the remote container. The dynamic entry ages out after 300 seconds. If a task on a remote node goes down and gets scheduled on a node the dynamic fdb entry still remains. Unless the container generates some data traffic it won’t be updated. This can lead to unpredictability in accessing the container; sometimes it will work pretty quickly if there is some traffic from the container and the mac entry gets updated. If the container is completely silent it can lead to upto 300 seconds of traffic loss.

大致就是说，因为设计机制的问题，某些overlay网络中的service task容器长期没有网络请求，会导致其他节点上的该任务路由表不能及时的更新。甚至当这个任务挂掉的时候，如果新启动起来的任务刚好在其他未更新节点上时，会导致对该task容器的访问出现一些不可预料的错误。

再简单的说，就是在overlay网络中的service容器有一定概率无法访问，甚至串访。当然这个简单版本的描述，并不全是这里的问题所致。由于之前被这个问题搞得整个docker swarm集群几乎残废。之前发现nginx的DNS缓存是其中一个原因，但是后来发现docker本身有更严重的问题。所以我会谨慎的确定是否这个问题已经得到了完全的解决。