Docker 시니어 기술면접
새 면접Q. Docker 빌드 컨텍스트의 개념과 대용량 프로젝트에서 빌드 성능을 저하시키는 원인을 설명하고, BuildKit의 주요 기능(병렬 빌드, 원격 캐시, 시크릿 마운트)을 활용하여 빌드 시간을 개선하는 전략을 설명해주세요. 특히 모노레포 환경에서의 최적화 방법을 포함해주세요.
빌드 컨텍스트는 docker build 명령 실행 시 Docker 데몬으로 전송되는 파일들의 집합으로, .dockerignore를 활용해 불필요한 파일을 제외해야 합니다. BuildKit은 DOCKER_BUILDKIT=1 환경변수로 활성화하며, 병렬 스테이지 실행으로 독립적인 빌드 단계를 동시에 처리하고, --mount=type=cache로 패키지 매니저 캐시를 영속화하며, --mount=type=secret으로 자격증명을 안전하게 주입합니다. 모노레포에서는 --build-context를 사용해 특정 서브디렉토리만 컨텍스트로 지정하고, 원격 캐시(--cache-from/--cache-to)를 레지스트리에 저장하여 CI/CD 환경에서 빌드 캐시를 공유합니다. 또한 RUN --mount=type=bind를 활용해 빌드 시에만 필요한 파일을 임시로 마운트하여 최종 이미지 크기를 줄일 수 있습니다.
- • 빌드 컨텍스트 최소화와 .dockerignore 활용
- • BuildKit의 병렬 빌드, 캐시 마운트, 시크릿 마운트 기능
- • 모노레포에서 --build-context와 원격 캐시 전략
- • RUN --mount=type=bind로 임시 파일 처리
대규모 마이크로서비스 환경에서 공통 베이스 이미지 관리 전략과 각 서비스의 빌드 의존성을 효율적으로 관리하는 방법을 설명해주세요.
Q. Docker의 로깅 드라이버(json-file, syslog, fluentd, gelf, journald)의 동작 원리와 성능 특성을 비교 설명하고, 대규모 컨테이너 환경에서 로그 수집 아키텍처를 설계할 때 고려해야 할 사항을 설명해주세요. 특히 로그 로테이션, 백프레셔 처리, 중앙집중식 로깅 시스템 구축 전략을 포함해주세요.
json-file은 기본 드라이버로 /var/lib/docker/containers에 JSON 형식으로 저장하며 max-size와 max-file 옵션으로 로테이션을 설정해야 디스크 고갈을 방지할 수 있습니다. fluentd와 gelf는 로그를 직접 외부 시스템으로 전송하지만, 네트워크 장애나 백엔드 지연 시 컨테이너가 블로킹될 수 있어 mode=non-blocking과 max-buffer-size 설정이 필수적입니다. 대규모 환경에서는 사이드카 패턴으로 각 노드에 로그 수집기(Fluentd, Fluent Bit)를 배포하고, json-file 드라이버로 로컬 저장 후 수집기가 파일을 읽어 중앙 시스템(Elasticsearch, Loki)으로 전송하는 방식이 안정적입니다. journald는 systemd 환경에서 효율적이며, 로그 메타데이터를 구조화하여 저장합니다. 성능 측면에서는 json-file이 가장 빠르지만 로그 검색 기능이 없고, 직접 전송 방식은 네트워크 오버헤드가 있으나 실시간 처리가 가능합니다.
- • json-file 드라이버의 로테이션 설정과 디스크 관리
- • fluentd/gelf의 백프레셔 처리와 non-blocking 모드
- • 사이드카 패턴을 활용한 로그 수집 아키텍처
- • 로깅 드라이버별 성능 특성과 트레이드오프
Kubernetes 환경에서 stdout/stderr 기반 로깅과 파일 기반 로깅의 차이점, 그리고 구조화된 로깅(structured logging) 도입 시 고려사항을 설명해주세요.
Q. Docker의 네임스페이스 기반 네트워크 격리 메커니즘과 iptables 규칙 생성 과정을 설명하고, 멀티테넌트 환경에서 컨테이너 간 네트워크 격리를 강화하는 방법을 설명해주세요. 특히 Network Policy 구현, 포트 포워딩 보안 이슈, 그리고 서비스 메시 도입 시 고려사항을 포함해주세요.
Docker는 각 컨테이너에 네트워크 네임스페이스를 할당하여 독립적인 네트워크 스택을 제공하며, veth pair로 컨테이너와 호스트 브릿지를 연결합니다. iptables는 DOCKER 체인을 생성하여 포트 포워딩(DNAT)과 컨테이너 간 통신을 제어하며, --icc=false 옵션으로 동일 브릿지 내 컨테이너 간 통신을 차단할 수 있습니다. 멀티테넌트 환경에서는 각 테넌트별로 별도의 Docker 네트워크를 생성하고, --internal 옵션으로 외부 접근을 차단하며, Calico나 Cilium 같은 CNI 플러그인을 사용해 세밀한 Network Policy를 적용합니다. 포트 포워딩 시 0.0.0.0 바인딩은 보안 위험이 있어 특정 IP로 제한해야 하며, 서비스 메시(Istio, Linkerd) 도입 시 사이드카 프록시의 리소스 오버헤드와 네트워크 레이턴시 증가를 고려해야 합니다. 또한 eBPF 기반 솔루션(Cilium)은 iptables보다 성능이 우수하고 관찰성이 뛰어납니다.
- • 네임스페이스와 veth pair 기반 네트워크 격리
- • iptables DOCKER 체인과 --icc=false 옵션
- • 멀티테넌트를 위한 네트워크 분리와 CNI 플러그인
- • 서비스 메시와 eBPF 기반 솔루션의 트레이드오프
IPv6 지원 환경에서 Docker 네트워크 설정 시 주의사항과 듀얼 스택 구성 방법, 그리고 컨테이너 간 암호화 통신 구현 전략을 설명해주세요.
Q. Docker의 HEALTHCHECK 지시어와 컨테이너 재시작 정책(restart policy)의 동작 원리를 설명하고, 프로덕션 환경에서 애플리케이션의 복원력을 높이기 위한 헬스체크 설계 전략을 설명해주세요. Kubernetes의 liveness/readiness probe와의 차이점도 포함해주세요.
HEALTHCHECK 지시어는 Dockerfile에서 --interval, --timeout, --start-period, --retries 옵션으로 정의하며, 지정된 명령어가 연속으로 실패하면 컨테이너 상태를 unhealthy로 변경합니다. 재시작 정책은 no, on-failure, always, unless-stopped 네 가지가 있으며, on-failure는 종료 코드가 0이 아닐 때만 재시작하고, always는 Docker 데몬 재시작 시에도 컨테이너를 재시작합니다. 프로덕션에서는 단순 TCP 체크보다 애플리케이션 레벨 헬스체크(DB 연결, 외부 의존성 확인)를 구현하되, 타임아웃을 짧게 설정하여 체크 자체가 부하가 되지 않도록 해야 합니다. Kubernetes의 liveness probe는 실패 시 컨테이너를 재시작하고, readiness probe는 실패 시 서비스에서 제외하여 트래픽을 받지 않게 하는 차이가 있습니다. Docker 단독 사용 시 헬스체크는 상태 표시만 하고 자동 조치는 오케스트레이터나 외부 모니터링 시스템이 담당해야 합니다.
- • HEALTHCHECK 옵션과 컨테이너 상태 관리
- • 재시작 정책의 종류와 동작 차이
- • 애플리케이션 레벨 헬스체크 설계 원칙
- • Kubernetes probe와의 차이점 및 역할 분담
서킷 브레이커 패턴과 헬스체크를 조합하여 장애 전파를 방지하는 방법과, 블루-그린 배포나 카나리 배포 시 헬스체크 활용 전략을 설명해주세요.
Q. Docker Content Trust(DCT)와 Notary의 동작 원리를 설명하고, 컨테이너 이미지 공급망 보안을 강화하기 위한 전략을 설명해주세요. 특히 이미지 서명 검증, Sigstore/Cosign 같은 최신 도구, 그리고 정책 기반 이미지 승인 프로세스 구축 방법을 포함해주세요.
Docker Content Trust는 The Update Framework(TUF) 기반의 Notary를 사용하여 이미지 서명과 검증을 수행하며, DOCKER_CONTENT_TRUST=1 환경변수로 활성화하면 서명되지 않은 이미지의 pull/push를 차단합니다. Notary는 루트 키, 타겟 키, 스냅샷 키 등 계층적 키 구조를 사용하여 키 노출 시 피해를 최소화하며, 이미지 태그와 다이제스트의 매핑을 서명하여 무결성을 보장합니다. Sigstore/Cosign은 키리스 서명을 지원하여 OIDC 기반 단기 인증서를 사용하고, Rekor 투명성 로그에 서명을 기록하여 감사 가능성을 높입니다. 프로덕션 환경에서는 Open Policy Agent(OPA)나 Kyverno를 사용해 정책 기반 승인을 구현하고, CI/CD 파이프라인에서 이미지 빌드 시 자동 서명하며, 런타임에 admission controller로 서명 검증을 강제합니다. 또한 SBOM을 이미지에 첨부하고 정기적으로 취약점 스캔을 수행하여 공급망 전반의 보안을 강화합니다.
- • Docker Content Trust와 Notary의 TUF 기반 서명 메커니즘
- • Sigstore/Cosign의 키리스 서명과 투명성 로그
- • OPA/Kyverno를 활용한 정책 기반 이미지 승인
- • CI/CD 파이프라인 통합과 런타임 검증 강제
에어갭 환경이나 오프라인 환경에서 이미지 서명 및 검증을 구현하는 방법과, 멀티 클라우드 환경에서 일관된 이미지 보안 정책을 적용하는 전략을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!