veyepar: OCIv2: Container Images Considered Harmful

Author(s):	Aleksa Sarai
Location	Room 7
Date	jan Tue 14	Days Raw Files
Start	13:30	First Raw Start	error-in-template
Duration	0:50:0	Offset	None
End	14:20	Last Raw End
Chapters
Total cuts_time	None min.

https://lca2020.linux.org.au/schedule/presentation/125/
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf OCIv2_Container_Images_Considered_Harmful.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

Most modern container image formats use tar-based linear archives to represent root filesystems, which results in many issues when using modern container images. In this talk, we will demonstrate a solution to this problem that we plan to propose for standardisation within the Open Container Initiative (code-named "OCIv2 images").

This talk is specific to the Open Container Initiative's image specification, but the same techniques could be applied to other systems (though we'd obviously recommend using OCI).

In order to avoid the [numerous issues with tar archives](https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar) it is necessary to come up with a different format. In addition, layer representations result in needless wasted space for storage of files which are no longer relevant to running containers. Massive amounts of duplication are also rampant within OCI images because tar archives are completely opaque to OCI's content-addressable store.

Luckily the problem of representing a container root filesystem for distribution is very similar to existing problems within backup systems, and we can take advantage of prior art such as [restic](https://restic.net/) to show us how we can get significant space-savings and possibly efficiency savings.

However, we also must ensure that the runtime cost of using this new system is equivalent to existing container images. Container images are efficient at runtime because they map directly to how overlay filesystems represent change-sets as layers, but with some tricks it is possible for us to obtain most of the improvements we also gained in distribution with de-duplication.

Our proposed solution to all of these problems will be laid out, with opportunities for feedback and discussion.

Comment:

production notes