[Rpm-ecosystem] Containerization using rpm

Neil Horman nhorman at tuxdriver.com
Wed May 13 16:22:51 UTC 2015


On Wed, May 13, 2015 at 05:34:56PM +0200, Jan Zelený wrote:
> -- snip --
> > One of the ways that I was looking at handling modified/removed files was to
> > package changes at no less than directory granularity.  The idea would be
> > that, for every changed file, the contents of the directory would be moved
> > over to the customized rpm, and then, prior to executing an instance of the
> > customized rpm, the copied directory (containing the modified file(s) would
> > be bind mounted back to the origional location for that container instance. 
> > Its not as efficient as some solutions, but it fits in with the
> > systemd-nspawn execution model nicely.
> 
> How about files in dirs like /usr/lib64?
> 
You're right, some directories this is really a non-optimal solution, because
the directory and its subdirectories are huge.  My thought was that
'customization' of a container really was meant for modifying configuration
files (like in /etc).  If you wanted to add/modify files in places like /usr/bin
or /usr/lib64, then what you really need to do is package your custom
application in its own rpm and then include it in the input manifest.

Not sure thats going to have legs, but its my starting point from a developer
perspective.  I think its reasonable to ask users, for a containerization suite
that relies on yum and rpm to do its work, that you are expected to package your
applications as rpms prior to use.  I don't think thats an insurmountable
request, especially if it buys you proper versioning on that component.

Neil

> -- snip --
> 
> Thanks
> Jan
> 


More information about the Rpm-ecosystem mailing list