mattermost
Drop support for Web image ?
I am thinking of dropping support and remove the web image from this repository, but I really think this is a decision to be discussed, so please give me feedback on this (whether you agree or not).
Actually, I think that the Web image is not really useful since it is only a Nginx server with minimal configuration to be used as a reverse proxy. I'm pretty sure that a huge majority of users already have their own reverse-proxy inside their infrastructures, so they are not using Web image. And people who don't should really, IMHO, use an existing reverse-proxy (Traefik, Nginx, etc.) and customize their configuration instead of using the default one we provide.
So what are you thinking ? Should we stop providing a Web image (and instead explain in documentation how to use App with a reverse-proxy) ? Or should we keep this image and improve it (maybe by using another reverse-proxy, like Traefik) ?
I think having a default, small, "security-first" reverse proxy is a good thing… but more as an example and "how to get this up and running as secure and fast as possible" not as a solution for everybody
I propose using a Caddy-container, because it has pretty secure and sane TLS-Defaults and someone who wants a) more compatibility or b) more security has to know what they are doing anyway.
@pichouk What are the implications of dropping support for the web image? What harm is keeping the web image support?
@jasonblais Dropping support for Web image will force users that use this image (how much ? can't really know) to configure their own reverse-proxy/web server OR to expose directly the Mattermost application to the internet.
IMHO this is not something difficult if users have some basic system administration skills (which I hope they have since they host a Mattermost server), but we will need to warn them (it will not be transparent if they just git pull && docker-compose up).
The complicated task with maintaining the Web image is "choices". A reverse-proxy/web server is the "main door" to enter on someone's infrastructure so this is a sensitive and highly customized component. There is probably hundreds of possible reverse-proxy/web server and thousands of different configurations. Somes want specific features, others want light and generic image. Somes want security, others want compatibility. There are as much possible configurations as there are users. Because of this, it is really complicated to provide an image that will fit everyone's needs, and I guess that a lot of users don't use Web image for this reason (and use their own reverse-proxy).
Thanks for the context. What's typical for Docker images in this case? Do they usually support web image, but perhaps provide a recommended way to set it up?
I'm not sure that there is a typical way to handle this.I look at some other popular free softwares (eg. Etherpad, Rocket Chat, Mastodon) and they generally provide a docker image to deploy the application and few documentation to explain how to deploy behind a reverse-proxy
My opinion/proposal is the following.
I think we should continue to provide app AND db images, with a docker-compose.yml example file to use it. We (Mattermost, maintainers and community) should maintain those images and a deployment example. Plus we have to provide a quick, simple and generalist documentation on how to deploy behind a reverse proxy (port to use, websocket endpoint, etc.). Users will then be able to choose their reverse-proxy and configure themselves.
Eventually, we can also provide one or two example of deployment (on a contrib folder ?) if there is community members to maintain.
Great, thank you @pichouk. Would you like to post this proposal to the Docker channel as well, so people there see it too? It would be good to get an engineer (Christopher or Corey) review it and share feedback as well, if any.
Running Mattermost any of the common cloud providers would prob involve the provider native load balancers iso an nginx container?
Hello,
I have been running a docker instance of mattermost-preview for testing purposes and when I decided to install the production server I ran into multiple issues.
I wish there was a single server production docker as easy as docker run --name mattermost-preview -d --publish 8065:8065 mattermost/mattermost-preview and a vhost configuration.
I'm pro reverseproxy. This image works perfect out of the box and the nginx doesn't take much ressources away. I've never worked with Nginx but with Apache, HAProxy and misc firewalls with ReverseProxy support. It takes time to maintain to configure and adds another source of trouble. But it would be nice to start the container without the proxy too. Maybe giving the choice to use it with or without the proxy.
I think that a traefik container would fit really well in the current docker-compose setup. Especially because it gives uses a way to use letsencrypt (which is currently not possible/easily done with the current setup?).
Rocket.chat has something like this in their compose file: https://raw.githubusercontent.com/RocketChat/Rocket.Chat/develop/docker-compose.yml . I couldn't get it to work yet.
@cht47
This image works perfect out of the box
Not really. Plus the README lacks clarity if one isn't familiar with docker compose.
The preview docker image is much easier to run.
Please also consider deprecating the db image based on postgres:9.4. Custom configurations can be mounted directly into the upstream postgres images.
Furthermore, newer PostgreSQL versions are available and support for 9.4 ends in 2020.
Thanks @pichouk
I do not know what is the optimal approximation on these two options. But I am going to share my experience with Mattermos-docker. In the last two years I am using multiple instances with the web image. This image with the docker-compose has been very useful to me.
For me keep this image and improve it sounds interesting. I want to help with it. But if we chose other option I willing to learn and help to the best of my knowledge :)
