Docker로 홈서버에 웹 서비스 배포하기 — DNS부터 HTTPS까지

부모님께서 자영업을 하시는데 배달 리뷰 관리를 내가 맡아서 도와드리고 있었다. 

우리 가게는 단골이 정말 많은데 리뷰를 보다 보니 문득 

"리뷰를 많이 남겨준 고객에게 작은 보상을 줄 수 있는 페이지를 하나 만들면 좋지 않을까?"

그런 생각이 들었다.

 

그래서 만든 게 ‘리뷰왕’ 페이지

처음엔 대충 AWS에 올릴 생각이었다

그런데 작업하다가 이전에 1주일 정도 걸린 홈서버 배포 경험이 생각이 났고 

기왕 만드는 김에 한 번 더 직접 굴러보고 깔끔하게 정리하자는 생각이 들어서 

이 프로젝트는 AWS 대신, 집에 있는 노트북을 서버로 사용하는 홈서버 프로젝트로 방향을 틀었다. 

 

 

전체 흐름도

도메인은 진짜지만 ip는 예시입니다.

 

-  사용자가 https://bbg-magok.shop 접속 -  DNS가 현재 공인 IP를 알려줌 -  HTTPS이므로 443 포트로 요청 -  공유기가 요청을 받아 NAT로 내부 서버에 전달 -  내부 서버의 nginx가 443 요청을 수신 -  nginx가 요청을 도커컨테이너로 프록시 -  컨테이너에서 실제 애플리케이션 응답

 

 

https://bbg-magok.shop

 

일단 배포한 사이트 먼저 ~

(디자인에는 조금 재능이 없어 이쁘진 않지만 홈서버가 내 메인 주제였다 조만간 고객의 소통 창구도 만들 예정이다)

 

이미 한 번 해본 작업이었지만,
이번에도 이틀이 걸렸다.
다만 이전과 달랐던 점은, 일주일씩 걸리던 작업을 이틀 안에 끝낼 수 있었고,
막히는 지점에서 원인을 훨씬 빠르게 좁힐 수 있었다는 점이다.

 

 

Docker를 사용한 이유

처음엔 그냥 집에서 쓰는 서버니까

파일 복사해서 실행해도 되지 않나 하는 생각도 했지만

1. 노드 버전 바뀌면? 2. 서버 환경이 바뀌면 ? 3. 나중에 서버를 옮기면 ? 4. 프로젝트 수정할 때 마다 파일 옮길 거야 ?

 

결국 서버를 관리하는 게 아니라 실행 환경을 버전으로 관리하고 싶은 마음이 컸다.

그래서 나는 다음과 같은 과정을 하게 된다.

 

홈서버 준비

1. 집에서 잠들어 있던 LG 노트북 (ubuntu 설치)

얼마 전 맥북을 물에 담군 일로 급히 집에 있는 LG를 사용 - 왼쪽이 홈서버용 노트북이다 !

2. 로컬에서 만들었던 이미지를 저장소에 push , 서버에서는 pull 후 run

3. 가비아에서 도메인 구매 

4. 구매한 도메인 ip에 DDNS 설정을 해줘야 한다.

 

 

 

도메인과 DDNS 왜 cloudflare를 선택했는가 

일단 DDNS란 IP 주소가 변경되어도 항상 동일한 도메인 이름으로 접속할 수 있게 해주는 서비스다.

가정용 홈서버는 공인 IP더라도 유동 IP이기 때문에 DDNS 설정을 해주지 않으면 매번

바뀐 IP를 도메인에 들어가서 연결 해줘야 한다. 

 

공유기에서도 DDNS를 제공하지만, 해당 DDNS는 공유기 제조사가 소유한 도메인의 서브도메인에 대해서만 동작한다.

mingde.iptime.org 같은 서브도메인을 준다

 

