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]
