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/ContainerApplicationGenericLabels/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]
