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