Language Stacks in Docker Hub
mmaslano at redhat.com
Tue Sep 30 07:01:18 UTC 2014
On 09/30/2014 04:45 AM, Nick Coghlan wrote:
> 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.
That's very good point. But guys are using RHSCL inside of some
cartridges, so that might be tricky to do in Fedora ;-)
More information about the env-and-stacks