[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] docs-first RFE for stripping containers
- From: Adam Miller <maxamillion fedoraproject org>
- To: "atomic-devel projectatomic io" <atomic-devel projectatomic io>
- Subject: Re: [atomic-devel] docs-first RFE for stripping containers
- Date: Thu, 5 Feb 2015 13:57:10 -0600
On Thu, Feb 5, 2015 at 1:35 PM, Jim Perrin <jperrin centos org> wrote:
> Keeping a container small is often important, and a number of
> sub-projects have spun up around keeping the size of a container down.
>
> Would there be value in having a utility that can 'strip' a container of
> unused file and rpm data in order to keep the size down? My basic
> thinking is that once a container is built, there are a large number of
> files in the container that simply take up space. Examples: glibc locale
> files[1], timezone data, cracklib (brought in by pam for new user
> passwords), and others.
>
> The idea for the workflow would be that once a dev has a functional
> container they're happy with, they can (optionally) strip it to help
> keep the size down. Gross correlation here would be stripping a binary
> of debug info.
>
> The resulting container would have no concept of rpms or dependency
> tracking, but would be significantly smaller in size.
>
>
> I'm unsure if this would fit into something like what vbatts is working
> on with docker-utils, or would be something else.
>
>
> I may not have phrased this overly well in my post-fosdem stupor, but
> the basic idea should be intact. Thoughts, comments?
>
>
First and foremost, I love the idea. We spoke about some of this on
IRC but I want to echo my thoughts here to share with the group and
for the sake of posterity.
One thing I would like to add is that at the start of the 'docker
image stripping process' (for lack of a better term), I think it would
be a good idea to generate and store in some way a rpm manifest as
metadata for the docker image so that we can easily reference what
components were used in order to create the original pre-stripped
image. This would hopefully provide a way to replicate/duplicate the
container image if needed on specific versions of rpms and for
tracking things like bugs, errata, $other.
>From there I think using vbatts' docker-utils[0] dockertarsum would be
a great solution for verifying the image in order to establish a chain
of trust for the stripped image if/when it were to be distributed
since we'd lose the option of 'rpm -V' and verifying rpm signing (the
goal as proposed on IRC was to remove rpm entirely from the stripped
container which saves roughly 12MB of space from the rpm database
alone). You did mention docker-utils which I agree with but thought
I'd expand on a little. I think the image stripping tool could either
be an extension to that toolkit or something that would just use or
reference dockertarsum for the specific use case of verifying the
container.
I'm kind of struggling with a way to determine what would 1) need to
be removed/stripped and 2) what would be safe to remove/strip in a
pragmatic way. There' s a lot of data stored in the rpm database that
I think could be used to determine specifically what files are really
necessary but I haven't investigated it enough to really have a solid
idea but that basically would ignore the use case where someone added
something to the image that's not in an rpm.
Lots to figure out, maybe others have ideas but I think it could be a
really cool utility/feature/workflow.
-AdamM
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=156477
>
>
>
>
> --
> Jim Perrin
> The CentOS Project | http://www.centos.org
> twitter: @BitIntegrity | GPG Key: FA09AD77
>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]