Language Stacks in Docker Hub

Nick Coghlan ncoghlan at
Tue Sep 30 02:45:52 UTC 2014

On 09/30/2014 01:28 AM, Marcela Mašláňová wrote:
> Cool, we should do it better. From what I see every image contains just
> the main package downloaded from upstream. If those users are using
> cpan/pypi/npm, there's not much added value.
> I wouldn't say they are outdated at all. They are missing just released
> node.js 0.12 and quite fresh Ruby 2.2 (from interpreted languages).
> Do you have vision what should be done? (Like package in dockerfile at
> least what we provide for RSHCL). Otherwise, we could create dockerfile
> for every existing framework, but we probably don't want to go this way
> and support all existing combinations. Too much maintenance.
> It might be good to use combinations, which we are providing in
> DevAssistant or pick one supported frameworks for every language, but
> someone has to pick the One...

I think this combinatorial explosion problem is why offering a lot of
prebuilt images is the wrong way to go with this. The desire to do so is
a reflection of the fact that the tooling for building and managing
Docker images is still relatively immature - I don't know exactly when
Koji was written, but I'd suggest that the current state of Docker image
management is, at best, where the RPM build process would have been

Instead of offering a wide array of prebuilt images, I think OpenShift
Origin are going in the right direction with v3, taking full advantage
of the notion of composable layers in the design of Docker:

I don't think that's something we want to reinvent independently at the
Fedora layer - instead, I'd encourage folks interested in the concept of
a "Docker build service" to get involved with OpenShift Origin v3, and
ensure that it's at least possible to get the built images *out* for
direct deployment with Docker, rather than *only* allow them to be
deployed into the OpenShift instance. Ideally, the image build service
and image registry components would be independently deployable, without
a full OpenShift instance around them. Either way though, the OpenShift
Origin project has a relatively high concentration of Docker expertise
at this point, and also a pressing need for an image build service as
part of the v3 redesign, so it's likely a good direction to explore.


Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

HSS Provisioning Architect

More information about the env-and-stacks mailing list