Hi, I would like to move the discussion about Dockerfiles for OpenSCAP container from GitHub [1] to the mailing list, because I'm interested in solving that topic.
Nowadays, OpenSCAP Deamon upstream repository contains multiple Dockerfiles in this repository to build various container images with OpenSCAP. There are Dockerfiles to build either from packages [2] or from latest upstream code [3]. The problem is that the Dockerfiles are outdated. They used to be to demonstrate "atomic scan", but now we ship an image called "openscap" in Red Hat Registry. Moreover, upstream dockerfiles are very different from what is used to build image registry.access.redhat.com/rhel7/openscap. Also there is a lot of duplication in the repository, because the multiple variants are almost the same. Firstly, I think that for testing and development it would be beneficial to have a Dockerfile that will enable upstream community to build an image that is very similar to registry.access.redhat.com/rhel7/openscap, but with fresh OpenSCAP daemon from upstream git. Also, the new Dockerfile and other files can be used as a template for downstream container builds. There are multiple solutions: * Keep the current directory structure in atomic and atomic-git. Update all current Dockerfiles, add all the files. However I'm afraid that there will be a lot of duplicates. * Remove the atomic and atomic-git. Make a new directory, that would contain Dockerfile and other files. We can reuse the files that are now used for our container image in Red Hat Registry. * Make a script that creates a Dockerfile and all the required files and builds the image. It could be parametrizable, so the user could choose base image, versions of packages (usptream/distro), developer's branches, etc. I use now this workflow: I have a Dockerfile on my laptop, I have a script that creates an image (based on Fedora) with fresh upstream OpenSCAP Daemon. The image is tagged as 'openscap:testing'. Then I just configure the image name in '/etc/atomic.d/openscap' and Atomic uses it instead of registry.access.redhat.com/rhel7/openscap automatically. This seems to me really easy and works OK so far. Are we interested to include something like that into upstream? What are your opinions on our upstream Dockerfiles? [2] [3] Regards [1] https://github.com/OpenSCAP/openscap-daemon/issues/102 [2] https://github.com/OpenSCAP/openscap-daemon/tree/master/atomic [3] https://github.com/OpenSCAP/openscap-daemon/tree/master/atomic-git Jan Černý Security Technologies | Red Hat, Inc. _______________________________________________ Open-scap-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/open-scap-list
