For review and comments: https://github.com/irinabov/docker-qpid-cpp-broker https://github.com/irinabov/docker-qpid-dispatch-router -- Regards, Irina.
On Thu, Dec 7, 2017 at 3:35 PM, Ken Giusti <[email protected]> wrote: > Hey! > > Just following up on this thread. What's the status? > > thanks, > > -K > > On Tue, Jul 11, 2017 at 11:27 AM, Robbie Gemmell > <[email protected]> wrote: > > On 29 June 2017 at 17:52, Irina Boverman <[email protected]> wrote: > >> Thank you all who thoughtfully responded to this proposal. This is a > >> summary as I understood it and my comments regarding these points. > >> > >> (1) Qpid community is in favour of creating and maintaining docker > images > >> for cpp/java brokers > >> and dispatch router. OS choice is less important, as long as the user > can > >> connect to the broker/router port. We only need to support one OS > choice. > >> > >> I think this is a good start. It covers a use case when someone wants to > >> test or deploy client apps against broker/router conveniently running > as a > >> docker service. > >> > >> I think there might be another use case for those users who want to > develop > >> client apps in a known environment with client libraries already > installed > >> for them to work with. I think the OS choice is important to these users > >> because they may have a preference/better knowledge of this particular > OS. > >> Please consider this use case. > >> > >> (2) Docker images should be of minimal size. > >> > >> As a concept, I fully agree with it. However, community support for > >> official images also makes sense to me. These images go through review > and > >> testing, as well as, get patches for CVEs. There is a whole > infrastructure > >> in place in Fedora to build docker images, etc following best practices > >> from OCI. > >> > >> Official images range in size between 120 to 200 mb, and have 10+ mil of > >> downloads, so the size does not appear to be an obstacle to adopting > them. > >> It is my opinion that future official images will evolve to be better > >> aligned with how they are used, for example "server" and "workstation", > etc. > >> > >> REPOSITORY TAG IMAGE ID > >> CREATED SIZE > >> docker.io/ubuntu latest ebcd9d4fca80 > >> 6 weeks ago 117.9 MB > >> docker.io/debian latest e5599115b6a6 > >> 5 months ago 123 MB > >> docker.io/centos latest 67591570dd29 > >> 6 months ago 191.8 MB > >> docker.io/fedora latest a1e614f0f30e > >> 6 months ago 197.1 MB > >> > >> We can also modify the base image to remove some items if we think they > are > >> not needed. > >> > > > > I think using a base OS image is fine, and your text and Justin's link > > suggests there are likely to be improvements in some regards in this > > area too. There is also nothing stopping a further image as minimal > > size option based on Alpine etc, but obviously components would need > > to work and be supported there first and it wasn't clear that is > > currently always true. > > > >> My personal preference is to start with fedora image because this > >> distribution has latest upstream releases for qpid packages, and I am > the > >> maintainer for a number of these packages. > > > > I think we possibly need some clarity around the end result here, as > > it could strongly influence this particular area. > > > > For images to be considered 'official' Apache Qpid artifacts > > maintained directly by the project, they and their Qpid related > > contents would really need to be fully managed in concert with the > > projects release process. For example, if such an image were utilising > > packages to incorporate their relevant Qpid bits then I think it > > follows those packages would similarly need to be considered > > 'official' and handled similarly. Utilising the Qpid packages from > > Fedora distributions for example, wouldn't be appropriate in an > > 'official Apache Qpid' image since they are not directly managed > > artifacts of the Apache Qpid project. > > > > There wouldn't be an issue in simply considering such images to be a > > community-created convenience binaries based on the projects source > > release, as e.g. the existing Fedora packages themselves already are, > > but they wouldn't be considered 'official' Apache Qpid artifacts. It > > is worth saying this isn't particularly unusual, for example httpd > > direct people to their source releases but do reference various third > > party binaries for Windows users, and don't seem to be involved with > > the docker images for httpd, with members of the docker community > > instead handling that. > > > > I think either approach works here, having distribution based packages > > obviously has certain advantages for users and the project, so its > > probably more of a question around what people are actually expecting > > and/or looking to contribute towards here. > > > >> Fedora community is also working on its own docker registry (it will > have > >> stable and test registries), has koji support for building images and > >> guidelines for naming and versioning them. > >> > >> (3). What upstream releases will be dockerised? > >> > >> I would like to propose to start with latest released version. We will > >> maintain at most 1 version at any time. All code necessary to create > these > >> images should be included in the upstream source repository starting > with > >> the next release. We will provide security patches for it as needed (and > >> possibly will need patch releases). I am not sure if it will be > possible to > >> remove older releases from docker registries (TBD). > >> > >> (4) What will be used to configure docker images? > >> > >> We can use env to configure brokers/router, similar to what was done > here: > >> https://hub.docker.com/r/scholzj/qpid-cpp/ (courtesy of Jakub Scholz). > >> > >> References: > >> > >> #Changes/Layered Docker Image Build Service > >> https://fedoraproject.org/wiki/Changes/Layered_Docker_ > Image_Build_Service#Policies_and_guidelines > >> > >> #Fedora Docker Layered Image Build Service by Adam Miller > >> https://blog.openshift.com/wp-content/uploads/Introducing- > Docker-Layered-Image-Build-Service.pdf > >> > >> #OpenShift Commons Briefing #57: Fedora Docker Layered Image Build > Service > >> by Adam Miller > >> https://www.youtube.com/watch?v=HHm0L6Fw5nk > >> > >> #Layered Image Build System > >> https://docs.pagure.org/infra-docs/sysadmin-guide/sops/ > layered-image-buildsys.html > >> > >> #Atomic Reactor: Python library with command line interface for building > >> docker images. > >> https://github.com/projectatomic/atomic-reactor > >> > >> #Fedora Docker Layered image build service now available blog > >> https://communityblog.fedoraproject.org/fedora- > docker-layered-image-build-service-now-available/ > >> > >> #Example of container build: cockpit > >> https://koji.fedoraproject.org/koji/packageinfo?packageID=17959 > >> > >> #Container:Guidelines > >> https://fedoraproject.org/wiki/Container:Guidelines > >> > >> #Fedora container repo > >> https://src.fedoraproject.org/cgit/container/ > >> > >> #Building a modular Linux OS > >> https://docs.pagure.org/modularity/ > >> > >> #projectatomic/container-best-practices > >> https://github.com/projectatomic/container-best-practices > >> > >> #Container Best Practices > >> http://docs.projectatomic.io/container-best-practices/ > >> > >> #Red Hat Image Naming Policy > >> https://github.com/projectatomic/ContainerApplicationGenericLab > els/blob/master/vendor/redhat/names.md > >> > >> #Guidelines for Naming Fedora Packages (including docker images) > >> https://fedoraproject.org/wiki/Packaging:Naming?rd= > Packaging:NamingGuidelines > >> > >> #OCI: open container initiative > >> https://www.opencontainers.org/ > >> > >> #Changes/FedoraDockerRegistry > >> https://fedoraproject.org/wiki/Changes/FedoraDockerRegistry > >> > >> #Creating minimal Docker images from dynamically linked ELF binaries > >> http://blog.oddbit.com/2015/02/05/creating-minimal-docker-images/ > >> > >> #Why docker images should be small > >> https://opensolitude.com/2015/05/13/docker-images-should-be-small.html > >> > >> Regards, Irina. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > -K > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
