Skip to content
This repository has been archived by the owner on May 20, 2022. It is now read-only.

Drop support for Web image ? #245

Open
pichouk opened this issue Mar 11, 2018 · 13 comments
Open

Drop support for Web image ? #245

pichouk opened this issue Mar 11, 2018 · 13 comments
Labels

Comments

@pichouk
Copy link
Contributor

pichouk commented Mar 11, 2018

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) ?

@HorayNarea
Copy link

HorayNarea commented Mar 13, 2018

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.

@jasonblais
Copy link
Contributor

@pichouk What are the implications of dropping support for the web image? What harm is keeping the web image support?

@pichouk
Copy link
Contributor Author

pichouk commented Mar 16, 2018

@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).

@jasonblais
Copy link
Contributor

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?

@pichouk
Copy link
Contributor Author

pichouk commented Mar 20, 2018

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.

@jasonblais
Copy link
Contributor

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.

@aldegoeij
Copy link

Running Mattermost any of the common cloud providers would prob involve the provider native load balancers iso an nginx container?

@johnchristopher
Copy link

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.

@cht47
Copy link

cht47 commented Apr 23, 2018

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.

@peterrus
Copy link

peterrus commented Apr 25, 2018

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.

@johnchristopher
Copy link

@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.

@J0WI
Copy link

J0WI commented Apr 7, 2019

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.

@nvjacobo
Copy link
Contributor

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 :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

9 participants