This project enables deployment of a Mattermost server in a multi-node production configuration using Docker.
Notes:
- The default Mattermost edition for this repo has changed from Team Edition to Enterprise Edition. Please see Choose Edition section.
- To install this Docker project on AWS Elastic Beanstalk please see AWS Elastic Beanstalk Guide.
- To run Mattermost on Kubernetes you can start with the manifest examples in the kubernetes folder
- To install Mattermost without Docker directly onto a Linux-based operating systems, please see Admin Guide.
The following instructions deploy Mattermost in a production configuration using multi-node Docker Compose set up.
- docker (version
1.12+) - docker-compose (version
1.10.0+to support Compose file version3.0)
If you want to install Enterprise Edition, you can skip this section.
To install the team edition, uncomment out these lines in docker-compose.yaml file:
args:
- edition=teamThe app Dockerfile will read the edition build argument to install Team (edition = 'team') or Enterprise (edition != team) edition.
This repository offer a Docker image for the Mattermost database. It is a customized PostgreSQL image that you should configure with following environment variables :
POSTGRES_USER: database usernamePOSTGRES_PASSWORD: database passwordPOSTGRES_DB: database name
It is possible to use your own PostgreSQL database, or even use MySQL. But you will need to ensure that Application container can connect to the database (see Application container)
If deploying to AWS, you could also set following variables to enable Wal-E backup to S3 :
AWS_ACCESS_KEY_ID: AWS access keyAWS_SECRET_ACCESS_KEY: AWS secretWALE_S3_PREFIX: AWS s3 bucket nameAWS_REGION: AWS region
All four environment variables are required. It will enable completed WAL segments sent to archive storage (S3). The base backup and clean up can be done through the following command:
# Base backup
docker exec mattermost-db su - postgres sh -c "/usr/bin/envdir /etc/wal-e.d/env /usr/bin/wal-e backup-push /var/lib/postgresql/data"
# Keep the most recent 7 base backups and remove the old ones
docker exec mattermost-db su - postgres sh -c "/usr/bin/envdir /etc/wal-e.d/env /usr/bin/wal-e delete --confirm retain 7"Those tasks can be executed through a cron job or systemd timer.
Application container run the Mattermost application. You should configure it with following environment variables :
MM_USERNAME: database usernameMM_PASSWORD: database passwordMM_DBNAME: database name
If your database use some custom host and port, it is also possible to configure them :
DB_HOST: database host addressDB_PORT_NUMBER: database port
If you use a Mattermost configuration file on a different location than the default one (/mattermost/config/config.json) :
MM_CONFIG: configuration file location inside the container.
If you choose to use MySQL instead of PostgreSQL, you should set a different datasource and SQL driver :
DB_PORT_NUMBER:3306MM_SQLSETTINGS_DRIVERNAME:mysqlMM_SQLSETTINGS_DATASOURCE:MM_USERNAME:MM_PASSWORD@tcp(DB_HOST:DB_PORT_NUMBER)/MM_DBNAME?charset=utf8mb4,utf8&readTimeout=30s&writeTimeout=30sDon't forget to replace all entries (beginning byMM_andDB_) inMM_SQLSETTINGS_DATASOURCEwith the real variables values.
If you want to push Mattermost application to Cloud Foundry, use a manifest.yml like this one (with external PostgreSQL service):
---
applications:
- name: mattermost
docker:
image: mattermost/mattermost-prod-app
instances: 1
memory: 1G
disk_quota: 256M
env:
DB_HOST: database host address
DB_PORT_NUMBER: database port
MM_DBNAME: database name
MM_USERNAME: database username
MM_PASSWORD: database password
This image is optional, you should not use it when you have your own reverse-proxy. It is a simple front Web server for the Mattermost app container. If you use the provided docker-compose.yml file, you don't have to configure anything. But if your application container is reachable on custom host and/or port (eg. if you use a container provider), you should add those two environment variables :
APP_HOST: application host addressAPP_PORT_NUMBER: application HTTP port
If you plan to upload large files to your Mattermost instance, Nginx will need to write some temporary files. In that case, the read_only: true option on the web container should be removed from your docker-compose.yml file.
Put your SSL certificate as ./volumes/web/cert/cert.pem and the private key that has
no password as ./volumes/web/cert/key-no-password.pem. If you don't have
them you may generate a self-signed SSL certificate.
If you are looking for SSO with GitLab and you use self signed certificate you have to add the PKI chain of your authority in app because Alpine doesn't know him. This is required to avoid Token request failed: certificate signed by unknown authority
For that uncomment this line and replace with the correct path of your PKI chain:
# - <path_to_your_gitlab_pki>/pki_chain.pem:/etc/ssl/certs/pki_chain.pem:ro
If you are running docker with non root user, make sure the UID and GID in app/Dockerfile are the same as your current UID/GID
mkdir -p ./volumes/app/mattermost/{data,logs,config,plugins}
chown -R 2000:2000 ./volumes/app/mattermost/
docker-compose start
docker-compose stop
docker-compose stop && docker-compose rm
sudo rm -rf volumes
First, shutdown your containers to back up your data.
docker-compose down
Back up your mounted volumes to save your data. If you use the default docker-compose.yml file proposed on this repository, your data is on ./volumes/ folder.
Then run the following commands.
git pull
docker-compose build
docker-compose up -d
Your Docker image should now be on the latest Mattermost version.
Docker images for 4.9.0 release introduce some important changes from PR #241 to improve production use of Mattermost with Docker.
There are 2 important changes for existing installations
One important change is that we don't use root user by default to run the Mattermost application. So, as explained on the README, if you use host mounted volume you have to be sure that files on your host server have the correct UID/GID (by default those values are 2000). In practice, you should just run following commands :
mkdir -p ./volumes/app/mattermost/{data,logs,config,plugins}
chown -R 2000:2000 ./volumes/app/mattermost/
The second important change is the port used by Mattermost application container. The default port is now 8000, and existing installations that use port 80 will not work without a little configuration change. You have to open your Mattermost configuration file (./volumes/app/mattermost/config/config.json by default) and change the key ServiceSettings.ListenAddress to :8000.
Also if you use your own web-server/reverse-proxy you need to change its configuration to reach port 8000 of the Mattermost container.
You need to migrate your database before upgrading Mattermost to 3.0.x from
2.x. Run these commands in the latest mattermost-docker directory.
docker-compose rm -f app
docker-compose build app
docker-compose run app -upgrade_db_30
docker-compose up -d
See the offical Upgrade Guide for more details.
The following instructions deploy Mattermost in a production configuration using docker swarm mode on one node. Running containerized applications on multi-node swarms involves specific data portability and replication handling that are not covered here.
- docker (1.12.0+)
First, create mattermost directory structure on the docker hosts:
mkdir -p /var/lib/mattermost/{cert,config,data,logs,plugins}
Then, fire up the stack in your swarm:
docker stack deploy -c contrib/swarm/docker-stack.yml mattermost
- Do not modify the Listen Address in Service Settings.
- Rarely
appcontainer fails to start because of "connection refused" to database. Workaround: Restart the container.
If you want to know how to use docker-compose, see the overview page.
For the server configurations, see prod-ubuntu.rst of Mattermost.