시놀로지 NAS Docker apt-get update 실패 — 호스트 네트워크 모드 임시 해결과 그 한계
시놀로지 NAS Docker apt-get update 실패 — 호스트 네트워크 모드 임시 해결과 그 한계
결론부터 말씀드리겠습니다. NAS Docker의 기본 네트워크 설정에서 컨테이너가 외부로 나가지 못하는 문제였습니다.
이 글은 2021년 1월에 직접 겪은 트러블슈팅 기록을 5년이 지난 지금 다시 꺼낸 회고입니다. 당시 저는 “8시간은 헛짓한거 같네요”라는 자조 섞인 한 줄을 남기고 임시 해결에서 멈췄는데, 지금 다시 보니 그 임시 방편이 왜 임시였는지, 그리고 정석 방향은 어디였는지가 더 선명하게 보입니다. 에러 해결 방법뿐 아니라 그 임시 방편의 한계까지 같이 정리합니다.
1. 시작은 ChromeDriver 자동화였습니다
브라우저 자동화 작업을 돌리려고 ChromeDriver가 필요해졌습니다. 그런데 시놀로지 NAS에서는 Chrome을 직접 설치할 방법이 없더라고요.
그래서 잡은 구조가, Docker 컨테이너에 Ubuntu를 올리고 그 안에서 Chrome과 ChromeDriver를 설치하는 방식이었습니다. NAS에 Docker 패키지를 설치하고, Ubuntu 이미지를 컨테이너에 올리는 것까지는 어렵지 않게 됐습니다.
문제는 그 다음 단계에서 바로 막혔습니다. apt-get update 명령어가 먹지를 않았습니다.
2. 막혔던 지점 — Docker 컨테이너의 apt-get update 실패
컨테이너 안(docker exec으로 bash 접속)을 들여다보니 말 그대로 깡통이었습니다. vi도 없고 nano도 없는 최소 구성, 원문 표현대로 “깡에 깡통 ubuntu”였습니다. 뭔가 설치하려면 apt-get update가 먼저 통과해야 하는데, 계속 이 메시지가 떴습니다.
W: Some index files failed to download. They have been ignored, or old ones used instead.
처음에는 패키지 미러 서버 문제인 줄 알았습니다. 그런데 한참 검색하고 이것저것 시도해보다 뒤늦게 깨달은 건, 이것이 패키지 서버 자체의 문제가 아니라 컨테이너가 외부망으로 나가는 경로 자체가 없는 네트워크 문제라는 것이었습니다. 패키지 서버로 요청 자체가 나가지 못하고 있었던 겁니다.
3. 임시 해결 — Docker 호스트와 동일한 네트워크 사용 체크
이전에 Docker를 잠깐 써봤던 경험 덕분에 “Docker에서는 네트워크 설정을 따로 해줘야 한다”는 건 알고 있었습니다. 그래서 DNS도 만져보고, 여러 설정을 건드려봤습니다. 내부망끼리는 통신이 됐는데, 내부망에서 외부망으로 나가는 건 계속 안 됐습니다.
결국 찾아낸 해결 방법은 DSM Docker 패키지 GUI에서 다음 경로로 들어가 설정 하나를 바꾸는 것이었습니다.
Docker → 이미지 → 실행 → 고급 설정 → 네트워크 → “Docker 호스트와 동일한 네트워크 사용” 체크
(당시 DSM 기준, 버전에 따라 UI 위치가 다를 수 있습니다)
이 체크 하나로 apt-get update가 정상 통과됐습니다. 긴 싸움 끝에 패키지 목록이 쭉 받아지는 걸 봤을 때의 안도감이란…
이 설정은 컨테이너가 NAS 자체의 네트워크 스택을 그대로 공유하는 방식입니다. 컨테이너 입장에서는 NAS와 같은 네트워크에 있는 것처럼 동작하게 되고, 그래서 외부 인터넷으로도 바로 나갈 수 있게 됩니다.
4. 그런데 이게 정답은 아니었습니다
해결은 됐지만 당시에도 찜찜했습니다. 원본 글에 이렇게 적었습니다.
“원래 대로라면 docker 포트 따로 잡아서 따로 연결해야 하는 걸로 알고 있는데 말이죠..”
그 찜찜함은 근거 있는 감각이었습니다.
쉽게 말하면, 컨테이너와 NAS가 같은 네트워크를 공유하는 구조입니다. 그러다 보니 컨테이너 안에서 어떤 서비스가 포트를 열 때, DSM이 이미 점유하는 포트나 NAS 자체 서비스와 충돌할 가능성이 생깁니다. Docker가 원래 목표로 하는 컨테이너 격리도 약해지는 방향이고요.
홈 NAS 자동화 용도라면 당장 큰 문제가 되는 상황이 아닐 수는 있습니다. 다만, Docker를 “격리된 환경”으로 쓴다는 기본 목적에서 보면 한 발 물러난 선택인 건 분명합니다.
당시 저는 “문제를 제대로 해결하지 못한 거 같아 좀 아쉽긴 합니다”로 글을 마쳤는데, 그 아쉬움이 정확했습니다.
5. 정석 해결법은 별도 포스트로 정리해뒀습니다
이후 포트 매핑 방식으로 다시 설정한 내용을 별도 포스트로 정리했습니다. 원본 글에도 이미 이렇게 수정 안내를 달아뒀습니다.
“수정 : 현재는 port 지정해서 아래 방식으로 설정하지 않습니다.”
정식 환경을 구성할 계획이라면 아래 글을 보시는 편이 훨씬 낫습니다.
👉 Synology NAS Docker Ubuntu에서 apt-get update가 안 될 때 — IP 포트 설정
이 글(57번)은 “왜 그때 호스트 네트워크 모드라는 임시 우회가 필요했는가”에 대한 회고입니다. 87번이 포트 매핑 방식의 정석 절차입니다. 두 글을 같이 읽으면 왜 첫 번째 방법을 운영 환경에서 쓰면 안 되는지가 더 선명하게 보입니다.
그 경험이 있으니, 같은 상황을 지금 다시 만난다면 저는 처음부터 이 순서로 점검할 것 같습니다.
6. 5년 뒤, 같은 자리에서 다시 본다면
- 컨테이너 안에서 외부로 나가는지부터 확인 — 외부로 요청이 가는지, 이름 풀이가 되는지를 먼저 본다
- DNS 문제인지 라우팅 문제인지 구분 —
nslookup google.com또는curl -v https://google.com으로 DNS 응답 여부를 먼저 확인. DNS 응답은 오는데 연결이 안 된다면 라우팅이나 방화벽 방향을 본다 - NAS 단의 방화벽·포트 설정 확인 — NAS 자체에서 막고 있는 건 아닌지
- 호스트 네트워크 모드는 마지막 임시 우회로만 — 빠르게 원인을 확인하는 용도로는 쓸 수 있지만, 운영 환경에서는 포트 매핑 방식으로 전환한다
“이렇게 하면 됩니다”가 아니라, “지금이라면 저는 이 순서로 봅니다”입니다. 환경마다 다를 수 있으니 참고만 하시면 됩니다.
트러블슈팅 점검 순서 요약
| 점검 순서 | 항목 | 이 사례에서의 결과 |
|---|---|---|
| 1 | 컨테이너 외부 접속 가능 여부 | 실패 — apt-get update 불가 |
| 2 | DNS 응답 | 시도했으나 미해결 |
| 3 | 호스트 네트워크 모드 체크 | 임시 해결 |
| 4 | 포트 매핑 방식 (정석) | 별도 포스트 87번 참조 |
원본 글 마지막에 “Docker를 좀 더 공부해봐야겠습니다”라고 썼는데, 그 다짐이 실제로 이어졌습니다. 그때 제대로 못 풀었던 것이 결국 87번 포스트의 출발점이 됐고, 그 글에서 포트 매핑 방식으로 제대로 정리할 수 있었습니다.
같은 문제로 막혀 계신 분이라면, 이 글이 왜 막혔는지 이해하는 데 한 줄이라도 보탬이 됐으면 좋겠습니다. 정석 구성은 87번 글에서 이어집니다.
출처 및 참고 자료
- 원본 실습 기록 (post ID: 57, 2021-01-09)
- 정석 해결 포스트: https://aprox.co.kr/synology-nas-docker-ubuntu-apt-get-update-fix/
- Docker 공식 문서 — Use host networking: https://docs.docker.com/engine/network/drivers/host/
※ Docker 공식 문서에서는 host 네트워크 모드에 대해 “If you use the host network mode for a container, that container’s network stack is not isolated from the Docker host”(컨테이너의 네트워크 스택이 Docker 호스트로부터 격리되지 않는다)고 설명합니다. 본문 §4에서 언급한 격리 약화 특성의 기술적 근거입니다.