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]
