Docker 주니어 CS 기초 기술면접
새 면접Q. Docker 컨테이너가 외부 인터넷과 통신할 때 사용되는 NAT(Network Address Translation)의 역할과 동작 방식을 설명하고, 컨테이너의 사설 IP가 어떻게 호스트의 공인 IP로 변환되는지 말씀해주세요.
NAT는 컨테이너의 사설 IP 주소를 호스트의 IP 주소로 변환하여 외부 네트워크와 통신할 수 있게 해주는 기술입니다. Docker는 기본적으로 iptables를 사용하여 NAT를 구현하며, 컨테이너가 외부로 패킷을 보낼 때 출발지 IP를 호스트 IP로 변환(SNAT)하고, 응답 패킷이 돌아올 때 다시 컨테이너 IP로 변환(DNAT)합니다. 이를 통해 컨테이너는 사설 네트워크 내에 있으면서도 외부 인터넷에 접근할 수 있습니다. 포트 매핑(-p 옵션)도 NAT의 일종으로, 특정 포트로 들어오는 트래픽을 컨테이너 내부 포트로 전달합니다.
- • NAT는 사설 IP와 공인 IP 간의 주소 변환 기술
- • Docker는 iptables를 통해 NAT 구현
- • SNAT(출발지 변환)와 DNAT(목적지 변환)를 통한 양방향 통신
- • 포트 매핑도 NAT의 일종인 포트 포워딩
Docker의 host 네트워크 모드를 사용하면 NAT 없이 통신이 가능한데, 이때의 장단점은 무엇인가요?
Q. Docker가 컨테이너 격리를 위해 사용하는 Linux Namespace의 개념을 설명하고, PID Namespace, Network Namespace, Mount Namespace가 각각 어떤 리소스를 격리하는지 말씀해주세요.
Linux Namespace는 프로세스가 볼 수 있는 시스템 리소스를 격리하여 각 컨테이너가 독립된 환경을 가지도록 하는 커널 기능입니다. PID Namespace는 프로세스 ID를 격리하여 컨테이너마다 독립적인 프로세스 트리를 가지게 하고, Network Namespace는 네트워크 인터페이스, IP 주소, 라우팅 테이블 등을 격리하여 각 컨테이너가 독립적인 네트워크 스택을 가지게 합니다. Mount Namespace는 파일시스템 마운트 포인트를 격리하여 각 컨테이너가 독립적인 파일시스템 뷰를 가지도록 합니다. 이러한 Namespace들이 결합되어 컨테이너 수준의 격리를 제공합니다.
- • Namespace는 시스템 리소스를 논리적으로 격리하는 커널 기능
- • PID Namespace: 프로세스 ID 격리
- • Network Namespace: 네트워크 스택 격리
- • Mount Namespace: 파일시스템 마운트 격리
- • 여러 Namespace가 결합되어 컨테이너 격리 구현
Namespace와 함께 사용되는 cgroups는 어떤 역할을 하며, Namespace와 어떻게 다른가요?
Q. Docker 이미지 레지스트리에서 같은 베이스 이미지를 사용하는 여러 이미지를 저장할 때 중복 데이터를 어떻게 처리하는지, 그리고 이것이 어떤 자료구조의 특성과 유사한지 설명해주세요.
Docker 레지스트리는 Content-Addressable Storage 방식을 사용하여 이미지 레이어를 저장합니다. 각 레이어는 내용의 해시값으로 식별되며, 동일한 내용의 레이어는 해시값이 같아 한 번만 저장됩니다. 이는 해시 테이블의 특성과 유사하며, 키(해시값)로 빠른 조회가 가능하고 중복을 자동으로 제거합니다. 예를 들어 ubuntu:20.04를 베이스로 하는 10개의 이미지가 있어도, ubuntu 레이어는 한 번만 저장되고 나머지 이미지는 이를 참조합니다. 이를 통해 저장 공간을 크게 절약할 수 있습니다.
- • Content-Addressable Storage: 내용의 해시값으로 저장
- • 동일한 레이어는 해시값이 같아 중복 저장 방지
- • 해시 테이블과 유사한 구조로 빠른 조회와 중복 제거
- • 여러 이미지가 동일 레이어를 참조하여 공간 절약
Docker pull 명령어로 이미지를 다운로드할 때 이미 존재하는 레이어를 어떻게 감지하고 스킵하나요?
Q. Docker 컨테이너로 PostgreSQL 데이터베이스를 실행할 때 ACID 속성 중 Durability(지속성)를 보장하기 위해 반드시 고려해야 할 사항과, 컨테이너가 삭제되어도 데이터를 보존하는 방법을 설명해주세요.
데이터베이스의 Durability는 커밋된 트랜잭션이 영구적으로 저장되어야 한다는 속성입니다. Docker 컨테이너는 기본적으로 ephemeral(임시적)하여 삭제되면 내부 데이터도 함께 사라지므로, 반드시 Volume을 사용하여 데이터 디렉토리를 호스트나 외부 스토리지에 마운트해야 합니다. PostgreSQL의 경우 /var/lib/postgresql/data 디렉토리를 Volume으로 지정해야 하며, docker run 시 -v 옵션이나 docker-compose의 volumes 설정을 통해 구현합니다. 이를 통해 컨테이너가 재시작되거나 삭제되어도 데이터가 유지되어 Durability가 보장됩니다.
- • Durability: 커밋된 트랜잭션의 영구 저장 보장
- • 컨테이너는 기본적으로 ephemeral하여 데이터 손실 위험
- • Volume을 사용하여 데이터 디렉토리를 외부에 저장
- • PostgreSQL의 /var/lib/postgresql/data를 Volume으로 마운트
- • 컨테이너 생명주기와 독립적으로 데이터 유지
데이터베이스 컨테이너의 백업 전략을 수립할 때 고려해야 할 사항은 무엇인가요?
Q. Docker 컨테이너에서 발생하는 좀비 프로세스(Zombie Process) 문제와 그 원인을 설명하고, init 시스템(tini, dumb-init 등)을 사용하는 이유를 프로세스 관리 측면에서 말씀해주세요.
좀비 프로세스는 실행이 종료되었지만 부모 프로세스가 wait() 시스템 콜로 종료 상태를 회수하지 않아 프로세스 테이블에 남아있는 프로세스입니다. Docker 컨테이너에서 애플리케이션이 PID 1로 실행되면 자식 프로세스가 종료되었을 때 reaping(회수) 책임을 가지게 되는데, 일반 애플리케이션은 이를 처리하지 않아 좀비 프로세스가 누적될 수 있습니다. init 시스템은 PID 1로 실행되어 모든 고아 프로세스를 입양하고 종료된 자식 프로세스를 자동으로 회수하며, 시그널을 올바르게 전파하는 역할을 합니다. 이를 통해 프로세스 테이블 고갈을 방지하고 정상적인 컨테이너 종료를 보장합니다.
- • 좀비 프로세스: 종료되었지만 부모가 회수하지 않은 프로세스
- • PID 1은 고아 프로세스 입양과 자식 프로세스 회수 책임
- • 일반 애플리케이션은 reaping 기능이 없어 좀비 프로세스 발생
- • init 시스템(tini, dumb-init)이 자동으로 프로세스 회수
- • 시그널 전파와 정상적인 종료 처리도 담당
Dockerfile에서 ENTRYPOINT를 설정할 때 exec 형식과 shell 형식의 차이가 PID 1 프로세스에 어떤 영향을 미치나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!