Docker 미드레벨 코딩 면접
새 면접Q. Docker Compose에서 환경 변수를 주입하는 4가지 방법(environment, env_file, .env, shell 변수)의 우선순위와 각각의 사용 사례를 설명하고, 민감한 정보를 안전하게 관리하기 위한 전략을 제시해주세요.
우선순위는 Compose file의 environment > shell 변수 > env_file > .env 순입니다. environment는 고정값이나 오버라이드에 사용하고, env_file은 환경별 설정 파일 분리에 적합하며, .env는 로컬 개발용 기본값 설정에 사용합니다. shell 변수는 CI/CD에서 동적 주입 시 활용합니다. 민감 정보는 Docker Secrets나 외부 vault(HashiCorp Vault, AWS Secrets Manager)를 사용하고, .env 파일은 .gitignore에 추가하며, 프로덕션에서는 환경 변수 대신 secrets를 마운트하는 방식을 권장합니다.
- • 환경 변수 주입 방법의 우선순위: environment > shell > env_file > .env
- • 각 방법의 사용 사례: 고정값, 환경별 분리, 로컬 개발, CI/CD 동적 주입
- • 민감 정보 관리: Docker Secrets, 외부 vault 활용, .gitignore 설정
Docker Swarm mode에서 secrets와 configs의 차이점과 각각의 업데이트 전략을 설명해주세요.
Q. Docker에서 사용자 정의 bridge 네트워크를 생성할 때 subnet, gateway, ip-range 옵션을 설정하는 방법과 이유를 설명하고, 컨테이너에 고정 IP를 할당할 때 발생할 수 있는 문제점과 DNS 기반 서비스 디스커버리를 사용해야 하는 이유를 설명해주세요.
docker network create 명령어에서 --subnet은 네트워크 주소 범위를, --gateway는 게이트웨이 IP를, --ip-range는 컨테이너에 할당 가능한 IP 범위를 지정합니다. 고정 IP는 docker run --ip 옵션으로 할당 가능하지만, 스케일링 시 IP 충돌 위험이 있고, 컨테이너 재시작 시 IP 변경 가능성, 오케스트레이션 도구와의 호환성 문제가 발생합니다. Docker는 내장 DNS 서버(127.0.0.11)를 통해 컨테이너 이름으로 자동 서비스 디스커버리를 제공하므로, 고정 IP 대신 컨테이너 이름이나 서비스 이름을 사용하는 것이 권장됩니다.
- • 사용자 정의 네트워크 옵션: subnet(주소 범위), gateway(게이트웨이), ip-range(할당 범위)
- • 고정 IP의 문제점: IP 충돌, 재시작 시 변경 가능성, 오케스트레이션 비호환
- • DNS 기반 디스커버리: 내장 DNS 서버 활용, 컨테이너 이름 기반 통신
macvlan 네트워크 드라이버를 사용하여 컨테이너에 물리 네트워크의 IP를 직접 할당하는 시나리오와 설정 방법을 설명해주세요.
Q. BuildKit의 캐시 마운트(RUN --mount=type=cache)와 시크릿 마운트(RUN --mount=type=secret) 기능을 활용하여 패키지 매니저 캐시를 재사용하고 빌드 시크릿을 안전하게 처리하는 방법을 설명하고, 이를 통해 해결되는 문제점을 제시해주세요.
BuildKit의 캐시 마운트는 RUN --mount=type=cache,target=/root/.cache/pip 형태로 패키지 매니저의 캐시 디렉토리를 빌드 간 공유하여 반복적인 다운로드를 방지합니다. 시크릿 마운트는 RUN --mount=type=secret,id=npmrc,target=/root/.npmrc 형태로 빌드 시에만 시크릿을 임시 마운트하여 최종 이미지에 포함되지 않게 합니다. 이를 통해 빌드 속도 향상, 네트워크 대역폭 절약, 레이어에 시크릿이 남지 않아 보안 강화, ARG로 전달하는 방식보다 안전한 시크릿 관리가 가능합니다.
- • 캐시 마운트: 패키지 매니저 캐시 디렉토리를 빌드 간 공유하여 다운로드 최소화
- • 시크릿 마운트: 빌드 시에만 임시 마운트하여 최종 이미지에 포함 방지
- • 효과: 빌드 속도 향상, 네트워크 절약, 보안 강화
BuildKit의 병렬 빌드 기능과 --build-arg BUILDKIT_INLINE_CACHE=1을 사용한 원격 캐시 활용 전략을 설명해주세요.
Q. 프로덕션 환경에서 컨테이너가 간헐적으로 응답 없음 상태에 빠질 때, strace, nsenter, docker exec를 활용하여 시스템 콜 레벨에서 문제를 진단하는 방법과 절차를 설명하고, 컨테이너 내부 프로세스가 데드락이나 I/O 블로킹 상태인지 판별하는 방법을 제시해주세요.
먼저 docker inspect로 컨테이너의 PID를 확인하고, nsenter -t PID -p -n을 통해 컨테이너 네임스페이스에 진입합니다. strace -p PID를 실행하여 프로세스가 대기 중인 시스템 콜을 확인하고, futex 호출이 반복되면 데드락, read/write가 블로킹되면 I/O 문제를 의심합니다. docker exec로 내부 진입 후 ps aux, top, lsof -p PID로 프로세스 상태와 열린 파일 디스크립터를 확인하고, /proc/PID/stack을 읽어 커널 스택 트레이스를 분석합니다. 네트워크 문제는 netstat -anp, tcpdump로 연결 상태를 확인합니다.
- • nsenter로 컨테이너 네임스페이스 진입, strace로 시스템 콜 추적
- • futex 반복은 데드락, read/write 블로킹은 I/O 문제 징후
- • /proc/PID/stack 분석, lsof로 파일 디스크립터 확인, tcpdump로 네트워크 진단
컨테이너에 디버깅 도구가 설치되지 않은 최소 이미지(distroless)에서 문제를 진단하기 위한 ephemeral container나 debug container 활용 전략을 설명해주세요.
Q. Docker 볼륨을 사용하는 데이터베이스 컨테이너의 I/O 성능을 측정하고 최적화하는 방법을 설명하고, tmpfs 마운트를 활용한 임시 데이터 처리, 볼륨 드라이버 옵션(type=nfs, o=addr), direct I/O 설정이 성능에 미치는 영향을 분석해주세요.
fio나 sysbench를 사용하여 IOPS, 처리량, 레이턴시를 측정하고, docker stats로 실시간 I/O 메트릭을 모니터링합니다. tmpfs 마운트(--tmpfs /tmp:rw,noexec,nosuid,size=1g)는 메모리 기반이므로 임시 테이블이나 캐시에 사용하면 디스크 I/O를 회피할 수 있지만, 재시작 시 데이터가 손실됩니다. NFS 볼륨은 네트워크 오버헤드가 있으므로 로컬 볼륨보다 느리며, o=nfsvers=4.1,rsize=1048576,wsize=1048576 옵션으로 버퍼 크기를 조정하여 최적화합니다. 데이터베이스는 direct I/O를 사용하여 OS 페이지 캐시를 우회하고 자체 버퍼 풀을 관리하므로, 볼륨 마운트 시 추가 버퍼링을 비활성화하는 것이 유리합니다.
- • 성능 측정: fio, sysbench로 IOPS/처리량/레이턴시 측정, docker stats 모니터링
- • tmpfs 마운트: 메모리 기반으로 빠르지만 휘발성, 임시 데이터에 적합
- • NFS 최적화: 버퍼 크기 조정, direct I/O로 이중 버퍼링 회피
CSI(Container Storage Interface) 드라이버를 사용하여 클라우드 스토리지(EBS, Persistent Disk)를 컨테이너에 동적으로 프로비저닝하는 방법과 성능 특성을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!