Hi, 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