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:[email protected]] > Sent: Tuesday, June 20, 2017 1:19 PM > To: qpid <[email protected]> > Subject: Re: Proposal to create Docker images for Qpid components. > > On 20 June 2017 at 18:20, Robbie Gemmell <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > 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 > > >> <[email protected]> > > >> 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 <[email protected]> > > 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: [email protected] For > > >> >>> additional commands, e-mail: [email protected] > > >> >>> > > >> >> ------------------------------------------------------------ > > --------- > > >> >> To unsubscribe, e-mail: [email protected] For > > >> >> additional commands, e-mail: [email protected] > > >> >> > > >> > > > >> > > > >> > ----------------------------------------------------------------- > > >> > ---- To unsubscribe, e-mail: [email protected] For > > >> > additional commands, e-mail: [email protected] > > >> > > > >> > > >> ------------------------------------------------------------------- > > >> -- To unsubscribe, e-mail: [email protected] For > > >> additional commands, e-mail: [email protected] > > >> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] For additional > > commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
