@@ -104,6 +104,86 @@ <h1 class="site-title">
104104
105105 < section id ="main ">
106106
107+ < article id ="post-加固容器映像 " class ="article article-type-post " itemscope itemprop ="blogPost " >
108+ < div id ="articleInner " class ="clearfix post-1016 post type-post status-publish format-standard has-post-thumbnail hentry category-template-2 category-uncategorized tag-codex tag-edge-case tag-featured-image tag-image tag-template ">
109+
110+
111+ < header class ="article-header ">
112+
113+
114+ < h1 class ="thumb " itemprop ="name ">
115+ < a class ="article-title " href ="/2017/05/25/加固容器映像/ "> 加固容器映像</ a >
116+ </ h1 >
117+
118+
119+ </ header >
120+
121+ < div class ="article-meta ">
122+
123+ Posted on < a href ="/2017/05/25/加固容器映像/ " class ="article-date ">
124+ < time datetime ="2017-05-24T16:00:00.000Z " itemprop ="datePublished "> May 25, 2017</ time >
125+ </ a >
126+
127+
128+ </ div >
129+ < div class ="article-entry " itemprop ="articleBody ">
130+
131+ < p > 容器在这个云计算时代变得愈发重要,越来越多的客户对容器产生了兴趣,甚至已经开始使用容器
132+ 来分发、部署和运行应用程序。</ p >
133+ < p > 容器的一个关键优势是其分层映像系统,它利用了aufs、btrfs、overlayfs、zfs、lvm以及
134+ device mapper等存储技术的先进特性。下图是从docker官方网站摘录出来的,它展示了docker
135+ 对于各种不同的工作负载提供了许多存储driver选项。然而遗憾的是,它们当中只有lvm这一个选择
136+ 同时满足production-ready和进入Linux内核这两项标准。事实上,lvm是官方唯一建议用于
137+ RHEL/CentOS生产环境的存储driver。RHEL/CentOS系列操作系统是生产服务器中最为广泛
138+ 使用的Linux发行版,尤其是在大型企业里。</ p >
139+ < p > < img src ="/images/driver-pros-cons.png " alt ="Storage Drivers "> </ p >
140+ < p > LVM是一种块存储技术,然而docker的分层映像系统是基于文件系统技术设计的,所以他们之间
141+ 存在一道语义鸿沟:映像中的每一层都是由被修改的文件以及文件元数据组成,而LVM中的每一层
142+ (快照)是由被修改的数据块组成。为了抹平这一鸿沟,lvm存储驱动需要遍历并对比相邻层次中
143+ 的所有文件,并判断每个文件是否修改或新增。这一过程由docker中的< code > NaiveDiffDriver</ code > 类完成。</ p >
144+ < p > 除此之外,这一设计选择还有一些其他的基础性问题:</ p >
145+ < ol >
146+ < li > 文件系统层的功能特性通常实现起来都非常复杂,这就是为什么时至今日所有文件系统层的
147+ driver都还不适用于生产环境;</ li >
148+ < li > 一些文件系统层面的高级功能无法在现有设计里得到支持,例如扩展属性xattr,因此SELinux
149+ 也无法使用;</ li >
150+ < li > 应用无法自主选择文件系统类型,即便某种特定的文件系统能使应用显著受益;</ li >
151+ < li > 当映像层数增加,文件系统的元数据访问会越来越慢;</ li >
152+ < li > 对任何大文件的第一次修改都会有很长的延迟,用来做文件的写时复制(Copy-on-Write),
153+ 这将导致I/O性能的显著波动。</ li >
154+ </ ol >
155+ < p > 为了解决这些问题,我们提议一种新型的映像系统,基于块存储来设计,可以支持任何类型的文件系统,
156+ 以及文件系统的完整功能集合,也可以保障持续、稳定的I/O性能。这一设计基于久经考验的LVM,同时
157+ 我们也设计了一个新的工具< code > lvdiffer</ code > ,来创建或应用块层次的patch/diff文件。</ p >
158+ < p > 设计的patch文件具有简单且可序列化的格式,如下所示:</ p >
159+ < figure class ="highlight plain "> < table > < tr > < td class ="code "> < pre > < div class ="line "> HYPERLAYER/1.0</ div > < div class ="line "> <key>: <value></ div > < div class ="line "> <key>: <value></ div > < div class ="line "> <key>: <value></ div > < div class ="line "> <key>: <value></ div > < div class ="line "> </ div > < div class ="line "> <offset> <length></ div > < div class ="line "> <data of $length*512 bytes></ div > < div class ="line "> <offset> <length></ div > < div class ="line "> <data of $length*512 bytes></ div > < div class ="line "> <offset> <length></ div > < div class ="line "> <data of $length*512 bytes></ div > < div class ="line "> ...</ div > </ pre > </ td > </ tr > </ table > </ figure >
160+ < p > 其中:</ p >
161+ < ol >
162+ < li > key和value是该patch文件的属性,由大小写字母、数字和下划线组成,并且首字符不能是数字;</ li >
163+ < li > offset和length是16进制数字,没有’0x’前缀,以sector为单位(512字节);</ li >
164+ < li > offset不需要依照某种特定顺序排列;</ li >
165+ < li > 换行符是单个’\n’,没有’\r’;</ li >
166+ </ ol >
167+ < p > 例如:</ p >
168+ < figure class ="highlight plain "> < table > < tr > < td class ="code "> < pre > < div class ="line "> HYPERLAYER/1.0</ div > < div class ="line "> Parent: 68044d4a72dfcf15018cfa6b4baf89361913d93d</ div > < div class ="line "> Author: Huiba Li <lihuiba@gmail.com></ div > < div class ="line "> Date: Thu May 4 15:34:37 2017 +0800 </ div > < div class ="line "> </ div > < div class ="line "> 0 8</ div > < div class ="line "> <data of 4096 bytes></ div > < div class ="line "> 800 80</ div > < div class ="line "> <data of 65536 bytes></ div > < div class ="line "> ...</ div > </ pre > </ td > </ tr > </ table > </ figure >
169+ < p > 这种格式叫做< em > HyperLayer</ em > ,它被设计为一种通用的块存储系统diff/patch格式,可用于(但不限于)
170+ LVM和QCoW2。基于这种patch文件,我们可以实现跟docker类似的基于块存储的映像系统。</ p >
171+
172+
173+ </ div >
174+ < footer class ="entry-meta entry-footer ">
175+
176+
177+
178+ </ footer >
179+ </ div >
180+
181+ </ article >
182+
183+ <!-- Table of Contents -->
184+
185+
186+
107187 < article id ="post-towards " class ="article article-type-post " itemscope itemprop ="blogPost " >
108188 < div id ="articleInner " class ="clearfix post-1016 post type-post status-publish format-standard has-post-thumbnail hentry category-template-2 category-uncategorized tag-codex tag-edge-case tag-featured-image tag-image tag-template ">
109189
@@ -190,86 +270,6 @@ <h1 class="thumb" itemprop="name">
190270
191271
192272
193- </ footer >
194- </ div >
195-
196- </ article >
197-
198- <!-- Table of Contents -->
199-
200-
201-
202- < article id ="post-加固容器映像 " class ="article article-type-post " itemscope itemprop ="blogPost " >
203- < div id ="articleInner " class ="clearfix post-1016 post type-post status-publish format-standard has-post-thumbnail hentry category-template-2 category-uncategorized tag-codex tag-edge-case tag-featured-image tag-image tag-template ">
204-
205-
206- < header class ="article-header ">
207-
208-
209- < h1 class ="thumb " itemprop ="name ">
210- < a class ="article-title " href ="/2017/05/25/加固容器映像/ "> 加固容器映像</ a >
211- </ h1 >
212-
213-
214- </ header >
215-
216- < div class ="article-meta ">
217-
218- Posted on < a href ="/2017/05/25/加固容器映像/ " class ="article-date ">
219- < time datetime ="2017-05-24T16:00:00.000Z " itemprop ="datePublished "> May 25, 2017</ time >
220- </ a >
221-
222-
223- </ div >
224- < div class ="article-entry " itemprop ="articleBody ">
225-
226- < p > 容器在这个云计算时代变得愈发重要,越来越多的客户对容器产生了兴趣,甚至已经开始使用容器
227- 来分发、部署和运行应用程序。</ p >
228- < p > 容器的一个关键优势是其分层映像系统,它利用了aufs、btrfs、overlayfs、zfs、lvm以及
229- device mapper等存储技术的先进特性。下图是从docker官方网站摘录出来的,它展示了docker
230- 对于各种不同的工作负载提供了许多存储driver选项。然而遗憾的是,它们当中只有lvm这一个选择
231- 同时满足production-ready和进入Linux内核这两项标准。事实上,lvm是官方唯一建议用于
232- RHEL/CentOS生产环境的存储driver。RHEL/CentOS系列操作系统是生产服务器中最为广泛
233- 使用的Linux发行版,尤其是在大型企业里。</ p >
234- < p > < img src ="/images/driver-pros-cons.png " alt ="Storage Drivers "> </ p >
235- < p > LVM是一种块存储技术,然而docker的分层映像系统是基于文件系统技术设计的,所以他们之间
236- 存在一道语义鸿沟:映像中的每一层都是由被修改的文件以及文件元数据组成,而LVM中的每一层
237- (快照)是由被修改的数据块组成。为了抹平这一鸿沟,lvm存储驱动需要遍历并对比相邻层次中
238- 的所有文件,并判断每个文件是否修改或新增。这一过程由docker中的< code > NaiveDiffDriver</ code > 类完成。</ p >
239- < p > 除此之外,这一设计选择还有一些其他的基础性问题:</ p >
240- < ol >
241- < li > 文件系统层的功能特性通常实现起来都非常复杂,这就是为什么时至今日所有文件系统层的
242- driver都还不适用于生产环境;</ li >
243- < li > 一些文件系统层面的高级功能无法在现有设计里得到支持,例如扩展属性xattr,因此SELinux
244- 也无法使用;</ li >
245- < li > 应用无法自主选择文件系统类型,即便某种特定的文件系统能使应用显著受益;</ li >
246- < li > 当映像层数增加,文件系统的元数据访问会越来越慢;</ li >
247- < li > 对任何大文件的第一次修改都会有很长的延迟,用来做文件的写时复制(Copy-on-Write),
248- 这将导致I/O性能的显著波动。</ li >
249- </ ol >
250- < p > 为了解决这些问题,我们提议一种新型的映像系统,基于块存储来设计,可以支持任何类型的文件系统,
251- 以及文件系统的完整功能集合,也可以保障持续、稳定的I/O性能。这一设计基于久经考验的LVM,同时
252- 我们也设计了一个新的工具< code > lvdiffer</ code > ,来创建或应用块层次的patch/diff文件。</ p >
253- < p > 设计的patch文件具有简单且可序列化的格式,如下所示:</ p >
254- < figure class ="highlight plain "> < table > < tr > < td class ="code "> < pre > < div class ="line "> HYPERLAYER/1.0</ div > < div class ="line "> <key>: <value></ div > < div class ="line "> <key>: <value></ div > < div class ="line "> <key>: <value></ div > < div class ="line "> <key>: <value></ div > < div class ="line "> </ div > < div class ="line "> <offset> <length></ div > < div class ="line "> <data of $length*512 bytes></ div > < div class ="line "> <offset> <length></ div > < div class ="line "> <data of $length*512 bytes></ div > < div class ="line "> <offset> <length></ div > < div class ="line "> <data of $length*512 bytes></ div > < div class ="line "> ...</ div > </ pre > </ td > </ tr > </ table > </ figure >
255- < p > 其中:</ p >
256- < ol >
257- < li > key和value是该patch文件的属性,由大小写字母、数字和下划线组成,并且首字符不能是数字;</ li >
258- < li > offset和length是16进制数字,没有’0x’前缀,以sector为单位(512字节);</ li >
259- < li > offset不需要依照某种特定顺序排列;</ li >
260- < li > 换行符是单个’\n’,没有’\r’;</ li >
261- </ ol >
262- < p > 例如:</ p >
263- < figure class ="highlight plain "> < table > < tr > < td class ="code "> < pre > < div class ="line "> HYPERLAYER/1.0</ div > < div class ="line "> Parent: 68044d4a72dfcf15018cfa6b4baf89361913d93d</ div > < div class ="line "> Author: Huiba Li <lihuiba@gmail.com></ div > < div class ="line "> Date: Thu May 4 15:34:37 2017 +0800 </ div > < div class ="line "> </ div > < div class ="line "> 0 8</ div > < div class ="line "> <data of 4096 bytes></ div > < div class ="line "> 800 80</ div > < div class ="line "> <data of 65536 bytes></ div > < div class ="line "> ...</ div > </ pre > </ td > </ tr > </ table > </ figure >
264- < p > 这种格式叫做< em > HyperLayer</ em > ,它被设计为一种通用的块存储系统diff/patch格式,可用于(但不限于)
265- LVM和QCoW2。基于这种patch文件,我们可以实现跟docker类似的基于块存储的映像系统。</ p >
266-
267-
268- </ div >
269- < footer class ="entry-meta entry-footer ">
270-
271-
272-
273273 </ footer >
274274 </ div >
275275
@@ -439,7 +439,7 @@ <h3 class="widget-title">Connect With Us</h3>
439439 < div class ="widget-entry-summary " style ="margin: 0; ">
440440
441441
442- < h6 style ="margin: 0; "> < a href ="/2017/05/25/towards / "> Torwards Hardened Container Images </ a > </ h6 >
442+ < h6 style ="margin: 0; "> < a href ="/2017/05/25/加固容器映像 / "> 加固容器映像 </ a > </ h6 >
443443 < span > May 25, 2017</ span >
444444 </ div >
445445
@@ -451,7 +451,7 @@ <h6 style="margin: 0;"><a href="/2017/05/25/towards/">Torwards Hardened Containe
451451 < div class ="widget-entry-summary " style ="margin: 0; ">
452452
453453
454- < h6 style ="margin: 0; "> < a href ="/2017/05/25/加固容器映像 / "> 加固容器映像 </ a > </ h6 >
454+ < h6 style ="margin: 0; "> < a href ="/2017/05/25/towards / "> Torwards Hardened Container Images </ a > </ h6 >
455455 < span > May 25, 2017</ span >
456456 </ div >
457457
0 commit comments