Docker 주니어 CS 기초 기술면접
새 면접Q. Docker 컨테이너에서 localhost를 사용할 때 주의해야 할 점은 무엇이며, 컨테이너 간 통신 시 localhost 대신 어떤 방법을 사용해야 하는지 설명해주세요.
Docker 컨테이너는 각자 독립된 네트워크 네임스페이스를 가지므로 컨테이너 내부의 localhost는 컨테이너 자신만을 가리킵니다. 따라서 컨테이너 A에서 localhost로 컨테이너 B에 접근할 수 없습니다. 컨테이너 간 통신을 위해서는 동일한 Docker 네트워크에 연결하고 컨테이너 이름이나 서비스 이름을 호스트명으로 사용해야 합니다. Docker의 내장 DNS 서버가 컨테이너 이름을 IP 주소로 자동 변환해주기 때문입니다.
- • 컨테이너마다 독립된 네트워크 네임스페이스 보유
- • localhost는 컨테이너 자신만 가리킴
- • 컨테이너 이름을 호스트명으로 사용하여 통신
- • Docker 내장 DNS가 이름 해석 수행
호스트 머신의 localhost에서 실행 중인 서비스(예: MySQL)에 컨테이너에서 접근하려면 어떻게 해야 하나요?
Q. Docker 이미지의 태그 관리는 어떤 자료구조의 특성과 유사하며, 하나의 이미지 ID가 여러 태그를 가질 수 있는 구조를 무엇이라고 하는지 설명해주세요.
Docker 이미지의 태그 관리는 해시 테이블(Hash Table) 또는 딕셔너리(Dictionary) 구조와 유사합니다. 이미지 ID(해시값)가 실제 값이고, 여러 태그가 이를 가리키는 키 역할을 합니다. 하나의 이미지 ID에 여러 태그가 매핑될 수 있는 이 구조를 앨리어싱(Aliasing)이라고 하며, myapp:latest와 myapp:1.0이 동일한 이미지 ID를 가리킬 수 있습니다. 이를 통해 메모리 효율성을 높이고 동일 이미지에 대한 다양한 참조를 제공합니다.
- • 해시 테이블 구조와 유사
- • 태그가 키, 이미지 ID가 값
- • 하나의 이미지 ID에 여러 태그 매핑 가능(앨리어싱)
- • 저장 공간 효율성 증대
docker rmi 명령어로 태그를 삭제할 때, 같은 이미지 ID를 가진 다른 태그가 있으면 어떻게 되나요?
Q. Docker에서 사용하는 Copy-on-Write(COW) 파일 시스템의 동작 원리를 설명하고, 이것이 컨테이너 실행 속도와 디스크 효율성에 어떻게 기여하는지 말씀해주세요.
Copy-on-Write는 여러 컨테이너가 동일한 이미지 레이어를 읽기 전용으로 공유하다가, 수정이 필요할 때만 해당 파일을 컨테이너의 쓰기 가능한 레이어로 복사하는 방식입니다. 이를 통해 100개의 컨테이너가 같은 베이스 이미지를 사용해도 이미지 레이어는 한 번만 저장되며, 각 컨테이너는 변경된 부분만 자신의 레이어에 저장합니다. 결과적으로 컨테이너 시작 시간이 빨라지고 디스크 공간이 크게 절약되며, 이미지 다운로드도 중복 레이어를 재사용하여 효율적입니다.
- • 읽기는 공유, 쓰기 시에만 복사
- • 여러 컨테이너가 동일 레이어 공유
- • 디스크 공간 절약 및 시작 속도 향상
- • OverlayFS, AUFS 등의 스토리지 드라이버로 구현
Copy-on-Write 방식의 단점이나 성능상 오버헤드가 발생할 수 있는 상황은 무엇인가요?
Q. Docker 컨테이너에서 데이터베이스를 운영할 때 트랜잭션 로그(WAL, Redo Log)의 저장 위치를 고려해야 하는 이유와, 볼륨 마운트 시 성능 최적화를 위한 방법을 설명해주세요.
트랜잭션 로그는 데이터베이스의 모든 변경사항을 순차적으로 기록하는 파일로, 장애 복구와 ACID 보장에 핵심적입니다. 컨테이너 레이어에 저장하면 COW 오버헤드와 컨테이너 삭제 시 데이터 손실 위험이 있으므로 반드시 볼륨에 마운트해야 합니다. 성능 최적화를 위해서는 데이터 파일과 로그 파일을 별도의 볼륨으로 분리하고, 특히 로그 파일은 순차 쓰기 성능이 좋은 스토리지에 배치하는 것이 좋습니다. 또한 tmpfs를 활용해 임시 데이터를 메모리에 저장하여 I/O 부하를 줄일 수 있습니다.
- • 트랜잭션 로그는 반드시 볼륨에 저장
- • 데이터와 로그 파일을 별도 볼륨으로 분리
- • 순차 쓰기 성능이 중요
- • tmpfs로 임시 데이터 성능 향상
Docker 볼륨의 백업 전략과 특정 시점으로 복구(Point-in-Time Recovery)를 구현하려면 어떻게 해야 하나요?
Q. Docker 이미지 빌드 시 캐시가 무효화되는 조건을 설명하고, 이것이 어떤 알고리즘 개념과 유사한지 말씀해주세요.
Docker는 Dockerfile의 각 명령어를 순차적으로 실행하며 레이어 캐시를 체크합니다. 특정 레이어에서 변경이 감지되면 해당 레이어부터 이후의 모든 레이어 캐시가 무효화됩니다. 이는 체인 반응(Cascade) 또는 의존성 그래프에서의 하향식 전파와 유사합니다. 예를 들어, COPY 명령어에서 파일 내용이 변경되거나 RUN 명령어의 내용이 달라지면 캐시가 무효화되고, 이후 모든 단계가 재실행됩니다. 따라서 자주 변경되는 명령어는 Dockerfile 하단에 배치하는 것이 빌드 효율성을 높입니다.
- • 순차적으로 캐시 체크
- • 변경 감지 시 이후 모든 레이어 무효화
- • 체인 반응 또는 의존성 전파와 유사
- • 자주 변경되는 명령어는 하단 배치
Dockerfile에서 apt-get update와 apt-get install을 별도의 RUN 명령어로 분리하면 안 되는 이유는 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!