[Docker] docker-compose 없이 Container Manager로 nginx 붙이기

배경

앞 글(DEBUG=False의 함정)에서 다룬 미디어 파일 문제를 nginx로 해결하기로 했다. 문제는 이 프로젝트가 Dockerfile/docker-compose.yml 없이 Synology Container Manager UI로 컨테이너를 수동 생성/관리하는 구조라는 것 — nginx를 붙이는 절차도 그에 맞춰야 했다.

nginx 설정 파일 준비

server {
    listen 80;
    server_name _;
    client_max_body_size 20M;

    location /static/ {
        alias /app/staticfiles/;
    }
    location /media/ {
        alias /app/media/;
    }
    location / {
        proxy_pass http://<django-컨테이너>:8001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

볼륨 마운트 3개로 Container Manager에서 연결한다.

1. 이 설정 파일 → /etc/nginx/conf.d/default.conf
2. 정적 파일 폴더(collectstatic 결과물) → /app/staticfiles
3. 미디어 파일 폴더 → /app/media

배포 순서가 꼬였던 부분

처음엔 이 nginx 설정 파일을 git 저장소 안에 만들어뒀는데, 곰곰이 생각해보니 순서가 이상했다 — Container Manager는 NAS 파일시스템만 보기 때문에, git 저장소(로컬 PC)에만 있는 파일은 볼륨 마운트 대상이 될 수 없다. 그리고 애초에 nginx 설정은 Django 앱 코드가 아니라 별도 컨테이너의 인프라 설정이라, 이걸 위해 git 배포 파이프라인(push → CI → 운영 반영)을 거칠 이유도 없었다.

정리: nginx 설정 파일은 git 저장소 밖, NAS의 별도 폴더에 직접 만들어서 그 경로로 볼륨 마운트했다. 로컬 저장소에는 참고용 사본만 남겨두는 정도로 충분했다.

proxy_pass엔 컨테이너 이름이 아니라 실제 접속 가능한 주소가 필요

nginx 설정의 proxy_pass http://<컨테이너이름>:8001;은 두 컨테이너가 같은 Docker 네트워크에 있을 때만 컨테이너 이름으로 서로를 찾을 수 있다. 그런데 기존 Django 컨테이너는 Synology 기본 브릿지 네트워크를 쓰고 있었고, 이 기본 브릿지에서는 컨테이너 이름으로 서로를 찾을 수 없다 (DB 연결은 별도의 레거시 "Link" 기능으로 되어 있었다).

두 가지 선택지가 있었다.

1. NAS의 LAN IP + 열려있는 포트로 직접 연결 — Django 컨테이너를 전혀 안 건드려도 되는 간단한 방법
2. 커스텀 브릿지 네트워크를 새로 만들어서 관련 컨테이너를 다 그 안에 넣기 — 더 깔끔하지만 기존 컨테이너들을 재생성해야 함

마침 "안정화 단계라 컨테이너를 다시 만들어도 괜찮다"는 상황이라 2번(커스텀 네트워크)으로 진행했다.

참고: Docker 커스텀 브릿지 네트워크는 시놀로지 제어판의 네트워크 설정과는 무관하다. Container Manager 앱 안의 Network 탭에서 별도로 만드는 것.

이 네트워크 전환 과정에서 겪은 DB 연결 사고는 별도 글(네트워크 통합하다가 DB가 끊긴 사고)에서 다뤘다.

마지막 장애물 — 80번 포트는 이미 쓰이고 있었다

nginx 컨테이너의 호스트 포트를 80으로 설정하려니 충돌이 났다. Synology DSM 자체가 기본적으로 80번 포트를 쓰고 있어서(DSM 웹 관리 페이지 등), NAS에서는 80/443을 컨테이너에 그대로 열어주기 어려운 경우가 흔하다.

해결: nginx는 호스트 포트 8080으로 띄우고, DSM의 리버스 프록시 규칙에서 Destination(목적지) 포트만 기존 Django 포트에서 nginx 포트(8080)로 바꿨다.

• Source(외부에서 들어오는 쪽, 보통 443/HTTPS)는 그대로 둔다 — SSL 처리는 DSM이 계속 담당
• Destination(내부로 전달하는 쪽)만 nginx가 열려있는 포트로 바꾼다

Django 컨테이너의 기존 포트(8001)를 nginx가 그대로 가져가는 방법도 있었지만(그러려면 Django 컨테이너를 다시 재생성해야 함), 이미 DB 문제를 한 번 겪은 뒤라 운영 컨테이너를 또 건드리는 리스크를 피하고 더 안전한 쪽(nginx만 새 포트로, 리버스 프록시 설정만 한 줄 수정)을 택했다.

정리

• 인프라 설정 파일(nginx.conf 등)은 앱 코드 배포 파이프라인과 분리해서, 그 설정을 실제로 쓰는 곳(여기서는 NAS 파일시스템)에 직접 둔다
• proxy_pass에 컨테이너 이름을 쓰려면 두 컨테이너가 같은 Docker 네트워크에 있어야 한다 — 아니면 IP로 직접 연결하거나, 네트워크를 통합해야 한다
• NAS 환경에서는 80/443 포트가 이미 관리 UI에 쓰이고 있을 수 있으니, 컨테이너는 다른 포트로 띄우고 리버스 프록시의 목적지 포트만 바꾸는 게 기존 컨테이너를 안 건드리는 안전한 방법이다