I’m currently trying to update my metabase instance which is running in docker. I tried it like this:
If you are running it via docker, then you simply kill the docker process, and start a new container with the latest image. On startup, Metabase will perform any upgrade tasks it needs to perform, and once it is finished, you’ll be running the new version.
Unfortunately this is not working, it’s still the old version.
Glad to hear! It’s probably worth mentioning that you’d need to set up a volume for the Metabase database (or have it persisted outside the container somehow) before doing this – or you’ll lose information.
Seems like a small note could be added to the documentation to mention pulling the new version of the image before running…
The link you gave probably has the right wording already: “… simply kill the docker process, and start a new container with the latest image”; maybe the docker-specific guide can shed extra light on how to get the latest image?
I'm a little bit hesitant to update metabasse using docker and maybe lose my configuration. I've got no experience with Docker so could anyone please give a step by step instruction?
you simply need to kill the Docker process and start a new container with the latest Metabase image
but it isn't described what we should type exactly and in which order into the command line. It's probably really simple but I'm not sure how to do this. I could also not find any other topics that lays out these steps.
Just remember to always backup before doing major changes, so you can always revert.
If you decided to use Docker, then you should really read the documentation, so you’re comfortable with how it works - upgrading containers is not unique to Metabase: https://docs.docker.com/
Without knowing your container names, you would do something like this (ref): docker stop metabase docker rm metabase docker pull metabase/metabase:latest docker run -d -p 3000:3000 --name metabase metabase/metabase … (I don’t know your run config)
Thanks for your response. I am not using H2 as the data source, I’m using MySQL and Google Analytics as database sources.
I’m just not sure where the metabase dashboard config (not the actual data) like questions, dashboard names, pulses, etc are stored. If I upgrade the container like you described above, will I lose this config?
If not I will continue using your above example, I have used all default names for docker. I have made a backup.
@nevil
H2 is the default internal database (not a data source). That’s where all settings and metadata is stored.
So since you don’t know, then I would guess you’ll lose everything on upgrade, since by default the H2 is located inside the container.
I think this is unnecessarily complicated for users like me. Almost everything about metabase is very user friendly and easy to understand, except upgrading for some reason. I would prefer just clicking on update, and it will do the work for me. Or better even, just upgrading automatically in the background without clicking update or me even noticing it.
There is probably some reason for it that that is not the case now, but from a users perspective that would be the best solution imo.
Having Metabase “magically” upgrade would be a really bad idea. The only time where you want auto-upgrade is for security, not when an application introduces new features.
Metabase is being used by all sizes - so from a single user running it to big companies with thousands of users running on multiple servers.
Since Metabase is essentially a JAR-file, a feature like auto-upgrade would be really difficult. There’s probably ways around this, but that would require another service running that would take care of the upgrade.
You can just use the JAR-file instead of Docker, which would mean that you simply download and replace the existing JAR-file and that would be the upgrade.
H2 was chosen because you could start using Metabase really fast, with almost zero configuration. But if you started to use Metabase in production, then you should move to a different backend database (as noted many times in the documentation).
If you want to continue using H2, you can even place the database outside of the container, so you’re not destroying it, when upgrading - but that would still be using H2, which is not recommended for production, since it doesn’t handle corruption very well.
So having an easy-upgrade-feature, would mean that the setup process would become more difficult.
I’ve done the upgrade and migration away from H2 like the docs describe, but have found out that I can’t login to the new container via the website (localhost:3000) since one of the configs isn’t reading right. So with a fast set up, there does need to be a warning or two in the UX that say - “don’t configure this without migrating off H2” or something.
@fozzy
There should be no differences between the H2 and whichever database you chose.
You should probably start a new thread and post more details like versions, which database and logs.
But it’s possible to run with H2 - just make sure your computer/server never crashes or shutdown because of power problems.
The documentation has multiple sections about not using H2 in production.
The log has a big warning on startup about not using H2 in production.
Thanks @flamber! We finally just re-configured from zero in Postgre for the session we're building. Now we're on to figuring out how to implement Charts.
I know this is fairly old, and having looked at the documentation mentione here, I too am using Docker to run metabase. The documentation appears to be directed at the use of metabase installed directly to the server it’s running on, and the commands don’t seem to take into account H2 in docker and MySQL on the native OS. Is there any difference in the migration commands and environment variables used when Docker is in play?
But now there's nothing on the ip adress I used to have it (error connectionfailure).
The instance is active in docker (having a new id though). What am I doing wrong?
Thanks!