Thank you for excellent remarks. I will take a look at your work and what can be done to minimise images, although I must admit it is easier to layer on top of official images produced by the distros.
On Tue, Jun 13, 2017 at 11:36 AM, Fraser Adams < [email protected]> wrote: > 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. >> >> >
