Container not immutable
juho9000 opened this issue · 4 comments
Why are we moving files around the container in the entrypoint script when we could just do this all as a part of the build process. It is a security best practice to keep the root file system of your container read only. Naturally we could set a tmpfs mount to the path being used, but this makes no sense to me in the first place.
Matomo won't work on a read only filesystem. Furthermore it contains an auto update mechanism and users can add plugins.
@juho9000 You might want to have a look on Bitnami Docker Image for Matomo. It's not entirely immutable (plugins and configuration are stored on a shared volume by default) but it's better than the code being served from a shared storage 😅.
You can extend bitnamis image to include plugins during build process by copying them in /opt/bitnami/matomo/plugins/, and add a common.config.ini.php (either during build process, or mounted at run time) to pre-configure your matomo instance. That way you might even be able to get rid of the shared volume entirely.
@J0WI immutability makes sense in several use cases. Having the exact definition of your instance (including which plugins were installed/upgraded) being tracked in a CVS makes it easier to debug (and rollback changes if necessary).
Or just take a look at the official nextcloud docker app.
It simply work as the matomo docker image should have work.
You start the image and put your volume/mount to /var/www/html - if it is empty, it will be initialized.
You can update nextcloud using webui - or just update the container with a new image and it will do the update.
The auto update mechanism will only work until the container is restarted, then it will go back to the source files that are baked into the image. This could cause database issues.
Generally with docker, source files are backed into the image and any directory that would be written to like tmp, cache, or plugins, would be created as a volume.
At this point, people may be relying on the production docker image and its unique implementation. Changing it significantly may break production installations that have built solutions around it.
A pull request would likely have to include a new tag that users could adopt incrementally. (e.g. matomo:4.2-multiserver)