Custom docker network configuration - container to container comms

I am installing Docker on a host where all applications are already containerised including the main smtp server.

When I try and relay mail from discourse to this smtp server it fails because the server cannot do a reverse lookup on the Discourse server IP. This works fine with my other containers because using docker compose I am allowing access to the mail server docker network using for example something like

            - mail_server

      external: true

How can I achieve this with Discourse so that Discourse service container and the mail server service container can communicate with each other directly?

We don’t use Docker compose (in any of the many forms it has taken over the years), so we’re not going to be able to translate an isolated snippet of its config into anything useful. What are you actually trying to achieve, in general terms? rDNS isn’t usually Docker’s concern, and it’s weird that you’ve got your SMTP server configured to do rDNS lookups on local submission anyway.

1 Like

Ok, I will simplify the question.

Docker container_a with a service configured to use Docker network_a needs to talk to container_b (discourse) using the internal Docker network. With docker compose I would simply add network_a to the networks configured for the service in container_b and set it as external.

I could reconfigure and rebuild my mail server but this is working configured as above for all my other docker container services I would rather have it working the same way for Discourse.

What docker command line would you run to make what you want to have happen, happen?

None, I use docker-compose and the yml config example posted in the original question.

I have tried using network args with launcher but this did not work

./launcher start my_forum --docker-args "–network mail_server"

Note the hypothetical implied by the use of the word “would” in my question. I’m not asking what docker command line you do run, I’m asking what you would run, were you to eschew the use of docker-compose and instead implement the same configuration without it. It should be at least theoretically possible to ask docker-compose to tell you would it would do, because it just invokes docker run behind the scenes anyway, but I doubt sufficient user-friendliness has been built-in. Alternately, you can usually reverse-engineer a command line out of the docker inspect output of a correctly configured container.


OK Matt, thanks for your help. I will eventually figure it out for myself and update this topic with the answer for any other poor unfortunate souls seeking support like myself :slight_smile:

Does docker network connect mail_server [discourse_container_id] work?

Obviously not ideal because it’ll need to be done again after each bootstrap, but should work until you have a full solution.

1 Like

Just tried that Cameron, and yes it works. I think the syntax in my launcher args could be wrong, I am just checking it now.

Trying to add the network via the launcher args doesn’t seem to work at all.

Manually connecting the network with network connect works but doesn’t register the host name of the discourse service with dockers name resolution system so the mail server hostname lookup (ping my_forum) fails. So I am back to square one - annoying that a simple docker network config is proving so tricky with discourse.

Does it work if you pass --alias my_forum to the network connect command?

I just found this too:

(I’ll be trying to get my Discourse instance onto an internal network soon, so I’m interested to see what you get working)

I saw that post, but I can’t get the networks to connect with the launcher network args option.

I am giving up for now, it looks like it’s going to be far easier to change my mail server setup…

After returning to the mail logs I noticed that the email host lookup failure generated a WARNING not an error. Looking at the discourse production logs I saw that discourse was complaining about the mail server certificate

Job exception: hostname “xxx” does not match the server certificate

Setting DISCOURSE_SMTP_ENABLE_START_TLS to false resolved the problem and mail is being delivered.

1 Like