Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker image 3.10 distributes matomo 3.9 files from volume after update #161

Closed
markuman opened this issue Jul 9, 2019 · 9 comments
Closed

Comments

@markuman
Copy link

markuman commented Jul 9, 2019

This docker image uses /var/www/html as volume. And on an init startup e.g. of 3.9, it moves all files to that path/volume https://github.com/matomo-org/docker/blob/master/apache/docker-entrypoint.sh#L5
When I start docker image version 3.10, this step won't be executet. So I run matomo docker image 3.10, but my volume distributes still the files from matomo 3.9

@msander
Copy link

msander commented Jul 24, 2019

Why is the moving necessary? Can't we just do this during the build of the docker container? Installing plugins should still be possible because of OverlayFS.
Database Migrations should also be run at container start.

@larsskj
Copy link

larsskj commented Nov 21, 2019

I agree this is a quite serious issue.
So - how are you supposed to do a proper upgrade using Docker containers? Would anybody know?

@dbrgn
Copy link

dbrgn commented Jan 22, 2020

Whoa, this is quite unexpected. My container is on 3.13.1 but the codebase served is still 3.12.

What is the workflow to keep the version up to date? How are other people doing it that run Matomo in production using Docker?

@markuman
Copy link
Author

My workflow atm is:

  1. update matomo using the webfrontend
  2. update the docker container to the same version

dunno how others handle this? maybe most matomo users doesn't use docker in production?

@carlosgeos
Copy link

I did (3.13.0 -> 3.13.1):

  1. Update docker container.
  2. Update through web interface.

And it seems to work as well.

@markuman
Copy link
Author

markuman commented Feb 2, 2020

Yeah, but caution: this will work as long as matomo didn't change their behaviour and won't touch the volume location in a future docker image release.
And update the image is necessary, because otherwise the underlying base image won't get any persistent updates too.

@houfu
Copy link

houfu commented Dec 30, 2020

I am not able to upgrade from 3.13.6 to 4.x.x. Pressing check for updates in the web interface tells me that 3.13.6 is latest version (hogwash! 💢 ) I have also updated the docker container several times but still cannot get past 3.13.6. Am I missing something?

nigelgbanks added a commit to Islandora-Devops/isle-buildkit that referenced this issue Apr 15, 2021
Having the code base in a volume makes upgrades and migrations a pain,
additionaly the file copies on initial startup can be really slow on NFS
drives.

Having a volume allows for the dynamic installation of plugins, but then
that is specific to that instance, if you were to run a several stage
environment dev/stage/prod then one would need to manually check that
the plugins exist is each environment. Better would be to extend the
image and pack the plugins in with the installation.

@see matomo-org/docker#57
@see matomo-org/docker#161
nigelgbanks added a commit to Islandora-Devops/isle-dc that referenced this issue Apr 15, 2021
Having the code base in a volume makes upgrades and migrations a pain,
additionaly the file copies on initial startup can be really slow on NFS
drives.

Having a volume allows for the dynamic installation of plugins, but then
that is specific to that instance, if you were to run a several stage
environment dev/stage/prod then one would need to manually check that
the plugins exist is each environment. Better would be to extend the
image and pack the plugins in with the installation.

@see matomo-org/docker#57
@see matomo-org/docker#161
nigelgbanks added a commit to Islandora-Devops/isle-buildkit that referenced this issue Mar 23, 2022
Having the code base in a volume makes upgrades and migrations a pain,
additionaly the file copies on initial startup can be really slow on NFS
drives.

Having a volume allows for the dynamic installation of plugins, but then
that is specific to that instance, if you were to run a several stage
environment dev/stage/prod then one would need to manually check that
the plugins exist is each environment. Better would be to extend the
image and pack the plugins in with the installation.

@see matomo-org/docker#57
@see matomo-org/docker#161
@ghnp5
Copy link

ghnp5 commented Apr 14, 2022

See related #281
Just experienced the same thing! Upgraded the image, restarted the container, and still on the old version, because the mounted /var/www/html/ hasn't updated at all.

There needs to be a check on start up to copy the files over or so! (without replacing important things in the state, like config.ini.php)

nigelgbanks added a commit to Islandora-Devops/isle-buildkit that referenced this issue May 12, 2022
* No longer use volume for Matomo install

Having the code base in a volume makes upgrades and migrations a pain,
additionaly the file copies on initial startup can be really slow on NFS
drives.

Having a volume allows for the dynamic installation of plugins, but then
that is specific to that instance, if you were to run a several stage
environment dev/stage/prod then one would need to manually check that
the plugins exist is each environment. Better would be to extend the
image and pack the plugins in with the installation.

@see matomo-org/docker#57
@see matomo-org/docker#161

* Matomo: create a per-site administrator in addition to the super administrator for all sites.
@J0WI
Copy link
Collaborator

J0WI commented Nov 26, 2022

duplicate of #248

@J0WI J0WI closed this as completed Nov 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants