[Rpm-ecosystem] Containerization using rpm

Jan Zelený jzeleny at redhat.com
Wed May 13 11:17:32 UTC 2015


On 13. 5. 2015 at 06:37:31, Neil Horman wrote:
> On Wed, May 13, 2015 at 09:22:01AM +0200, Tomáš Smetana wrote:
> > Dne Tue, 12 May 2015 11:27:52 -0400
> > 
> > Neil Horman <nhorman at tuxdriver.com> napsal(a):
> > > On Tue, May 12, 2015 at 03:10:12PM +0200, Jan Zelený wrote:
> > > > On 11. 5. 2015 at 15:09:50, Neil Horman wrote:
> > > > > Hey all-
> > > > > 
> > > > > 	I was recently made aware of this list, and though I would join,
> > > > > 
> > > > > due to a project I'm exploring currently.  I've been working on
> > > > > container strategies for a bit, and found that the predominant
> > > > > container
> > > > > technologies were re-inventing several wheels, and so I started
> > > > > this:
> > > > > 
> > > > > http://freightagent.github.io/freight-tools/
> > 
> > <...>
> > 
> > > So far the tool works quite well for local installations, using yum
> > > repositories to install and execute the test web server container I have
> > > using systemd-nspawn (which is the other tool that I'm reusing here).
> > > 
> > > My roadmap over the upcomming weeks is something as follows:
> > > 
> > > 1) clustered use - allowing a cluster of nodes to execute containers in
> > > response to a centeral administrator
> > > 
> > > 2) multi-tennancy - the ability for several tennants to share the same
> > > physical cluster of systems
> > > 
> > > 3) derivative containers - the ability to codify in the base manifest, a
> > > set of derivative containers that rely on the base container.  The idea
> > > being that the base container contains the base filesystem for the
> > > container, while the derivatie container contains overridden
> > > directories for the purpose of specifying configuration for the
> > > container.
> > > 
> > > 4) Networking - One of the things that I've taken away from kubernetes
> > > is
> > > that the SDN components are somewhat difficult to work with in a
> > > multi-tennant environment.  I'd like to integrate networking features
> > > into
> > > freight directly to better co-ordinate overlay networks to sets of
> > > containers
> > 
> > <...>
> > 
> > Hello,
> > 
> >   I'm not sure how much would you be interested and wouldn't want to
> >   hijack
> > 
> > the thread...  I got a similar/complementary idea: maintaining the content
> > of the container with the host dnf/rpm.  I have something like a
> > proof-of-concept (and not finished yet):
> > 
> > https://github.com/tsmetana/cpm/blob/master/cpm
> > 
> > The main goal of the script is the "checkinstall" part (perhaps a
> > misleading name -- it should evoke what it really does though): It
> > basically scans the content of the container (installroot) for any
> > differences to the container's internal RPMDB and creates an binary-only
> > package containing any un-owned files.  What's still missing is the part
> > that would find out the leaf packages and make them dependencies of the
> > newly created package. Such a package would then become "the app".
> > Installing it using the script should also re-build the container.
> > 
> > The resulting package would of course be an ugly pile of unsorted stuff
> > (much like any Android APK or whatever JAR...), unsuitable for anything
> > else than this isolated environment.  However, good enough when "time to
> > market" is the main concern.
> > 
> > Apparently seeing the containers upstreams re-inventing much of what is
> > solved in packaging tools already lead many people to similar idea of
> > rather extending the existing tools than to create the same thing from
> > scratch again...
> > 
> > Regards,
> 
> I'm not sure I fully have my head wrapped around what you're explaining
> here, but I think I get part of it, and I like the idea.  If I'm reading
> the above correctly, I think what you're addressing is a method of
> container customization.  You're idea is something along the lines of:
> 
> 1) Do a yum --installroot=/path/to/container <rpmset>
> 2) Customize some files within the container image created in (1)
> 3) Run your script to scan your container image which identifies the files
> that you've changed, creating a new rpm out of those customized files, and
> setting the Requires: tag in the new rpm such that it depends on the
> packages that were needed to create the origional container file system in
> (1)
> 
> Do I have that right?

I can see more ways how to use it but I absolutely love the idea to combine 
both approaches in a way you proposed.

> If so, I think thats really slick. Its adventageous because the container
> rpm is just the customization bits (which means its small), and all the
> dependent support rpms get installed as dependencies.
> 
> May I add such a feature to my roadmap?
> Neil

As a potential user, I say yes :-) This combination sounds really very 
interesting.

Thanks
Jan


More information about the Rpm-ecosystem mailing list