Definitely a good idea. I have my own images for C++ broker (https://hub.docker.com/r/ scholzj/qpid-cpp/) / Dispatch (https://hub.docker.com/r/ scholzj/qpid-dispatch/) / GUI for the C++ broker ( https://hub.docker.com/r/scholzj/qpid-cpp-gui/) and since I built them for the first time I probably never used anything else. So having something official and centrally maintained would be great.
What I'm curios about is what would you (and of course also others) expect in terms of how to configure the images - what env. variables should be supported etc. Getting it to the official docker library would be great. What I'm not sure about is whether we really need the different OS versions. What would be the benefit of maintaining them? Regards Jakub On Tue, Jun 13, 2017 at 4:13 PM, 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. >
