fix: Remove VOLUME from Dockerfile

[polarathene]

#52

FWIW, this will only realistically affect users of the image that use Docker Compose. Their data won't be lost provided they don't prune anonymous volumes before realizing, but honestly if your data is of importance to persist to disk you should not be relying on an implicit anonymous volume for this.

In the unlikely event actual users complain about the missing data, all they need to do is adjust image to any container image that has VOLUME /var/lib/rspamd, it doesn't need to be rspamd due to the way Docker Compose persists the volume (associated to the service not the image), which depending on content of the volume is also a security risk in that it can leak sensitive information.

Your compose example already mounts a named data volume over the implicit anonymous one from VOLUME, so any user following that guidance already won't be affected by this change:

rspamd-docker/examples/compose/compose.yaml

Lines 24 to 25 in def4084

	volumes:
	- rspamd-compose-rspamd-dbdir:/var/lib/rspamd

Removing this instruction removes surprises from not expecting implicit volumes/persistence, such as for someone trying the image out.

[dragoangel]

your view very limited to compose scope, we had discussion with @fatalbanana and this directive in Dockerfile not provide any harmful impact to compose or k8s or anything, it impact only pure docker run command and it had too, and that why it will be there.

[polarathene]

your view very limited to compose scope

What other scopes do you have in mind specifically?

this directive in Dockerfile not provide any harmful impact to compose or k8s or anything

Collapsed for brevity

I literally raised the PR because it caused unexpected behaviour with Compose use. I wanted to reset the container to a clean slate, and not knowing of any implicit VOLUME instruction at the time I did the usual docker compose up --force-recreate which one would expect provides a new container matching the image content, but in this case it did not.

The fact that sensitive data can leak due to the anonymous volume not being associated to the container in this context is something I'd consider harmful. I am not as familiar with the content of /var/lib/rspamd as you may be, so perhaps nothing sensitive is stored there? Otherwise you are choosing to actively dismiss valid security risks in addition to the caveat I raised complaint with.

---

it impact only pure docker run command and it had too, and that why it will be there.

? docker run vs docker compose differ.

• Docker Compose does not destroy the anonymous volume with the container, not many know about this and troubleshooting is not necessarily straight-forward as to why state persists when it's expected to have been removed as one would have with podman/docker/nerdctl run commands.
• Docker CLI (and others) will remove the anonymous volume when the container is destroyed, but only if invoked with --rm option. Otherwise each new container accumulates anonymous volumes on disk with little context to identify them. Manually removing the containers would not cleanup those anonymous volumes, one must be aware of it and prune them (potentially at the expense of other volumes that a user would prefer to keep, or manually remove which is quite inconvenient), not doing so can (depending on volume content) quickly eat into disk space.

---

All I'm conveying here are problems that are provable. I'm not sure why you're defending the use of VOLUME so much given it's legacy nature.

Could you please at least document here publicly the value you believe VOLUME provides the image?

Collapsed for brevity

Given that you already have explicit mounts documented to make it redundant, and that containers naturally have their own runtime layer of storage that persists within the container until the container is destroyed? (that's right it persists across container restarts without needing VOLUME)

You accuse me of a limited scope to compose, when that's effectively the only relevant context for VOLUME, but is an anti-pattern. The instruction was introduced early into the spec prior to support for named and bind mount volumes IIRC.

---

Update

• VOLUME is an anti-pattern and legacy, with various caveats that cause real problems (as per collapsed sections above).
• I've confirmed the Podman and Nerdctl equivalent compose subcommands do not match the docker compose sticky anonymous volume behaviour. podman run has an opt-in option to change how VOLUME is treated, including an option to out-right ignore it (similar has been proposed for docker run but no progress), I haven't checked similar support with nerdctl.
• The installed Rspamd .deb package ensures /var/lib/rspamd is already created with the _rspamd user/group ownership. Explicit anonymous/named volumes will inherit that and be compatible.
• README already states you should explicitly mount a volume to /var/lib/rspamd, further confirming that VOLUME in the Dockerfile is redundant:
  

  rspamd-docker/README.md

  Line 17 in def4084

  Volumes or bind mounts should be used for the `/var/lib/rspamd` directory and optionally for `/etc/rspamd`. If bind mounts are used, the `/var/lib/rspamd` directory should be writable by `11333:11333` on the host machine.

I'm still waiting on a legitimate reason to need VOLUME, given the container already provides it's own layer that persists through it's lifetime. Anything other than Docker Compose is going to discard that implicit anonymous volume upon image upgrade, so it's not providing any value persistence wise.