[CentOS-devel] CentOS Docker images

Chris St. Pierre chris.a.st.pierre at gmail.com
Tue Mar 18 11:27:35 UTC 2014


On Tue, Mar 18, 2014 at 5:03 AM, Karanbir Singh <mail-lists at karan.org>wrote:
>
> 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.
>

I'm sold.  It sounds like we'd need the build process to have three
components:

* A kickstart;
* A post-processing script that packages the image up (into either an AMI
or a Docker image or whatever else comes along); and, of course
* The harness that ties it all together.

If you can point me to the code that's used to create HVM AMIs, I can start
poking at this.


> 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.


You're not missing anything -- they can't be used for base images, and
they're not very trusted, either.  I just mentioned them to definitively
rule them out.


> 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.
>

Any reason we can't just host it entirely on github and use webhooks to
trigger the builds at git.centos.org?


> 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.
>

What has been painful about them?  If they're not always stable for the end
user, we could consider tagging them with "nightly" and leaving a stable
build (e.g., stock 6.5) as "latest", so that people have to specifically
ask for the fully-updated image.

E.g., 'docker run ... centos/centos6' runs CentOS 6.5, or whatever the most
recent "stable build" is.  'docker run ... centos/centos6:nightly' runs a
fully-updated image.

BTW, I did snag the 'centos' username on the Docker index; I'll contact you
or Jim on IRC today to transfer it to you guys.

> Also, at this point we should target the easiest wins and ship a base OS
> image, but keep in mind that shipping app containers might be an
> interesting option as well in the future ( gluster cluster as an example
? )

Yes!  If we're willing to make this a separate process, this would be super
easy with Dockerfiles.  We could even use Trusted Builds for this, based on
our own images, and not have to use CentOS' own resources. :)

-- 
Chris St. Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.centos.org/pipermail/centos-devel/attachments/20140318/85d673d8/attachment.html 


More information about the CentOS-devel mailing list