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.
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?
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.
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.
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!
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…
VM 생성 후 discourse-setup를 호출한 뒤, 프로세스를 중단하지 않았습니다. 그래서 모든 작업이 한 번에 실행되었습니다.
처음에는 스왑 공간이 없다는 것을 깨달았고, discourse-setup 스크립트가 없으면 자동으로 설정해 주지만, 확인을 위해 셸로 나갔습니다. 그러자 기본 가이드와 달리 설치 프롬프트가 다르게 표시되어, 한 번 더 나갔습니다.
+ 당황스러웠던 점은 Let’s Encrypt 관련 항목으로, 알림을 받을 이메일 주소를 요구했는데, 처음에는 HTTPS를 수동으로 설정해야 한다고 생각했습니다. 실제로는 스크립트가 Let’s Encrypt SSL 인증서로 Discourse 인스턴스를 설정해 줍니다. + 또 다른 사항은 SMTP 사용자 이름과 비밀번호 입력 부분이었습니다. 이 항목들을 비워 두어도 되는지 여전히 확신이 서지 않지만, 관리자 이메일 주소와 해당 계정의 비밀번호를 입력했습니다.
이것이 문제의 원인이었다고 생각하지는 않지만, 혹시 모르니 언급합니다. 두 번째 시도에서는 처음과 동일한 방식으로 모든 작업을 진행하되, (1) 스왑을 수동으로 설정하고, (2) discourse-setup를 중단 없이 실행하게 한 것만 달랐습니다.
첫 번째 인스턴스를 구할 수도 있었겠지만, Discourse의 아키텍처는 여전히 저에게 미스터리이며, HTTP/HTTPS 엔드포인트를 어떻게 재시작해야 하는지 확신이 서지 않습니다. netstat -tulpn 출력을 비교해 보면, 첫 번째 인스턴스에서는 모든 관련 서비스가 실행 중이고 올바른 포트(예: PostgreSQL은 5432, Redis는 6379 등)에서 리스닝하는 것으로 보이지만, 누락된 항목은 80번과 443번 포트 두 개뿐입니다(nginx가 실행되지 않았음을 시사합니다):
1차 (실패한) 인스턴스:
$ 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 -
두 번째 인스턴스:
(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 -
나중에 참고할 메모 몇 가지:
처음에는 80번과 443번 리스닝 포트가 없다는 것을 눈치챘지만, 127.0.0.1:3000 소켓(기본 Rails 포트라고 기억하고 있었습니다)을 확인했습니다. 그때는 아직 nginx가 실행되지 않았을 수도 있다는 생각이 들지 않았고, 어떤 이유에서인지 여전히 Docker 포트 매핑이 원인이라고 의심하여 netcat으로 기본적인 리다이렉트를 수행했습니다:
Docker 내부: nc -l -p 80 -c "nc 127.0.0.1 3000"
Docker 외부(VM 내부): nc -zv localhost 80 및 curl localhost:80 (이로써 Docker에 문제가 없음을 확인했습니다)
또한 nc -zv가 계속 Connection refused를 반환했기 때문에 Azure 인바운드 포트 규칙이 의심스러웠지만, 이는 포트는 열려 있지만 반대편에서 리스닝하는 프로세스가 없다는 의미일 뿐이라는 것을 나중에 깨달았습니다. (포트가 차단되어 있었다면 nc가 단순히 멈춰 있었을 것입니다.)