Proposal to create Docker images for Qpid components.

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal to create Docker images for Qpid components.

Irina Boverman
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Proposal to create Docker images for Qpid components.

Steve Huston
+1

I think it's a great idea to make Docker images available.

Not sure it makes sense to package client(s) as images, but overall I think the idea would help make Qpid more easily accessible to users and help ease deployment.

-Steve

> -----Original Message-----
> From: Irina Boverman [mailto:[hidden email]]
> Sent: Tuesday, June 13, 2017 10:13 AM
> To: qpid <[hidden email]>
> Subject: Proposal to create Docker images for Qpid components.
>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to create Docker images for Qpid components.

Fraser Adams
In reply to this post by Irina Boverman
Hi Irina,

I think that this is an excellent idea and I totally agree with the
sentiment "Availability of Qpid images will make it easier to
consume/deploy Qpid components and promote Qpid visibility." I think
that in 2017 it's really important for the project to be providing
official maintained images as otherwise we'll continue to see a
fragmented miscellany of images of unknown provenance growing up out of
necessity. To be fair that seems to be a general trend on Docker Hub for
many projects, but I personally tend to find it a bit frustrating and
would prefer a bit more control over provenance and versioning for
things used on production systems.

I'd make a few comments though.

1. It's probably better to propose this on the users list as that tends
to have more traffic than the dev list. If you choose to repost on the
users list feel free to include this response (if it's useful).

2. I do wonder about the comment "We can maintain docker scripts
creating these images from the base OS images and using Qpid
installation methods consistent with the OS distribution" and "I would
look to support Fedora/CentOS latest images" and "expand OS coverage for
debian/Ubuntu/etc".

I can see why this might be the /obvious/ approach, but IMHO I think
that it's a somewhat poor anti-pattern for containerisation that is
propagated way too often on Docker Hub and tends to result in large
bloaty images with larger potential attack surfaces than necessary and
in addition reinforces a model that containers are somehow "lightweight
VMs" rather than containerised appliances. I very much prefer a
micro-containerised approach using an approach similar to that descrived
here: http://blog.oddbit.com/2015/02/05/creating-minimal-docker-images/ 
though acknowledging that this approach adds some complexity to the
build process and requires a little care.

Ultimately reducing image size from the 400-500MB range to something
like 55MB for qpidd feels like a good thing for a number of reasons, the
following article contains some interesting musings on the subject
https://opensolitude.com/2015/05/13/docker-images-should-be-small.html.

It's a bit more complex for Python and Java based components, but I
think that basing components on lighter weight Alpine Linux based Java
or Python runtimes is probably the best way to go, I note that Docker
Hub is (slowly) moving towards Alpine and http://www.iron.io/ have built
some uber tiny Docker images for a wide range of languages see
https://github.com/iron-io/dockers and https://hub.docker.com/u/iron/

3. One question to ask is which Qpid versions would be supported by the
build system. Obviously one advantage of containerisation is the ability
to easily use multiple versions of an application in order to support
regression testing and potentially legacy capabilities in an operational
environment, but of course there is a price to be paid as older versions
run into difficulties with newer compilers, boost versions etc.


I had a bit of a go at creating a build system for qpidd, my intention
has been to do the same for other components, but I've been stuck for
time, see https://github.com/fadams/docker-qpid though the qpid-cpp link
is the only one with any useful content.

The approach that I took was to create a Dockerised build system based
on Debian so that the only dependency to actually build the component is
a working Docker install and an Internet connection, the build system
installs the necessary dev packages then installs the requested qpid-cpp
source, runs the Qpid build then it exports the relevant shared
libraries etc. and dynamic linker in order that a separate Dockerfile
can use these to create a small image containing only what is necessary
for qpidd to execute.

I created two alternative build systems, one based on Debian wheezy the
other based on jessie, the former was somewhat simpler as wheezy has
somewhat older gcc and boost packages so less "wrangling" was necessary
to build really old Qpid versions, with jessie I had to build gcc and
boost from source. If you only intent to build recent Qpid versions much
of that complexity is unnecessary as recent Qpid versions compile with
recent gcc and boost versions, but I'm a little bit of a glutton for
punishment and it seemed a bit more of a challenge to try and create
something that could build every qpidd version from 0.5 to trunk. I
suspect that the best approach might be to use jessie with the default
compiler for recent Qpids and only use wheezy for older ones to provide
legacy support.


I'm no bash expert so the build.sh used by the Dockerfiles is a little
bit monolithic and could do with something of a refactor into functions,
but hopefully what it's doing should be fairly clear.

Hope this is useful.

Best regards,

Frase


On 13/06/17 15:13, Irina Boverman 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.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to create Docker images for Qpid components.

Lorenz Quack
In reply to this post by Irina Boverman
Hello Irina,

Sounds like a good idea.

Do you plan on providing docker images of all Qpid components?
Would be good to have for example the cpp and the java broker available to
easily evaluate and compare them.

Kind regards,
Lorenz


On Tue, 2017-06-13 at 10:13 -0400, Irina Boverman 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to create Docker images for Qpid components.

Lorenz Quack
Hi Irina,

Is there anything we could do to help/make it easier to package the java broker?
Are there any obstacles that make it hard to package it?

Kind regards,
Lorenz 


On Tue, 2017-06-13 at 13:56 -0400, Irina Boverman wrote:

> As many as I can. Currently we do not package java broker as an RPM for
> Fedora/CentOS, nor do we have it packaged for Ubuntu.
>  
>
> On Tue, Jun 13, 2017 at 12:03 PM, Lorenz Quack <[hidden email]> wrote:
> > Hello Irina,
> >
> > Sounds like a good idea.
> >
> > Do you plan on providing docker images of all Qpid components?
> > Would be good to have for example the cpp and the java broker available to
> > easily evaluate and compare them.
> >
> > Kind regards,
> > Lorenz
> >
> >
> > On Tue, 2017-06-13 at 10:13 -0400, Irina Boverman 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to create Docker images for Qpid components.

Robbie Gemmell
Administrator
In reply to this post by Irina Boverman
I think docker images would be good to have.

Rather than reply to lots of little bits from various different mails,
I'm just going to gather some general comments/questions here based on
the previous mails.

- If I understand correctly Irina's proposal is essentially to create
create RPMs/DEBs (for certain components at least, might not be as
useful/necessary to others, see later) and then create docker images
using them (configure yum/dnf/apt repo, call install?). To Jakub's
point around doing things such as nightly RPMs, that could form part
of it however we still wouldn't especially promote them to end users,
much like the maven repo snapshots arent, as such interim builds are
only meant to be known to folks tracking/partipating in development as
we are only allowed to direct regular everyday users at project
releases.

- One thing I think worth some thought/discussion is versioning, e.g .
what would the docker tags offered be. It looks like some projects do
precise full-version tags to a specific 'major.minor.patch' release,
as well as more general 'minor version' and 'major version' tags
netting the latest release in a given stream. There might be some
related behaviour there to decide on, e.g if using the OS package
systems, would running an update result in moving to a newer component
release in the stream. For some of those tag formats it could, while
for others it should not.

- If we do start offering images based on packages, then those
packages and the related images essentially become 'convenience
binaries' for the release that get created+tested by the project as
part of the components release process. For bug fixes and
functionality updates to be usable in images, there will need to be
matching component releases to allow updating their packages and in
turn images. I think this points to the project doing more [patch]
releases for some of our components (i.e. ones we only do source
release archives for), which I think would also be a very good thing.

- Its true that having multiple base OS options would take
maintenance. Only having one option on the other hand probably
involves some decisions as to which (for a given component? Perhaps
they might not all be the same?). I think this also probably gets into
considering what people are looking for when they use a docker image.
In the case of a server such as a broker some people might just want
the port(s) listening and doing stuff to use/try-out a particular
server and dont care what OS etc is under it, while others might care
that that its on a particular OS variant (e.g one they use for all
their other bits), and others still might only care that its as small
an image as possible (somewhat combining the previous behaviours to an
extent).

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

Robbie

On 13 June 2017 at 15:13, Irina Boverman <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to create Docker images for Qpid components.

Rob Godfrey
On 20 June 2017 at 18:20, Robbie Gemmell <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> >> 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 <[hidden email]>
> 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: [hidden email]
> >> >>> For additional commands, e-mail: [hidden email]
> >> >>>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Proposal to create Docker images for Qpid components.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Loading...