Language Stacks in Docker Hub

Nick Coghlan ncoghlan at redhat.com
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
pre-Koji.

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:
https://openshift.github.io/documentation/openshift-pep-010-docker-cartridges.html

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.

Regards,
Nick.

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

HSS Provisioning Architect


More information about the env-and-stacks mailing list