Remove container_names from docker-compose.yml

[topelrapha]

Summary

In environments with multiple instances on one server there are nameconflicts by setting container names in docker-compose.yml. Is there any reason why they are hardcoded?
If not it would be great to remove the container_names from docker-compose.yml by accepting this PR.

[topelrapha]

Ping

[almereyda]

I agree this is a useful change that improves container handling accross application deployments.

This will ease configurations, in which all multiples of Mattermost and Database containers are created on the default bridge network, as currently (un-)defined in the configuration examples without explicit networks.

Even if those could be deployed alongside, which is prohibited by a sanity check of the container_names at creation time, a reverse proxy would only be able to route round robin between the multiple individual, differently configured Mattermost web services. Additionally, in that impossible case, they also wouldn't be able to distinguish between their database counterparts, and jump between them undeterministically.

Does it also seem advisable to change this in the other occurence of container_name in this repository?

• https://github.com/mattermost/docker/search?q=container_name:
  /docker-compose.nginx.yml

My intuition would be, to also add networks directives for both Compose files to this PR, and change its title to something like: Improve container service discovery. But I'm not a maintainer here, and leave this for others to decide.

In the current configuration, master kind of assumes no presence of a dedicated web network for a reverse proxy, where no frontend TLS termination can be provided to deployed applications, which is less than common.

[spirosoik]

👀