시놀로지 Docker apt-get update 실패 — 호스트 네트워크 임시 해결법
결론부터 말하면, NAS Docker의 기본 네트워크 모드에서 컨테이너가 외부로 못 나가던 문제였습니다. 2021년 초, 이걸 몰라서 8시간을 헤맨 기록이 있습니다.
이 글은 그때 남긴 트러블슈팅 기록을 5년이 지난 지금 다시 꺼낸 회고입니다. 당시 임시방편으로 썼던 호스트 네트워크 모드가 왜 임시일 수밖에 없었는지를 함께 짚습니다. 정석 해결법은 이 글이 아니라 후속 포스트에 있습니다.
1. 시작은 ChromeDriver 자동화였습니다
시놀로지 NAS에서 어떤 자동화 작업을 돌리려고 ChromeDriver가 필요해졌습니다. 그런데 NAS에는 Chrome을 직접 설치할 수가 없더라고요.
그래서 Docker로 방향을 잡았습니다. NAS에 Docker 패키지를 설치하고, 그 위에 Ubuntu 컨테이너를 올린 다음, 컨테이너 안에서 Chrome과 ChromeDriver를 설치하는 구조입니다.
Ubuntu 이미지를 컨테이너에 올리는 것까지는 됐습니다. 문제는 그다음 단계에서 바로 막혔습니다.
apt-get update 명령어가 먹지를 않았습니다.
2. 막혔던 지점 — apt-get update 실패
컨테이너 안에 들어가 보니 말 그대로 깡통이었습니다. vi도 없고 nano도 없는 최소 구성의 Ubuntu 이미지였습니다. 뭔가 설치하려면 apt-get update가 먼저 통과해야 하는데, 계속 이 메시지가 반복됐습니다.
W: Some index files failed to download. They have been ignored, or old ones used instead.
처음엔 패키지 미러 서버 문제인 줄 알았습니다. 인덱스 파일을 받아오지 못한다는 메시지였으니까요. 그런데 지금 돌이켜 보면 이 에러의 본질은 패키지 미러가 아니라 컨테이너가 외부 네트워크를 전혀 볼 수 없는 상태였습니다. 패키지 서버로 요청 자체가 나가질 못하고 있었던 겁니다.
Docker는 기본적으로 컨테이너를 내부 가상 네트워크(bridge 모드)에 연결합니다. 이 상태에서 외부 인터넷으로 나가려면 NAS가 중간에서 라우팅을 처리해줘야 하는데, 당시 제 환경에서는 그 경로가 열려 있지 않았던 것으로 보입니다.
3. 임시 해결 — 호스트 네트워크 모드 체크
이것저것 손을 댔습니다. DNS 설정을 바꿔보고, 컨테이너를 내리고 다시 올려보기도 했지만 결과는 달라지지 않았습니다. 당시 제가 남긴 메모에도 이런 말이 있습니다.
“내부망에서 내부망끼리는 연결이 됩니다만 내부망에서 외부망으로 연결이 안 되가지고”
내부망에서 외부로 나가는 경로가 막혀 있다는 건 알고 있었지만, 어떻게 뚫어야 하는지가 문제였습니다.
그러다 찾은 게 DSM Docker 패키지의 네트워크 설정이었습니다.
Docker 패키지 → 이미지 → 실행 → 고급 설정 → 네트워크 → “Docker 호스트와 동일한 네트워크 사용” 체크
당시 기준 DSM 6.x UI입니다. DSM 7.x에서는 메뉴 위치가 다를 수 있습니다.
이 체크 한 번으로 apt-get update가 정상 통과됐습니다.
이 설정은 컨테이너가 NAS 자체의 네트워크 스택을 그대로 공유하는 방식입니다. 컨테이너 입장에서는 NAS와 같은 네트워크에 있는 것처럼 동작하게 되고, 그래서 외부 인터넷도 바로 나갈 수 있게 됩니다.
4. 그런데 이게 정답은 아니었습니다
해결은 됐지만 당시에도 찜찜했습니다. 글을 쓰면서 이렇게 적었습니다.
“원래 대로라면 docker 포트 따로 잡아서 따로 연결해야 하는 걸로 알고 있는데 말이죠..”
그 찜찜함은 근거 있는 감각이었습니다.
호스트 네트워크 모드는 컨테이너와 NAS가 네트워크를 공유하는 방식입니다. 컨테이너 안에서 어떤 서비스가 포트를 열면, 그 포트가 NAS 자체에서 사용하는 포트나 DSM이 점유하는 포트와 겹칠 수 있습니다. 그리고 컨테이너와 NAS 사이의 경계가 사실상 사라지기 때문에, 일반적으로 알려진 수준에서 격리가 약해지는 방향이기도 합니다.
홈 NAS 자동화 용도라면 당장 큰 문제가 되는 건 아닐 수 있습니다. 다만, “컨테이너를 격리해서 쓴다”는 Docker의 기본 목적에서 보면 한 발 물러난 선택입니다.
5. 정석 해결법 (포트 매핑): 별도 포스트로 정리해뒀습니다
이후 포트 매핑 방식으로 다시 설정한 내용을 따로 정리했습니다. 원본 글에도 이미 이렇게 안내해뒀습니다.
“수정 : 현재는 port 지정해서 아래 방식으로 설정하지 않습니다.”
포트 매핑 방식은 컨테이너와 NAS의 네트워크 경계를 유지하면서도, 필요한 포트만 명시적으로 열어 외부 통신을 가능하게 합니다. 호스트 네트워크처럼 스택 전체를 공유하는 대신, 컨테이너가 격리된 채로 외부와 연결될 수 있는 통로만 만드는 방식입니다.
Synology Docker 컨테이너를 제대로 운영할 계획이라면, 호스트 네트워크 모드보다는 포트를 명시적으로 지정하는 방식을 권장합니다.
6. 5년 뒤 회고 — 같은 자리에서 다시 본다면
지금이라면 저는 이 순서로 짚어봤을 것 같습니다:
- 컨테이너에서 외부로 통신이 되는가 — 외부 연결 가능 여부를 먼저 확인
- DNS 문제인가, 라우팅 문제인가 — 이름 풀이가 되는데 통신이 안 되는 건지, 아니면 경로 자체가 없는 건지를 구분
- NAS 단에서 막히고 있는 건 아닌가 — 방화벽 등 NAS 자체 설정 점검
- 호스트 네트워크 모드는 마지막 임시 우회로 — 정식 환경이 아닌, 일시적 확인 목적으로만
“이렇게 하면 됩니다”가 아니라, 지금이라면 저는 이 순서로 봤을 것 같다는 이야기입니다.
한눈에 보는 점검 순서
| 점검 순서 | 항목 | 이 사례에서의 결과 |
|---|---|---|
| 1 | 컨테이너 외부 접속 가능 여부 | 실패 (기본 bridge 모드) |
| 2 | DNS 응답 | 만져봤지만 미해결 |
| 3 | 호스트 네트워크 모드 체크 | 임시 해결 |
| 4 | 포트 매핑 방식 (정석) | 별도 포스트 87번 참조 |
“Docker를 좀 더 공부해봐야겠습니다”라고 글을 맺었던 그때가 생각납니다. 그 아쉬움이 출발점이 돼서 포트 매핑 방식으로 이어졌고, 결국 그때 못 풀었던 것들이 다음 글의 재료가 됐습니다.
이 글은 2021년 1월 작성된 원본 트러블슈팅 기록을 현재 시점에서 회고·보완한 글입니다.