Discourse installation on Azure not reachable

I created a new Ubuntu 14.04 VM on Microsoft Azure and installed Discourse using the guide here: https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md

The entire installation went perfectly, but the instance is not reachable publicly. I have the A record configured to the public IP given by Azure. I also tried using the IP address directly.

I suspect this has something to do with the Docker IP and the Eth0 IP address, but not sure how to solve it.

# ifconfig
docker0   Link encap:Ethernet  HWaddr 02:42:4c:29:e0:92  
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:4cff:fe29:e092/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6144 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21683 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:414603 (414.6 KB)  TX bytes:30771613 (30.7 MB)

eth0      Link encap:Ethernet  HWaddr 00:0d:3a:00:15:21  
          inet addr:10.0.0.4  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20d:3aff:fe00:1521/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1079091 errors:0 dropped:0 overruns:0 frame:0
          TX packets:634212 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1254465906 (1.2 GB)  TX bytes:318586926 (318.5 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:7245 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7245 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:986455 (986.4 KB)  TX bytes:986455 (986.4 KB)

vethcb56e42 Link encap:Ethernet  HWaddr 6a:43:07:bb:63:3f  
          inet6 addr: fe80::6843:7ff:febb:633f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2717 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2896 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:225111 (225.1 KB)  TX bytes:3277314 (3.2 MB)

So essentially I have 3 IPs: the public IP, the eth0 IP on the VPN, and then the docker instance IP. I’m guessing I need to somehow route the public IP:80 port to the docker IP?

Please help. Thank you.

1 Like

Currently we do not officially support Discourse installation on Microsoft Azure. We recommend using DigitalOcean.

Supporting Discourse installation on Microsoft Azure is on my to-do list and I plan to make a how-to guide for same by the end of January 2016.

Provided Docker installed correctly, I am unclear why the current guide would not work…

Crazy cloud shenanigans likely get in the way – there’s probably some equivalent of AWS’ security groups, or perhaps the networking stack needs an extra kick in the pants.

3 Likes

So I sort of found the problem, but not the cure. As expected it has to do with the port forwarding/mapping/routing issue.

Azure VMs are part of a resource group with a common virtual public IP and a VPN/subnet for individual machines. Then there is a Network Security Group, with which one has to define some NAT rules.

I did setup forwarding for the Docker ports, but to no avail. Now trying to diagnose using Docker documentation. Jeff is right, once Docker works correctly, Discourse will work too.

The Azure classic VM should be better because they allow mapping of specific endpoints (ports). Will try installing in one of those.

Will post my updates. For better or for worse, I’m stuck with Azure at the moment.

5 Likes

Ok. So I discarded the instance of Ubuntu and created a new Ubuntu VM of the classic type. Then I chose a fixed Instance IP address. Then I created two endpoints for TCP/80 and TCP/443 to forward from the public to private network. Also I installed Docker from the instructions for Ubuntu and not the script directly.

I’m not sure which of these steps helped, but now Discourse works on Azure!

Thank you all!

9 Likes

Hi there!

Resetting my discourse installation on azure, I cannot reach it anymore!

It was working before, but by now, it doesn’t! I map the public ports to the vm and inside the vm to the docker installation. It all worked before.

Any idea where to start over? Where to check, what is up and running? Docker is running (according to pgrep).

Any help appreciated!
Bernd

I finally switched to digital ocean, where it works out of the box. The VM classic type seems not to be available anymore at Azure? Tried to setup an instance without success…

Regards,
Bernd

Hate to bump this topic, but it is still relevant. Everything installs beautifully Discourse-wise, all seems fine, but ports 80 and 443 are publicly unreachable.


update: The basic install does work out of the box on Azure on Ubuntu Server.

These are what I did differently the second time around:

  1. After VM creation and calling discourse-setup, I didn’t interrupt the process, so everything was run in one go.

    The first time I realized I had no swap, and even though the discourse-setup script sets it up if missing, I exited to shell to check stuff. Then some of install prompts were different than in the basic guide, so exited one more time.

    + What baffled me was the Let’s Encrypt one, asking for an email address to receive notifications regarding it, and was under the impression that I would have to set up HTTPS manually. In reality, the script sets up the Discourse instance with a Let’s Encrypt SSL certificate.
    + Another thing was the SMTP user name and password sections; still not sure if I could’ve just left these blank, but I just added the admin email address and the password for that account.

  2. Set up swap space manually according to this meta.discourse thread.

    I don’t think this had anything to do with it, but mentioning it just in case. The second time, I did everything the way I did in the first, except (1) set up swap manually, and (2) let discourse-setup run without interruptions.

It is possible that the first instance could have been saved but Discourse’s architecture is still a mystery to me, and not sure how to restart HTTP/HTTPS endpoints. When comparing netstat -tulpn outputs, it is clear that in the first instance, all the relevant services seem to run and listen on the right ports (e.g., PostgreSQL on 5432, Redis on 6379, etc.) and the only 2 entries missing are the 80 and 443 ports (suggesting that nginx wasn’t running):

1st (failed) instance:

$ sudo -s

# docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED        STATUS        PORTS                                                                      NAMES
62396a99737c   local_discourse/app   "/sbin/boot"   14 hours ago   Up 14 hours   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   app

# docker exec -it 62396a99737c bash

(docker)# netstat -tulpn
Active Internet connections (only servers)
Proto Local Address  Foreign Address State   PID/Program name
tcp   127.0.0.1:3000 0.0.0.0:*       LISTEN  -
tcp   0.0.0.0:5432   0.0.0.0:*       LISTEN  -
tcp   0.0.0.0:6379   0.0.0.0:*       LISTEN  -
tcp6  :::5432        :::*            LISTEN  -
tcp6  :::6379        :::*            LISTEN  -

Second instance:

(docker)# netstat -tulpn
Active Internet connections (only servers)
Proto Local Address  Foreign Address  State   PID/Program name
tcp   0.0.0.0:6379   0.0.0.0:*        LISTEN  -
tcp   0.0.0.0:80     0.0.0.0:*        LISTEN  2359/nginx: master
tcp   127.0.0.1:3000 0.0.0.0:*        LISTEN  -
tcp   0.0.0.0:5432   0.0.0.0:*        LISTEN  -
tcp   0.0.0.0:443    0.0.0.0:*        LISTEN  2359/nginx: master
tcp6  :::6379        :::*             LISTEN  -
tcp6  :::5432        :::*             LISTEN  -

Couple notes for future self:

  1. The first time around, I noticed the lack of 80 and 443 listener ports, but saw the 127.0.0.1:3000 socket (which I remembered to be the default Rails one). It didn’t dawn on me yet that maybe nginx wasn’t running, and for some reason I still suspected Docker port mappings to be the culprit, so I did a basic redirect with netcat:

    Inside Docker: nc -l -p 80 -c "nc 127.0.0.1 3000"
    Outside Docker in the VM: nc -zv localhost 80 and curl localhost:80 (this settled it that Docker was ok)

  2. I also thought the Azure inbound port rules to be suspect, because nc -zv kept returning Connection refused, but then realized that this only means that the ports are open but no one is listening on the other side. (If the ports would be blocking, than nc would just hang.)

1 Like

discourse-setup should fail if you don’t have ports 80 and 443 open to inbound traffic.

Ah. That’s true. Some of the questions about email configuration were changed a while back and not changed in the guide. I think most people read the prompts and not the install document, so no one else has complained.

Why did you think that? The install process has automatically set up let’s encrypt for years.

I can’t tell if you’re saying that your site is working or not working.

If it’s not working, it’s a good bet that you ran discourse-setup a bunch of times and used up your rate limit at letsencrypt.org.

2 Likes

Here’s a PR to make install cloud be the same as discourse-setup: update INSTALL-cloud for discourse-setup by pfaffman · Pull Request #14065 · discourse/discourse · GitHub

2 Likes