Docker映象档大变革，全新ID杂凑编码，更安全也省空间

2016年才到不久，Docker就推出Docker Engine 1.10 RC版本。而Docker表示，新版本Docker Engine能为映像档提供更好的安全基础外，Docker也提供旧映像档更新的搬迁步骤（migration step），并且提供相关搬迁工具，将迁移时间降到最低。

Docker资深工程主管Arnaud Porterie表示，Docker Engine 1.10版本将完全改变Docker Engine在本机储存映像档的方式。过去的映像档都是随机指派通用唯一辨识码（Universally Unique Identifier，UUID）进行命名，而新版本透过则安全杂凑（secure hash）的机制，Docker得以透过映像档的内容，为映像档进行ID编号。

著《Docker源码分析》的孙宏亮解释，Docker从UUID改由安全杂凑机制命名，其中关键差异在于，Docker每一层layer的映像档ID，全部都必须透过映像档内部的资料来产生，不再是使用过去的随机UUID。他表示，借由此方法，透过docker build建构映像档时，映像档内容与映像档ID，将会形成1对1的对应关系。

由于每一个映像档仅会产生一组独特的ID，因此可以减少储存同样一份的映像档，孙宏亮表示，对于减轻Docker Hub的储存压力也是大有好处。他也举例，过去同一个Dockerfile，在10台不同的机器上build，因为映像档快取仅仅在本机端有效，因此将会产生10个内容相同，但是ID编号不同的映像档。另外，由于是透过UUID产生随机编号，如果这10台机器，分别把这10份映像档储存到同样的Doocker Registry，则会产生多余的9份映像档，因此也会对Docker Registry产生储存上的压力。

孙宏亮也解释了为何新版Docker Engine使用杂凑机制的命名方式，将会比使用UUID命名映像档来得更加安全。他表示，由于映像档ID与映像档内容所形成的1对1对应关系，如果有心人士只有伪造映像档ID或映像档其中之一，都无法成功。他解释，对于单一映像档，虽然可以同时伪造ID以及映像档内容。但是映像档间所形成的父子关系（parent），将会导致原有的子映像档记录的ID失效，因此仍然不可使用完整的映像档，除非有心人士将某映像档以及其所有子孙映像档档全部进行伪造，但是这样所付出的成本非常高。

针对有升级需求的用户，Docker也提供了前置作业的指南。Docker表示，如果要让现有映像档能符合新的运作方式，必须将现有映像档的命名方式从UUID，改为由内容产生ID编号。而这也意味使用者必须计算目前档案的安全总和检查码（secure checksum）。

Arnaud Porterie表示，Docker daemon首先会计算使用者目前档案的安全总和码，在开启Docker daemon后，现有的映像档、标签以及Containers也会完成迁移，而所有的映像档及标签也都会配有新的安全ID。孙宏亮则认为，Docker使用者迟早必须导入这一步措施，而“长痛不如短痛。”他表示，由于新版本并不会改变映像档内容，因此转换过程可以透过离线作业完成，而开发人员也可以使用Docker 1.10来制新的映像档。

不过孙宏亮也表示，新版本也会对于既有的维运团队、开发团队带来冲击。比如，旧映像档与转换后的新映像档的标签、储存库很有可能一致，进而产生了冲突问题，使用者也必须事先需要规划相对应的转换策略。同时他也认为，线上环境映像档的更新会是一个值得关注的议题。尽管Docker Engine会为使用者带来阵痛期，“但是不可否认，映像档的大改，我认为是一个划时代的功能，我个人非常喜欢。”孙宏亮表示。