I have two containers, one for metabase and one for postgresql, both work correctly, only I have seen that the installation jar has a new user interface compared to the docker version that the previous one maintains.
My question would be to know if it is possible to upgrade to obtain the last interface and in any case which would be the best way, that is, if I can enter the container and execute the update from the command line, or modify the Dockerfile Metabase-Head
I guess you’re talking about 0.33.0-preview2 vs the current release 0.32.9?
I would not recommend that you use preview2 in any type of production - it’s work-in-progress and that version has many errors, which are being worked on.
If you really want to use it anyway, then you can shell into the container, stop the Metabase service, replace the current JAR-file with the preview2 JAR-file (think it’s located in
/app/metabase.jar), and then start the Metabase service again (or just restart the container).
I am not sure if it is the preview, I realized why I started the service from the terminal with:
java jar metabase.jar
Note differences in the interface and that’s why my doubt arose, but if it’s a preview I will leave it the same.
@sys2020 Okay, I think you should check which versions you’re using by clicking the gear icon () in the top-right corner and click About Metabase.
Hello friend, just to test I made the replace with the preview version, modify the docker-compose.yml file and address the folder / app to an external volume. Once the containers are lifted, check the folder assigned to that volume to verify that the file is there, then i stop the containers, and replace the metabase.jar file with the preview version, before start the containers again.
My surprise is that I keep my login information in the new version
I would like to know if in this way I can create my jar updates, that is, only by replacing the .jar inside the volume folder thought that it would respect me all the configuration within metabase (user, charts, etc) or is it too risky?
Why do you want to replace the jar-file inside of the docker instead of just using the official docker?
If you really want to do that, then you could just create a volume for
/app, redirecting it do somewhere on the host.
And please make sure that you don’t use H2 in production for metadata (users, charts, etc):
ok i will show you visually
There is the external volume which points to the data_mb folder (/home/admin/containers/metabase-occ/data_mb)
and there it is the .jar that its generated when i run the docker-compose.yml
I only access the folder where the original .jar was saved and replace it with wget (but all from outside the container)
I tried to unload the jar from inside the container but it marked an error in the url, so I decided to keep the .jar out of the container but within a volume
But please explain why you want to replace the jar-file inside the docker container?
It might just be better if you build your own container with whichever jar-file. You can probably quickly get an understanding, since the build script is fairly simple:
I am doing different tests to identify the best way to deploy the containers (metabase, postgrsql) and to be able to make a new version replace, quickly. I understood your point and indeed, it would be better to shoot the new version from the .sh
@sys2020 I might be misunderstanding what you’re trying to do, but upgrading the container is just like upgrading most other docker containers:
Just make sure you have a backup of the metadata before upgrading, in case something goes wrong or there’s a bug in the new version, then you can just downgrade to previous version and restore the metadata.