Mattermost

Upgrade Instruuctions

Mattermost

Upgrade process is now working. See below for notes on failed upgrade.

Find the correct docker tag for the new version at: Tags List
Update the MATTERMOST_IMAGE_TAG in Stack config in portainer
Click Update the stack button, enable the Re-pull image and redeploy option and click Update

It may be worth checking the upgrade notes

Failed Mattermost Upgrade Notes

This process was created combining info on updating the docker image and the Mattermost docs on upgrading the server.

It failed so I had to delete everything in the mattermost volume. This forced effectively a new install.

I now know the reason it failed is that all folders were mounted as a single volumn at /mattermost. The problem is this folder contains:

data in ./data
config in ./config
logs in ./logs
plugins in ./plugins and ./client/plugins
mattermost s/w in ./bin + other folders.

So either s/w is not updated because it is still in the volume or all software and data is lost to re-create the volume.

The fix is to follow the volume format from https://github.com/mattermost/docker/blob/main/docker-compose.yml and use different volumes for:

  * ${MATTERMOST_CONFIG_PATH}:/mattermost/config:rw
  * ${MATTERMOST_DATA_PATH}:/mattermost/data:rw
  * ${MATTERMOST_LOGS_PATH}:/mattermost/logs:rw
  * ${MATTERMOST_PLUGINS_PATH}:/mattermost/plugins:rw
  * ${MATTERMOST_CLIENT_PLUGINS_PATH}:/mattermost/client/plugins:rw
  * ${MATTERMOST_BLEVE_INDEXES_PATH}:/mattermost/bleve-indexes:rw

But it cannot work like this (in portainer). YAML does not allow ${VARIABLE_NAME} has the name of the key. So you have to use intermediate name:

volumes:
  intername:
    name: ${VARIABLE_NAME}

services:
  application:
    ...
    volumes:
      intername:/path:options