qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Huston <shus...@riverace.com>
Subject RE: Proposal to create Docker images for Qpid components.
Date Tue, 20 Jun 2017 20:14:35 GMT
I agree w/ Rob, Robbie... 2 brokers and dispatch. Clients don't make sense for docker images,
IMO.

-Steve

> -----Original Message-----
> From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> Sent: Tuesday, June 20, 2017 1:19 PM
> To: qpid <dev@qpid.apache.org>
> Subject: Re: Proposal to create Docker images for Qpid components.
> 
> On 20 June 2017 at 18:20, Robbie Gemmell <robbie.gemmell@gmail.com>
> wrote:
> 
> > I think it makes sense for qpid-broker-j, qpid-cpp broker, and
> > qpid-dispatch.
> >
> 
> +1 These are what I imagined would make sense
> 
> 
> >
> > I believe some folks might also like 'client' images, which is much
> > less obvious to me..though I can see that for those needing
> > compilation or with interdependencies on bits that do, perhaps it
> > could make them slightly easier to get started with. Packages would
> > also in many cases though.
> >
> >
> Yeah - I'm not totally sold on the need for Docker images here (though I'm
> not necessarily against)... packages make a lot of sense to me however.
> 
> -- Rob
> 
> 
> > On 20 June 2017 at 14:17, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> > > So, stepping back for a second, which components do we think we
> > > should be releasing docker images for (and once we've agreed on this
> > > we can agree
> > on
> > > the number/form of images for each component perhaps :-) )?
> > >
> > > -- Rob
> > >
> > > On 20 June 2017 at 14:06, Robbie Gemmell <robbie.gemmell@gmail.com>
> > wrote:
> > >
> > >> It was talking about downloading the built Java broker binary
> > >> release tar.gz, verifying it, and doing something with it. It
> > >> wasn't saying anything in particular about the OS, except there is
> > >> one and Java is available somehow.
> > >>
> > >> For example, some randomly selected 'docker official' images I
> > >> looked at for Apache projects with Java components which all
> > >> happened to do this (I'm sure there are others that are different, of
> course):
> > >>
> > >> https://hub.docker.com/r/_/tomcat/
> > >> not-alpine: https://github.com/docker-library/tomcat/blob/
> > >> 5ac222d258dc70c77bb3a9a4fab81ea286c9abd1/8.5/jre8/Dockerfile
> > >> alpine: https://github.com/docker-library/tomcat/blob/
> > >> 5ac222d258dc70c77bb3a9a4fab81ea286c9abd1/8.5/jre8-
> alpine/Dockerfile
> > >>
> > >> https://hub.docker.com/_/maven/
> > >> not-alpine: https://github.com/carlossg/docker-maven/blob/
> > >> 0490eff01e529b2d94789511b008d01a7b314953/jdk-8/Dockerfile
> > >> alpine: https://github.com/carlossg/docker-maven/blob/
> > >> 2357d3394f19730172ac9c7f4afe7cf052f36b4d/jdk-8/Dockerfile
> > >>
> > >> https://hub.docker.com/_/zookeeper/
> > >> alpine: https://github.com/31z4/zookeeper-docker/blob/
> > >> f12428ab7c6ea263ef037cf258129b83276c009c/3.4.10/Dockerfile
> > >>
> > >> At another try I got one thats doing something different:
> > >>
> > >> https://hub.docker.com/_/cassandra/
> > >> https://github.com/docker-library/cassandra/blob/
> > >> d83b850cd17bc9198876f8686197c730e29c7448/3.10/Dockerfile
> > >>
> > >> Here they seem to be using their own .deb files via
> > >> http://www.apache.org/dist/cassandra/debian which actually
> > >> redirects to http://dl.bintray.com/apache/cassandra/, a debian repo
> > >> (https://bintray.com/apache/cassandra/debian) set up within the ASF
> > >> org on bintray (https://bintray.com/apache)
> > >>
> > >> Robbie
> > >>
> > >> On 20 June 2017 at 11:05, Fraser Adams
> > >> <fraser.adams@blueyonder.co.uk>
> > >> wrote:
> > >> > Re: "it doesnt seem unusual to have a Dockerfile set up to pull
> > >> > the
> > >> existing
> > >> > binary release archive, verify its sigs, and extract+configure it
> > >> > in
> > an
> > >> > appropriate location."
> > >> >
> > >> > Yes, it's certainly not unusual, but my personal view is that it
> > >> > isn't
> > >> great
> > >> > practice.
> > >> >
> > >> > As I said in my earlier reply to Irina, IMHO there are far too
> > >> > many instances of really bloaty Docker images containing far more
> > >> > than they
> > >> need,
> > >> > as well as unnecessarily making images larger than they need to
> > >> > be
> > (which
> > >> > isn't great if you are doing Continuous Deployment on a large
> > >> > system)
> > it
> > >> > also unnecessarily increases the attack surface. Now OK Qpid
> > >> > brokers
> > are
> > >> > probably long-lived services, so the first point might about
> > minimising
> > >> size
> > >> > may apply less to them than say 12 Factor App business function
> > services,
> > >> > but as a general principle I tend to think that not enough
> > >> > thought is
> > >> given
> > >> > to the footprint of Docker images.
> > >> >
> > >> > I may have misunderstood, If the sentence I've quoted is
> > >> > referring to
> > a
> > >> > Dockerfile for a *build system*, which subsequently exports a zip
> > >> containing
> > >> > only that necessary to build (using a separate Dockerfile) a
> > >> > small, versioned microcontainer based on a minimal distro like
> > >> > Alpine (or
> > from
> > >> > scratch) then that's fine, but having an image intended for use
> > >> > on a production system doing that sort of thing doesn't seem
> > >> > appropriate to
> > >> me.
> > >> >
> > >> > F.
> > >> >
> > >> >
> > >> >
> > >> > On 20/06/17 08:54, Lorenz Quack wrote:
> > >> >>
> > >> >> On Mon, 2017-06-19 at 13:16 +0100, Robbie Gemmell wrote:
> > >> >>>
> > >> >>> - To the comments around the Java broker, I don't think
> > >> >>> creating packages for it is really necessary? From a quick
look
> > >> >>> at some
> > others
> > >> >>> images it doesnt seem unusual to have a Dockerfile set up
to
> > >> >>> pull
> > the
> > >> >>> existing binary release archive, verify its sigs, and
> > >> >>> extract+configure it in an appropriate location.
> > >> >>>
> > >> >> Great. That would work for me.
> > >> >> I just thought it would be good to have the entire Qpid project
> > >> >> represented and to provide some choice at the same time.
> > >> >>
> > >> >> Kind regards,
> > >> >> Lorenz
> > >> >>
> > >> >>> Robbie
> > >> >>>
> > >> >>> On 13 June 2017 at 15:13, Irina Boverman <iboverma@redhat.com>
> > wrote:
> > >> >>>>
> > >> >>>> Hi everyone,
> > >> >>>>
> > >> >>>> I would like to propose creating Docker images for Qpid
> > >> >>>> components hosted in Docker Hub, updated upon component
> > >> >>>> release and maintained by the project, and I would like
to
> > >> >>>> contribute to doing this.
> > >> >>>>
> > >> >>>> Availability of Qpid images will make it easier to
> > >> >>>> consume/deploy
> > Qpid
> > >> >>>> components and promote Qpid visibility.
> > >> >>>>
> > >> >>>> We can maintain docker scripts creating these images from
the
> > >> >>>> base
> > OS
> > >> >>>> images and using Qpid installation methods consistent
with the
> > >> >>>> OS distribution. A possible naming convention might be
> > >> >>>> qpid/<component>/<OS>.
> > >> >>>> I registered the 'qpid' user on DockerHub to use if this
seems
> > >> >>>> reasonable.
> > >> >>>> For example, we could create qpid/dispatch/<OS>
image,
> > >> >>>> qpid/<broker>/<OS> image, qpid/<client(s)>/<OS>
image, etc.
> > >> >>>> Initially I would look to support Fedora/CentOS latest
images
> > >> >>>> and Qpid components as RPMs for them,
> > then
> > >> >>>> aim
> > >> >>>> to expand OS coverage for debian/Ubuntu/etc in the future.
> > >> >>>>
> > >> >>>> The goal would be to update Qpid images within a few days
upon
> > >> component
> > >> >>>> release (either directly or indirectly using yum/dnf from
> > >> >>>> public repositories). We could ask the Docker team to
grant
> > >> >>>> Qpid
> > "official"
> > >> >>>> status
> > >> >>>> when images have been stabilized.
> > >> >>>> --
> > >> >>>> Regards, Irina.
> > >> >>>
> > >> >>> ------------------------------------------------------------
> > ---------
> > >> >>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org For
> > >> >>> additional commands, e-mail: dev-help@qpid.apache.org
> > >> >>>
> > >> >> ------------------------------------------------------------
> > ---------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org For
> > >> >> additional commands, e-mail: dev-help@qpid.apache.org
> > >> >>
> > >> >
> > >> >
> > >> > -----------------------------------------------------------------
> > >> > ---- To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org For
> > >> > additional commands, e-mail: dev-help@qpid.apache.org
> > >> >
> > >>
> > >> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org For
> > >> additional commands, e-mail: dev-help@qpid.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org For additional
> > commands, e-mail: dev-help@qpid.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Mime
View raw message