modsecurity-crs-docker: Look on how to retain older images in case latest is broken

I think the root of the problem here is that you are trying to re-use the the version from something else (maybe ModSecurity itself?) to also version the container images. I think they have to be versioned separately as there is a whole lot of configuration-files, image definitions and versions of other involved software (apache, nginx, etc.) that has an influence on the API of the images. Having an independent version solves these problems and I guess is also what people generally expect.

We had the same problem on our side - We got cached by the fact, that the underlying Nginx Docker image also changed and the new template paths came in. May you could also try to decouple the two versions. It should be allowed to add i.e. 3.3.2-134, then you have in the first part the modsecurity version and behind a buildnumber/releasenumber for the Dockerfile. Or decouple it completely and set your own version numbers and you change the minor whenever the version of modsecurity changes. And then write it into every changelog which modsecurity version is included. Any solution would help to stabilize the deployment procedure.

The images have been overridden again and caused an outage of one of our services due to changed behaviour (not yet diagnosed).

This makes the images unusable for any productive scenario.

So, the corresponding fix in this repo is linked now: https://github.com/coreruleset/modsecurity-crs-docker/pull/88.

Now we are building on top of a specific version from the base repo. So each build will be unique and long term, if you use the proper tag.

Let me know what you think @matthiasbaldi @arnegroskurth.

Ok, started with something. This is the PR I have for the base docker: https://github.com/coreruleset/modsecurity-docker/pull/140. If you have any comments, please add them there! the idea is to replicate it here in a similar way.

Ok, let me think about this for a bit, and will circle back. Using just latest was deprecated because we have “two” latest (one for apache and one for nginx)

I think even though that would already been an improvement from the current situation, it is not really ideal as the update process is much less straight forward with that solution. Semantic versioning is all about categorizing and communicating changes to your software component which is completely gone when you effectively version the component by date. With just a meaningless date as versioning information, I, as a user of the component, have to go through all changes when updating the component to be able to decide whether I also have to change my system due to a breaking change or can rely on the component still function like before. And for what?

So may I ask what your reasoning for that is?