Language Stacks in Docker Hub
vpavlin at redhat.com
Tue Sep 30 07:16:33 UTC 2014
On 30.9.2014 04:45, 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.
Very good point and I am already talking to Openshift guys - they
actually are already able to build images in Openshift v3 and they are
working on traceability and reproducibility of builds and also on a way
how to provide reasonable metadata of layeres and their content to other
tools. So when it comes to build service, I'd definitely go with Openshift.
But what I see as a problem at the moment is that Fedora is not well
recognized in Docker land. Red Hat as well as Cent OS are, but I don't
see Fedora mentioned anywhere.
But I agree with Marcela that it wouldn't be easy at all to provide and
maintain layered images which are useful for developers.
Lead Infrastructure Engineer
Brno, Czech Republic
More information about the env-and-stacks