안녕하세요,
저는 Discourse를 처음 사용해 보는데, 설치 과정에서 막혀 있습니다. Ubuntu Server 18.04 가상 머신을 구축한 후, 설치 설명서를 대략적으로 따랐습니다.
'대략적으로’라는 말은 클라우드 서버 대신 Ubuntu Server를 사용했다는 뜻입니다. Docker를 직접 설치하지 않고 discourse-setup가 설치하도록 했습니다. 또한, 아직 메일 서버를 설정하지는 않았지만, 설정 과정에서 합리적인 답변을 제공했습니다. 이것이 문제의 원인인지 확실하지는 않습니다. DNS는 모두 설정되어 있고 서버에는 정적 IP 주소가 할당되어 있습니다.
부트스트래핑이 완료된 후 서버의 FQDN으로 접속하면 “Congratulations, you installed Discourse!” 페이지 대신 “Welcome to nginx!” 페이지가 표시됩니다.
이 설치 작업은 실험 환경용으로 진행되며, 외부에서 공개적으로 접근할 수 없도록 할 예정입니다.
Marc.
서버에 nginx가 설치되어 있나요? 설치되어서는 안 됩니다. 하지만 discourse-setup가 이를 감지했어야 합니다. DNS가 올바르게 설정되어 있는지 확인해 보셨나요?
서버에 Nginx가 설치되어 있지 않습니다. DNS의 경우, 서버에 A 레코드와 PTR 레코드가 있습니다. 다른 요구 사항은 무엇인가요?
마크
해당 페이지를 볼 수 있는 유일한 경우는 DNS가 잘못된 서버로 지정되어 있거나, NGINX가 컨테이너 외부에 위치하여 포트 80을 점유하고 컨테이너의 응답을 방해하고 있을 때입니다.
웹 브라우저를 서버의 IP 주소로 직접 지정하면 Nginx 환영 페이지가 표시됩니다.
Ubuntu 서버에 SSH로 접속한 경우:
marc@community:~$ locate nginx
/var/discourse/image/base/install-nginx
marc@community:~$
또한 Ubuntu 서버에서:
sudo find / -iname "*nginx*"
…/var/lib/docker/overlay2 아래에 많은 파일들…
/var/discourse/image/base/install-nginx
/var/discourse/shared/standalone/letsencrypt/deploy/nginx.sh
/var/discourse/shared/standalone/log/var-log/nginx
다음 명령의 결과를 보여주세요:
lsof -i:80
명령어 lsof -i:80은 출력을 생성하지 않습니다.
그렇다면 포트 80에서 아무것도 리스닝하지 않는다는 뜻인가요?
Docker가 :80에서 리스닝 중이었다면(성공적인 설치에서는 이를 달성해야 하며, 컨테이너 내부의 nginx가 트래픽을 수신하려면 필수적입니다) 다음과 같은 내용이 표시되었을 것입니다:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
docker-pr 890 root 4u IPv6 961922 0t0 TCP *:http (LISTEN)
컨테이너 외부에 nginx가 설치되어 있지 않고 Docker가 해당 포트에서 리스닝하지 않는다면, nginx 환영 페이지를 볼 수 있는 유일한 다른 이유는 네트워크 설정 오류일 것입니다.
말씀하신 대로인 것 같습니다. 내 랩톱에서 서버 IP 주소를 대상으로 nmap을 실행한 출력 결과는 다음과 같습니다:
Starting Nmap 7.01 ( https://nmap.org ) at 2020-04-10 23:34 AEST
Nmap scan report for community.aureus-group-sb.com (192.168.12.35)
Host is up (0.0010s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
MAC Address: 0C:8B:FD:CD:AF:EB (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds
네트워크 문제는 다음을 포함할 수 있지만, 이에 국한되지는 않습니다:
위 항목 중 어느 것도 해당되지 않을 때만 Discourse 문제입니다. 표준 설치 절차를 따르고 있지만, 스스로 인정하듯 전혀 표준이 아닌 환경에서 설치하고 있습니다.
조직에서 월 $5를 지출할 수 있다면, 클라우드에 배포하고 클라우드 VPS 방화벽을 자체 환경으로만 페이지를 반환하도록 제한하는 것이 시간 측면에서 더 저렴할 수 있습니다.
현재 저는 이 설정을 구축하는 과정에서 학습할 수 있는 측면에 주로 집중하고 있습니다. 이 부분을 안정적으로 관리하게 되면, 호스팅 옵션을 반드시 검토할 것입니다.
나열하신 네트워크 관련 사항들을 살펴보면,
VM와 외부 세계 사이에 어떤 네트워크 정책이 존재합니까?
git pull이 성공했고 discourse-setup를 실행할 수 있었다면, 컨테이너의 콘텐츠를 다운로드하기 위해 GitHub에 연결하는 것을 막는 요인이 있었을까요?
서버가 접근 가능한 주소로 지정되지 않으면 Let’s Encrypt가 실패하므로, YML 파일을 수정하여 HTTPS를 비활성화했습니까?
VM은 인터넷에 연결되어 있으며 GitHub에 대한 접근 제한은 없습니다. discourse-setup을 실행할 때 Let’s Encrypt 계정 이메일? (ENTER를 누르면 건너뜁니다) [me@example.com]: 항목을 비워 두었습니다.
YML 파일을 수정하지 않았습니다.
해당 필드를 비워 두면 인증서 문제와 관련하여 알림을 받지 않게 되지만, 컨테이너가 Let’s Encrypt를 활성화하려는 시도를 막지는 않습니다.
자, 이제 몇 가지 더 큰 문제를 짚어 보았지만, 이는 OP(원문 게시자)와 직접적인 관련이 없습니다. 네트워크 어딘가에 nginx가 설치되어 있어 해당 페이지를 표시하고 있는데, 가상 머신에서 테스트해 본 결과 nginx가 설치되어 있지 않고 docker가 리스닝 상태도 아닙니다.
이것이 어떻게 발생하는지 파악한 후, 두 번째 단계는 YML 파일을 올바르게 구성하는 것입니다. 당장은 해당 페이지의 원인을 찾아야 합니다.
나도 같은 생각을 했어. 그 페이지가 어디서 오는 건지 알아볼게.
다음은 제가 파악한 내용입니다. 서버를 종료하면 해당 서버에 ping을 보낼 수 없습니다(IP 주소, 이름, FQDN 모두). IP 주소로 브라우저에서 접속을 시도하면 Firefox의 표준 “연결할 수 없음” 페이지가 표시됩니다.
따라서 IP 주소 충돌이 아니라고 결론을 내렸습니다.
VM을 다시 켠 후에도 이제 브라우저로 접속할 수 없으며, 다시 표준 “연결할 수 없음” 페이지가 표시됩니다. 현재 동작은 lsof -i:80 출력에서 예상했던 내용과 일치합니다.
docker exec -it <cont.id> /bin/bash 명령을 통해 컨테이너 내부에 들어가서 ps aux의 출력을 확인했습니다. 그 안에는 다음 줄이 있었습니다:
root 2030 0.2 0.0 2160 1328 ? Ss 14:10 0:01 runsv nginx
따라서 nginx가 컨테이너 내부에서 실행되고 있는 것으로 보이지만, nsenter -t 1446 -n netstat -plnt의 출력은 다음과 같습니다:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 3606/unicorn master
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 3590/postmaster
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 3591/redis-server *
tcp6 0 0 :::5432 :::* LISTEN 3590/postmaster
tcp6 0 0 :::6379 :::* LISTEN 3591/redis-server *
이것은 컨테이너가 포트 80과 443에서 리스닝하지 않고 있다는 것을 의미합니까?