Use Docker volumes

[yukiisbored]

With docker volumes, you can create a virtual volume for bindings. This is useful to save stateful data such as configuration. The reason why using docker volumes is better than binding it to host is to isolate it more from the host and make it more friendly in swarm configurations.

[pichouk]

I think we should keep Host mounted volumes on the docker-compose.yml file, it could be a breaking change to lot of people if we change this behavior. Also, it allow an easier direct access to data than Docker volumes.

But I agree it could be interesting to use Docker volumes with Swarm. If you submit a PR to add this to the contrib/swarm/docker-stack.yml file, I'll be happy to review and merge :)

[yukiisbored]

@pichouk We can just have another docker-compose file like docker-compose.v3.yml which leverages the features v3 and Docker 1.10.3+ have.

[pichouk]

@xcompass What do you think about this ? I didn't like the idea to have multiple docker-compose.vX.yml file because it can confused people. But maybe I'm wrong about this and it could be better.

[xcompass]

Just did a reading on docker volume. They recommend using volume instead of binding for storing data. I don't have any objection to switch to volume. However, we need to figure out a way for current users to migrate with proper documentation.

[HorayNarea]

In favour of bindings: they are easier to backup

[pichouk]

Moving to Docker volumes is a big changes for current users and I kind of like bindings since it is easy to backup/modify your data (eg. Mattermost config.json file). But in the other hand, Volumes (and generally Swarm/Docker compose 3 features) seems to be more and more in demand.

I suggest to officially support Docker Swarm on this repository and move contrib/swarm/docker-stack.yml at the root of this repository. Then we'll be able to keep some "old-school" stuff inside docker-compose.yml and add some Swarm oriented features (like using Docker volumes) on docker-stack.yml. As soon as we add correct documentation about, seems ok for me.

Seems good for you ?

[yukiisbored]

@pichouk I agree, sounds like a good idea.

[pichouk]

I keep this issue opened but in standby for the moment. We will probably change our repository organization with PR#195. We will probably add Docker volumes features to the new Swarm-oriented configuration file. Stay tuned, I don't forget this issue :)

[pdemagny]

Awaiting #195 Too in order to continue my work of PR#176 and make a new PR for a full-feature docker stack yaml file with support for Volumes, Configs, Secrets ... I would also add another stack file with the addition of Traefik if your interested. It could bring reverse proxying & load-balancing on the table, and most importantly automatic letsencrypt https certificates generation :) Just let me know.

[yukiisbored]

@pdemagny Most likely people already have traefik setup somewhere else or use another load balancer. Adding that just adds more confusion.

[pdemagny]

@yukiisbored It wouldn't add more confusion as it would be in a seperated yaml file, you'll still be free to use the basic yaml file. On the contrary i think that it would most certainly add possibilities for users to setup mattermost. In addition, it wouldn't stop people from contributing stack files with other load balancers included, once again to quickly provide mattermost users more ways to deploy.

[pdemagny]

I completely back to solution with multiple yaml sample files in the root directory as it is being done with #195 to give people freedom of choice. And i think the "default" one should be a compose 3.x file with volumes support (at least). Having a compose v2 file as default file doesn't really go with the flow ... and can confuse people. Multiple setup options is great, with default on the current docker verions/logic, and old versions/logic present for backward compatibility.

[pichouk]

About Traefik and other reverse-proxy/load-balancer/webserver example, I'm ok if there are people to maintain those files. This is an official Mattermost repository, so we need to maintain up-to-date code and documentation to deploy Mattermost using Docker.

@jasonblais Is that ok for you if we add multiple examples of way to deploy Mattermost using Docker ?

[pdemagny]

I could maintain the docker stack files :)

[fullgore]

well i could help maintain it as well with @pdemagny if he needs as it's a good addition and make sense to handle SSL with letsencrpt for instance.