question: an alternative strategy how to use the matomo docker image

[nflow]

hey, i have a question regarding an alternative strategy how to use the matomo docker image.

as far as i have observed it, the matomo applicaiton is copied by the entryscript.sh, if the matomo.php is not present, to the /var/www/html folder. since matomo performs various changes to the applicaiton during runtime, e.g. plugins, misc and config. the application folder is mounted externally, to not lose our configuration. the problem with that behavior is that updating a docker image will have no effect on deployments. thats my assessment so far.

in order image updates affect the applicaiton itself i did a few changes. i decided to mount only:

• /var/www/html/config/config.ini.php
• /var/www/html/plugins
• /var/www/html/misc
  each time i recreate the container all applications will be overwritten with the originals and the update of an image will affect the application itself. furthermore, i prefer to mount relevant configs and folders which make backups more straight forward, in my opinion. i used our current installation in a test setup and switched to the proposed strategy and everything seems to work.

can you think of any issues that may come up doing it this way?

here is the compose file i used:

version: '3.9'

services:
  mysql:
    image: "mariadb"
    command: "--max-allowed-packet=64MB"
    restart: "unless-stopped"
    volumes:
      - "db:/var/lib/mysql"
    environment:
      MYSQL_ROOT_PASSWORD: r00t_p4ssw0rd
      MYSQL_PASSWORD: p4ssw0rd
      MYSQL_DATABASE: matomo
      MYSQL_USER: matomo

  matomo:
    image: "matomo:4.6"
    restart: "unless-stopped"
    volumes:
      - ./configs/php-matomo.ini:/usr/local/etc/php/conf.d/php-matomo.ini:ro
      - ./configs/config.ini.php:/var/www/html/config/config.ini.php
      - plugins:/var/www/html/plugins
      - misc:/var/www/html/misc
    networks:
      - "default" 

volumes:
  db:
  plugins:
  misc:

thanks and kind regards!

[ulope]

Thanks, that sounds like a much more sane way to run Matomo in docker.

[hoermannklaus]

Absolutely what I experienced. I deploy Matomo in a Kubernetes cluster. And made persistent volume claims for all the folders you mentioned.
Any hints on why the "entrypoint.sh" script does this copying? Whats the reason for this setup?

[djmaze]

@nflow Can you tell me which files Matomo makes changes to in the misc folder? In my case it seems those files are not changed at all.

[hoermannklaus]

I use the IP2LOCATION plugin. This tells me to put the binary database into the "misc" folder. So I need to persist this folder. Otherwise the database is gone after a Redeploy.

[tuky]

Any hints on why the "entrypoint.sh" script does this copying? Whats the reason for this setup?

@hoermannklaus See https://github.com/matomo-org/docker/blob/master/Dockerfile-debian.template#L99 and combine that piece of information with https://hub.docker.com/_/matomo:

The app matomo itself is not well structured. On the one hand you need /var/www/html to be a volume, to persist runtime changes. On the other hand /var/www/html is supposed to host the app code itself. Hence the solution of OP to dissect app code from persisted runtime changes.

[ptemmer]

This solution would work, weren't it for the anonymous docker volume that gets created automatically (due to the "VOLUME /var/www/html" instruction in the Matomo Dockerfile.

Or aren't you guys using the official image?

[ulope]

When you specify a mounted volume in the compose file (or even on the cli for that matter) with the same target inside the container it overrides the VOLUME command from the dockerfile.

[ptemmer]

But isn't mounting /var/ww/html precisely what we want to avoid? And instead just mount the config, plugins and misc subdirectories?

Thanks!

[ulope]

Ah, yeah of course you're right.

[Findus23]

@djmaze

Can you tell me which files Matomo makes changes to in the misc folder? In my case it seems those files are not changed at all.

In addition to what is mentioned above, at the very least the Matomo built-in GeoIP2 plugin stores its files there and the custom logo upload feature also puts the images into misc/

[tuky]

We're using bitnami's matomo docker image (https://hub.docker.com/r/bitnami/matomo) and we can only suggest you to use it, too. All you need to do here is specify /bitnami/matomo as the volume (see https://github.com/bitnami/bitnami-docker-matomo/blob/master/docker-compose.yml).

[ptemmer]

@tuky, I actually looked into the bitnami container the other day.
It's a generic base container where a bunch of scripts (/opt/bitnami/scripts) setup apache, php, the software, etc.. which at first sight adds complexity, especially when trying to debug when something isn't working properly.
I'm in two minds about it.

What are your thoughts on that?

[tuky]

We actually acknowledge that as a blackbox, just like matomo's code is a blackbox to us. But we trust in bitnami's competency and looking at the scripts their setup seems well structured. They have a large community and because it's open source we can still dive in, if something breaks. They made rootless work but we use it as root user, because that also runs cron inside the container to periodically run the archiver. It was surprisingly easy to set up a running service using AWS ECS and an EFS for volume persistence.

[djmaze]

I also think the bitnami approach seems to add much complexity which you need to understand, and I don't really get the benefits. I like containers to be as simple as possible.

The official matomo image works almost perfectly in our swarm mode setup. (Although we needed to increase PHP's memory limit and max execution time, so we derived an image from the official one using a very short dockerfile).

For running, we just assign volumes for the config and plugins folders, because we don't need the geoip stuff. We run an app container and a separate archive container (which runs ./console core:archive --no-interaction and is triggered by cron, or rather swarm-cronjob in our case).

Updating matomo then is as simple as running the update in the web interface and then restarting the containers / services with the updated docker image according to the new version.

[yi-yang-github]

Btw in the end I found https://github.com/crazy-max/docker-matomo works much better.

[J0WI]

Duplicate of #248 and matomo-org/matomo#19151. Unfortunately Matomo does not provide a cli to update the application. Just replacing the files may result in a broken database schema.

[zofrex]

It would be really useful if, in addition to closing issues and explaining what doesn't work, you could explain what does work? There's a lot of comments from people on one way or another to do this, and I'm personally left not really understanding how to upgrade Matomo at all.

[J0WI]

#248 (comment) is the only supported update mechanism by Matomo.

[adelca]

This does not make sense, what does "NEW UPDATE: MATOMO x.x.x" button do to a container running on an already updated image?
I am running Matomo fpm-alpine on an EKS cluster + RDS.
I went from matomo:5.1.2-fpm-alpine to matomo:5.2.2-fpm-alpine and the UI still requested me to click on the update button.
There is no documentation about how to update a Matomo container using a new image, the closest I could find is this:
https://matomo.org/faq/on-premise/update-matomo/

But again, this does not make sense, it says it will download new files which we dont need because I already updated the image.

Will there be an official document explaining how to update a Matomo app running on containers? Also we must consider automation/scripting ways of doing it, there is no way I will be clicking on some button to update tens of environments lol

[michalkleiner]

@adelca see my explanation in #375 (comment).