예를 들어 iptime DDNS는 iptime.org 하위 도메인만 관리할 수 있으며,
내가 직접 구매한 도메인에 대해서는
IP 변경 시 DNS 레코드를 수정할 권한이 없다.

 

반면 Cloudflare를 사용하면
내가 소유한 도메인의 네임서버를 위임받아
DNS 레코드를 직접 제어할 수 있고,
API를 통해 공인 IP 변경 시 A 레코드를 자동으로 갱신하는
DDNS를 직접 구현할 수 있다.

 

가비아는 DDNS API를 제공하지 않는다.

 

도메인을 구매한 건 가비아이기 때문에

가비아가 네임서버를 가지고 있는데, 이를  cloudflare의 네임서버로 변경해줘야 한다. 

즉, DNS 관리 권한을 가비아 -> cloudflare로 위임한 것이다. 

그로 인해 A레코드, IP변경, 인증서 발급용 DNS 기록 등을 모두 Cloudflare API로 제어할 수 있게 된거다. 

 

 

5. cloudflare의 인증서 발급 실행 

인증서 발급을 위해 nginx 설정을 먼저 시도했지만,,,
가정용 공유기 환경에서는 80 포트 포워딩이 제한되어
HTTP 기반 검증 방식은 사용할 수 없었다.

 

결국 DNS를 직접 제어할 수 있는 Cloudflare의
DNS 인증 방식을 선택했고, 이는 서버를 외부에 노출하지 않고도
도메인 소유권을 증명할 수 있는 구조였다.

 

특히  홈서버 환경에서는 필요한 포트만 열고, 검증 과정에서는 아예 열지 않는 것이
보안과 안정성 측면에서 훨씬 합리적인 선택이라고 느꼈다.

 

 

6. 포트포워딩 443만 설정, 내부 서버로 포트포워딩 설정

 

 

 

그리고 cloudflare로 인증서 만드는 과정에서 계속 1시간 내내 

9109 error가 나는 거다 

모든 사람들이 9109에러는 

 

1. api token이 아니라 global token 사용시

2. 권한 부족시 (read , write) 

3. 키네임 혹은 벨류 오류시 

 

3개밖에 없다고 하는데 모두가 정상이었던 나는 1시간 내내 삽질을 하다가 

O를 Q라고 쓴 걸 뒤늦게 발견했다 

(설정 하나, 문자 하나가 곧바로 장애로 이어질 수 있다는 걸 다시 한 번 체감했다... 안경을 쓰고 개발을 해야)

 

 

 

 

 

결론

사실 이 프로젝트는 AWS로 배포했으면 30분도 안 걸렸을 것이다.

트래픽도 거의 없고, 비용도 더 적게 들었을 가능성이 크다.

그럼에도 홈서버를 재선택 한 건 
네트워크, DNS, 인증서, 포트포워딩이 단순
설정값이 아니라 흐름으로 이해하고 싶었기 때문이다.

도메인 요청이 어떻게 공유기를 지나고, 
어떤 지점에서 HTTPS종료되며, 
왜 특정 포트만 열어야 하는지까지 
직접 겪어보면서 생긴 네트워크 이해도가 확실히 다르다고 느낀다. 

실제로 입사 초기에는 네트워크 이해 부족으로 원인을 찾지 못했던 문제들이 꽤 있었다.
홈서버 한 번 하고 난 뒤로는

- 로컬에서 도메인이 뜨지 않던 문제 (host 설정) - 포맷 후 DB 접속이 안 되던 문제 (IP 대역 불일치) - 톰캣이 뜨지 않던 문제 (프록시 설정) - HTTPS가 HTTP로 내려가 로그인되지 않던 문제 (인증서 만료)

이런 문제들의 원인을 아주 빠르게 추적할 수 있게 됐다.

홈서버는 번거롭고 비효율적일 수 있지만,
적어도 나에게는 네트워크를 설정이 아니라 구조로 이해하게 만들어준
가장 좋은 실습 환경이었다고 생각한다.