[CentOS-devel] CentOS Docker images

Tue Mar 18 09:03:55 UTC 2014
Karanbir Singh <mail-lists at karan.org>


On 03/16/2014 07:30 PM, Chris St. Pierre wrote:
> I've volunteered to help maintain official CentOS Docker
> (https://www.docker.io/) images, and Karanbir suggested I email the list
> to "thrash out what we need at the infra end to achieve these images."
> Currently, there are 'centos' images available in the top-level Docker
> registry namespace, but these are maintained by dotcloud.  I think we
> can do better. :)
> As I see it, there are two ways we can do this:
> 1.  Use ami-creator (https://github.com/katzj/ami-creator), or something
> derived from it, to build Docker images from a kickstart file.  This is
> how CentOS AMIs are currently built.
> Pros: Consistent with how AMIs are usually built; Kickstart is a known
> entity.
> Cons: ami-creator won't actually work for us as-is; requires a full
> kickstart config.

ami_creator is still used for the pv images, but for the hvm images its
now done as a native kvm image, then migrated. I think having a
kickstart that people can contribute into isnt a bad idea, and as you
mentioned - lots of people already familiar with it

> 2.  Use the mkimage-yum.sh script from Docker
> (https://github.com/dotcloud/docker/blob/master/contrib/mkimage-yum.sh),
> customized as necessary to produce a minimal base image.
> Pros: Consistent with how Docker images are usually built; we can
> contribute changes to mkimage-yum.sh upstream to help other Yum-based
> distros; only requires a yum config.
> Cons: Requires changing a shell script to make changes to the base
> image, not just a Kickstart.

how about just using anaconda to drive the install ( so running the
build like a native kvm image, then trimming). The yum installroot for
@core is going to bring in a kernel etc as well, and we could
--excludedocs and set installlang etc at the anaconda level. It also
means, and I quite like, the idea that a single build process could be
used for other things as well.

> Unfortunately, Docker Trusted Build
> (http://blog.docker.io/2013/11/introducing-trusted-builds/) can't be
> used for base images, AFAICT.

afaik, trusted-builds are a CI component of app containers and might not
be very relevant to the platform generic containers we might end up
doing initially ? or am I missing something else here. Are they trying
to setup trusted builds as a 'validated/verified good build with a
trackable upstream' ? commit access to a github repo might not be much
of in terms of traceability.

> In either case, we'll need a git repo to hold the code and configs used
> to build the images.  If we follow the example of the official CentOS
> AMIs (http://wiki.centos.org/Cloud/AWS), it should be sufficient to
> provide a reasonably up-to-date base image ("latest" or "nightly" or
> similar), and a few recent dot releases.  Of course, once CentOS 7 is
> released we'll need to do that for both 6 and 7, but that shouldn't be
> difficult if we do this right.

We can work with or setup a new git repo for the docker configs,
metadata etc and I would say we use the same workflow that has been
proposed for the other cloud-instance sig stuff : ie. mirror on github
for easier import, and manually bridge to git.centos.org, with triggers
to build instance at git.centos.org.

If we can get to the AWS pages in the wiki, that would be good - and
easy to get to, just needs someone to work on it a bit. So thanks for
raising the hand :)

In terms of versions, we should do CentOS-5 as well. And we should
perhaps, if we can get away with it, drop the updated-in-time images and
stick to just the release content in CentOS-5/6 and then 7. The
updated-in-time VM's have been a train wreck at AWS, and for 6.5 I didnt
do it at all.

- KB
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc