Deploy with Docker on Digital ocean - enabling https

Description

I’ve been running rocket.chat for several years now for a small hobby project. Until now I had it manually installed on Ubuntu, but got tired of the maintenance. So my plan is to get a “minimal feasible” installation of rocket.chat running on Digital ocean and migrate my data.

So I got the pre-loaded “1-click-install” image from DO, restored my MongoDB, set my .env.

I could log in using http://<domain>:3000 and everything was working splendidly until I tried getting https set up using this official guide.

I’m using the provided compose.yml and traefik.yml with no changes. I only added my domain etc. in the .env (see below).

Getting the certificate did work, but now all I’m getting is a gateway timeout at https

I have a feeling that guide is missing something crucial. i.e. at what point do we decide to route traffic to rocket.chat port 3000? In every step before you need to use http://<domain>:3000 so why should https://<domain> suddenly work? I can’t find anything in the traefik.yml that could explain this.

This is my first time doing anything with docker and traefik, so I’m a bit lost. I do find some ready made .yml -files online that claim to work, but I’d rather understand what I’m missing instead of just blindly copy-pasting stuff that I do not understand…

I would really appreciate some help, thanks!

Server Setup Information

  • Version of Rocket.Chat Server: 6.12.0
  • Operating System: Ubuntu 20:04
  • Deployment Method: Docker on DO
  • Number of Running Instances: 1
  • DB Replicaset Oplog: not relevant
  • NodeJS Version: not relevant
  • MongoDB Version: not relevant
  • Proxy: Traefik
  • Firewalls involved: Not that I know of

Any additional Information

.env

   RELEASE=6.12.0
   BIND_IP=127.0.0.1
   ROOT_URL=https://<my domain>
   DOMAIN=<mydomain without a prefix or trailing slashes>
   LETSENCRYPT_EMAIL=<my E-Mail>
CONTAINER ID   IMAGE                                                COMMAND                  CREATED          STATUS             PORTS                                                                      NAMES
f44fd92d779f   registry.rocket.chat/rocketchat/rocket.chat:6.12.0   "docker-entrypoint.s…"   18 seconds ago   Up 17 seconds      127.0.0.1:3000->3000/tcp                                                   root-rocketchat-1
0352972ce45f   traefik:v2.9.8                                       "/entrypoint.sh --ap…"   2 hours ago      Up 2 hours         0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   rocketchat-traefik-1
4257fd77397c   bitnami/mongodb:5.0                                  "/opt/bitnami/script…"   2 hours ago      Up About an hour   27017/tcp                                                                  root-mongodb-1

So, thanks to ChatGPT, I got it working. It suggested changing the BIND_IP to 0.0.0.0 (EDIT: which wasn’t the problem) and making sure everything is in the same network by manually adding the networks to the compose.yml

Works like a charm!

“Beware false prophets” or some such. Or this will turn into an XY Info problem.

Don’t use ChatGPT to try and make up for your own lack of knowledge.

This is a really bad idea but ChatGPT is probably too stupid to tell you why… You essentially let Rocket listen on any IP which you do not want to do - that’s the job of the reverse proxy.

So you just potentially opened your Rocket to any old hacker bypassing the reverse proxy and getting to you on http.

Traefik should be listening on the general interface and then reverse any specific traffic back to Rocket.

What ChatGPT has shown you is that you have an issue with the networking within the containers or Ubuntu that you need to fix.

I suggest you undo the damage for starters and look at your logs as per the docs.

I’m with you on that one!

I re-read my message: I didn’t meant to say, that the BIND_IP solved my problem. That’s was just the first suggestion. The second suggestion was to check if the containers are in the same network (they weren’t).

So it was a networking issue within/between the containers. The traefik container was in a different network. I confirmed that by manually disconnecting and connecting it to the correct network. That was the solution.

Then I went through the .yml, defined the network there and made sure everything connects to it (without copy-paste from ChatGPT – it’s suggestions would’ve broken everything).

But: ChatGPT helped my find out what the issue was faster then my manual RTFM ever would!