Update Dockerfiles - Githubissues

OpenSCAP / openscap-daemon

Manages continuous scans of your infrastructure

https://www.open-scap.org/tools/openscap-daemon

GNU Lesser General Public License v2.1

106 stars 32 forks source link

Update Dockerfiles #102

Closed jan-cerny closed 7 years ago

jan-cerny commented 7 years ago

We have Dockerfiles in this repository to build various containers with OpenSCAP, either packages or from git. They are outdated and very different from what is used in registry.access.redhat.com/rhel7/openscap. I think that for testing and development it would be beneficial to have a Dockerfile that will build an image that is very similar to registry.access.redhat.com/rhel7/openscap, but with fresh OpenSCAP daemon from upstream git.

Maybe we could remove current Dockerfiles.

shawndwells commented 7 years ago

On 6/6/17 7:50 AM, Jan Černý wrote:

We have Dockerfiles in this repository to build various containers with OpenSCAP, either packages or from git. They are outdated and very different from what is used in |registry.access.redhat.com/rhel7/openscap|. I think that for testing and development it would be beneficial to have a Dockerfile that will build an image that is very similar to |registry.access.redhat.com/rhel7/openscap|, but with fresh OpenSCAP daemon from upstream git.

Maybe we could remove current Dockerfiles.

.... there are OpenSCAP container images in Red Hat's registry?! What are they used for? Better yet.... where is the documentation on what OpenSCAP Daemon is?

I know work was happening on GitHub... never heard this was shipping!

mpreisler commented 7 years ago

where is the documentation on what OpenSCAP Daemon is?

There is https://github.com/OpenSCAP/openscap-daemon/blob/master/README.md

openscap-daemon is used for atomic scan feature. Only a small subset of what openscap-daemon can do is used in production today.

jan-cerny commented 7 years ago

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 copy-paste that registry.access.redhat.com/rhel7/openscap
Make a script that would create a Dockerfile and all the files and eventually build the image. It could be parametrizable, so the user could choose base image, versions of packages (usptream/distro), etc.

The goal that I want is to be able to easily test the upstream Daemon together with Atomic. I think that it could be also an upstream for registry.access.redhat.com/rhel7/openscap

Any opinions?

jan-cerny commented 7 years ago

I use now this workflow: I have a Dockerfile locally, I have ./build.sh and it creates a Fedora based image, with fresh upstream OpenSCAP Daemon. The image is tagged openscap:testing, then I just change the image name in /etc/atomic.d/openscap and Atomic uses it instead of registry.access.redhat.com/rhel7/openscap automatically. This seems really easy and works OK so far.

Are we insterested to include something like that into upstream?

What about my suggestions from the previous comment?

jan-cerny commented 7 years ago

I have opened a thread on the mailing list to affect more people. https://www.redhat.com/archives/open-scap-list/2017-June/msg00009.html

jan-cerny commented 7 years ago

What about using S2I for build directly from source? https://docs.openshift.com/enterprise/3.2/creating_images/s2i.html#creating-images-s2i

jan-cerny commented 7 years ago

Fixed in https://github.com/OpenSCAP/openscap-daemon/pull/106