I think it all depends on your personal preference and how you’d like to work. I do find the docker deployment method not as transparent as the binary deployment and it’s much more configurable, because I’m not limited to what’s there in the container, but as a sysadmin I have to say that, I guess If you do not want to take care of things like that and are happy with what is being provided, docker might be the better option for you.
The upgrade instructions are basically the same for both deployments, it all boils down to:
- get the new version
- extract it
- backup the old version (or move it aside)
- install the new version
- start the new version
- watch the magic (aka database migration) happen
What docker does, is it decouples the directories you want to keep during an upgrade (config, data, logs, etc.) from the application by moving them out to the “volume” subdirectory which will then be mounted into the container, that way it is easy to just install a new container and do not have to worry about the rest.
But you can also achieve that with the binary installation, there are configuration options to point those directories to different paths, outside the mattermost installation and if you do that, the upgrade process for the binary installation changes a bit and also makes it easier because you do not have to copy things around, but just start the new version then.
So there are pros and cons for both versions and if you want to switch from one to the other, we’ll help you with that.
I’ve not done this yet, but I could imagine the following points need to be done:
- install the same mattermost version and edition with docker on the same or a different system without any specific configuration, so that an empty setup is running to make sure everything is configured correctly (containers, ssl offloading, database, etc.)
- shut down the container deployment
- copy the directories “data”, “logs”, “config”, “client” and “plugins” from your binary installation over to “volumes/app/mattermost” on your docker deployment
chown -R 2000:2000 volumes/app/mattermost (docker container uses UID 2000 and your binary installation probably uses “mattermost” with a different UID)
If you want to keep the database outside the containers, this should be all it needs then, because the config.json you copied over from your binary installation already points to the existing database installation. As long as you do not use a socket connection but a TCP connection, this should work (you cannot access the socket from within the container).
Also SMTP or other external resources (like ElasticSearch) will need to be tested then.
If you’re using the bleve index you can either reindex it after you migrated to the docker deployment or also copy over the “bleve” directory in the step where you copied config, data, etc.
If you also want to migrate the database into docker it’s important to say that the docker compose templates from mattermost by default use postgres, so I’ve never tried to deploy it with a mariadb/mysql container for the database part, but this probably also will work. So if you’re running postgres in your binary deployment, you would have to dump the database there (
man pg_dump) and restore it into the database that’s running as a container then (
If your binary deployment is on MariaDB/MySQL, you should either try to get this version running inside a container instead of the PostgreSQL container or we could try a whole different approach instead of what is outlined above by going the
mmctl export and
mmctl import route.
Sorry for this wall of text, but it all depends a bit on what your current setup looks like, the details not mentioned so far and if you want to go all-in on the docker approach or leave parts outside of it.