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會為使用者帶來陣痛期,「但是不可否認,映像檔的大改,我認為是一個劃時代的功能,我個人非常喜歡。」孫宏亮表示。


Advertisement

更多 iThome相關內容