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] > >
