I think it makes sense for qpid-broker-j, qpid-cpp broker, and qpid-dispatch.
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. 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]
