소개
이 종합 가이드에 오신 것을 환영합니다! 이 가이드는 다음 Docker 인터뷰에서 뛰어난 성과를 거두는 데 필요한 지식과 자신감을 갖추도록 설계되었습니다. 개발자, DevOps 엔지니어 또는 시스템 관리자이든, 오늘날 클라우드 네이티브 환경에서 Docker 를 마스터하는 것은 매우 중요합니다. 이 문서는 기본 개념 및 이미지 관리부터 고급 오케스트레이션, 보안 및 문제 해결에 이르기까지 광범위한 Docker 주제를 다루며, 역할별 질문 및 실질적인 과제도 포함합니다. 이해도를 높이고 전문성을 보여주어 모든 Docker 관련 역할에서 성공할 수 있도록 준비하십시오.
Docker 기본 및 핵심 개념
Docker 란 무엇이며 왜 사용되나요?
답변:
Docker 는 컨테이너화를 사용하여 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈 소스 플랫폼입니다. 애플리케이션을 위한 일관된 환경을 제공하여 개발부터 프로덕션까지 다양한 컴퓨팅 환경에서 안정적으로 실행되도록 보장하는 데 사용됩니다.
Docker 이미지와 Docker 컨테이너의 차이점을 설명해 주세요.
답변:
Docker 이미지는 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정을 포함하여 소프트웨어 조각을 실행하는 데 필요한 모든 것을 포함하는 가볍고 독립적이며 실행 가능한 패키지입니다. Docker 컨테이너는 Docker 이미지의 실행 가능한 인스턴스입니다. 컨테이너를 생성, 시작, 중지, 이동 또는 삭제할 수 있습니다.
Dockerfile 이란 무엇이며 그 목적은 무엇인가요?
답변:
Dockerfile 은 사용자가 이미지를 조립하기 위해 명령줄에서 호출할 수 있는 모든 명령을 포함하는 텍스트 문서입니다. 이미지 생성 프로세스를 자동화하여 애플리케이션 환경의 재현성과 버전 관리를 보장하는 방법을 제공합니다.
Docker 는 어떻게 격리를 달성하나요?
답변:
Docker 는 주로 네임스페이스 (namespaces) 및 컨트롤 그룹 (cgroups) 과 같은 Linux 커널 기능을 통해 격리를 달성합니다. 네임스페이스는 시스템 리소스 (예: 프로세스 ID, 네트워크 인터페이스) 의 격리된 보기를 제공하며, 컨트롤 그룹은 컨테이너의 리소스 사용량 (CPU, 메모리, I/O) 을 제한하고 모니터링합니다.
Docker 볼륨이란 무엇이며 왜 중요한가요?
답변:
Docker 볼륨은 Docker 컨테이너에서 생성되고 사용되는 데이터를 영구적으로 저장하는 데 선호되는 메커니즘입니다. 컨테이너는 일시적이므로 볼륨이 중요합니다. 볼륨이 없으면 컨테이너가 제거될 때 컨테이너 내부의 데이터가 손실됩니다. 볼륨을 사용하면 데이터가 컨테이너보다 오래 지속될 수 있습니다.
Docker 레이어 개념을 설명해 주세요.
답변:
Docker 이미지는 여러 개의 읽기 전용 레이어로 구성되며, 각 레이어는 Dockerfile 지침을 나타냅니다. 이미지를 빌드할 때 각 명령은 이전 레이어 위에 새 레이어를 생성합니다. 이러한 레이어링은 일반 레이어를 여러 이미지에서 재사용할 수 있도록 하여 효율적인 저장, 공유 및 캐싱을 가능하게 합니다.
Docker Hub 란 무엇인가요?
답변:
Docker Hub 는 Docker 에서 제공하는 클라우드 기반 레지스트리 서비스로, 컨테이너 이미지를 찾고 공유하는 데 사용됩니다. 사용자가 사용자 정의 이미지를 푸시하고 공식 또는 커뮤니티에서 제공한 이미지를 풀할 수 있는 중앙 저장소 역할을 합니다. 또한 자동 빌드 및 웹훅도 제공합니다.
Docker 컨테이너에서 호스트 머신으로 포트를 노출하는 방법은 무엇인가요?
답변:
컨테이너를 실행할 때 -p 또는 --publish 플래그를 사용하여 포트를 노출합니다. 예를 들어, docker run -p 8080:80 my_image는 컨테이너 내부의 포트 80 을 호스트 머신의 포트 8080 에 매핑하여 외부 액세스를 허용합니다.
.dockerignore 파일의 목적은 무엇인가요?
답변:
.dockerignore 파일은 .gitignore와 유사하며 Docker 이미지 빌드 시 제외할 파일 및 디렉토리를 지정합니다. 불필요한 파일 (소스 코드, 빌드 아티팩트 또는 민감한 데이터 등) 이 이미지에 복사되는 것을 방지하여 이미지 크기와 빌드 시간을 줄이는 것이 목적입니다.
Docker 데몬 (dockerd) 에 대해 간략하게 설명해 주세요.
답변:
Docker 데몬 (dockerd) 은 호스트 머신에서 실행되며 이미지, 컨테이너, 네트워크 및 볼륨과 같은 Docker 객체를 관리하는 백그라운드 서비스입니다. Docker API 요청을 수신하고 처리하며, 이미지 빌드, 컨테이너 실행 및 스토리지 관리와 같은 작업을 수행합니다.
Dockerfile 및 이미지 관리
Dockerfile 이란 무엇이며 왜 사용되나요?
답변:
Dockerfile 은 사용자가 이미지를 조립하기 위해 명령줄에서 호출할 수 있는 모든 명령을 포함하는 텍스트 문서입니다. Docker 이미지 생성 프로세스를 자동화하여 다양한 환경에서 일관성과 재현성을 보장하는 데 사용됩니다.
Dockerfile 에서 FROM 지시문의 목적을 설명해 주세요.
답변:
FROM 지시문은 새로운 빌드 단계를 초기화하고 후속 지침에 대한 기본 이미지를 설정합니다. 모든 Dockerfile 은 FROM으로 시작해야 하며, 이미지 빌드의 부모 이미지를 지정합니다. 예: FROM ubuntu:22.04.
Dockerfile 에서 CMD와 ENTRYPOINT의 차이점은 무엇인가요?
답변:
CMD는 실행 중인 컨테이너에 대한 기본 인수를 제공하며, 이는 명령줄 인수로 재정의될 수 있습니다. ENTRYPOINT는 실행 파일로 실행될 컨테이너를 구성하며, 해당 인수는 일반적으로 고정되어 있고 CMD는 추가 매개변수를 제공합니다.
Docker 빌드 캐시는 어떻게 작동하며 왜 중요한가요?
답변:
Docker 는 빌드 프로세스 중에 각 레이어를 캐시합니다. 마지막 빌드 이후로 지침과 해당 컨텍스트가 변경되지 않았다면 Docker 는 캐시된 레이어를 재사용하여 후속 빌드를 크게 가속화합니다. 이는 효율적인 개발 워크플로우에 매우 중요합니다.
.dockerignore 파일이란 무엇이며 그 목적은 무엇인가요?
답변:
.dockerignore 파일은 빌드 컨텍스트가 Docker 데몬으로 전송될 때 제외할 파일 및 디렉토리를 나열합니다. 이는 불필요한 파일이 이미지에 포함되는 것을 방지하여 이미지 크기와 빌드 시간을 줄이며, .gitignore와 유사합니다.
Dockerfile 에서 멀티 스테이지 빌드 개념을 설명해 주세요.
답변:
멀티 스테이지 빌드를 사용하면 Dockerfile 에서 여러 개의 FROM 문을 사용할 수 있으며, 각 문은 새로운 빌드 단계를 시작합니다. 이는 빌드 시간 종속성과 런타임 종속성을 분리하는 데 사용되며, 이전 단계에서 필요한 아티팩트만 복사하여 더 작고 안전한 최종 이미지를 생성합니다.
Docker 이미지 크기를 줄이는 방법은 무엇인가요?
답변:
이미지 크기를 줄이려면 최소한의 기본 이미지 (예: Alpine) 를 사용하고, 멀티 스테이지 빌드를 활용하고, 설치 후 불필요한 파일 및 캐시를 정리하고, RUN 명령을 통합하여 레이어를 최소화하고, .dockerignore를 사용하여 빌드 컨텍스트에서 관련 없는 파일을 제외하십시오.
Docker 이미지 레이어란 무엇이며 왜 중요한가요?
답변:
Docker 이미지는 여러 개의 읽기 전용 레이어로 구성되며, 각 레이어는 Dockerfile 의 지침을 나타냅니다. 레이어는 캐싱 및 이미지 간의 공통 레이어 공유를 통해 효율적인 저장 및 배포를 가능하게 하여 디스크 공간 및 다운로드 시간을 줄입니다.
Dockerfile 에서 ADD와 COPY를 언제 사용해야 하나요?
답변:
COPY는 로컬 파일 또는 디렉토리만 이미지로 복사하므로 일반적으로 선호됩니다. ADD는 URL 또는 로컬 경로에서 tarball 을 자동으로 추출하는 것과 같은 추가 기능이 있지만, 신중하게 관리하지 않으면 예기치 않은 동작이나 보안 위험을 초래할 수 있습니다.
Docker 이미지를 태그하는 방법은 무엇이며 태깅은 왜 중요한가요?
답변:
docker build -t <image_name>:<tag> . 또는 docker tag <source_image>:<source_tag> <target_image>:<target_tag>를 사용하여 이미지를 태그합니다. 태깅은 이미지 버전 관리, 다른 빌드 (예: latest, dev, v1.0) 식별 및 레지스트리로 푸시하는 데 중요합니다.
WORKDIR 지시문은 무엇에 사용되나요?
답변:
WORKDIR 지시문은 Dockerfile 에서 해당 지침 다음에 오는 모든 RUN, CMD, ENTRYPOINT, COPY 또는 ADD 지침에 대한 작업 디렉토리를 설정합니다. 컨테이너 내의 파일 시스템을 구성하고 기본 경로를 제공하여 후속 명령을 단순화하는 데 도움이 됩니다.
컨테이너 오케스트레이션 (Docker Compose & Swarm)
Docker Compose 란 무엇이며 언제 사용하나요?
답변:
Docker Compose 는 다중 컨테이너 Docker 애플리케이션을 정의하고 실행하기 위한 도구입니다. YAML 파일을 사용하여 애플리케이션의 서비스, 네트워크 및 볼륨을 구성한 다음 단일 명령 (docker compose up) 으로 모든 것을 시작합니다. 로컬 개발 환경 및 테스트에 이상적입니다.
docker-compose.yml 파일의 주요 구성 요소를 설명해 주세요.
답변:
docker-compose.yml 파일은 일반적으로 services(웹 서버, 데이터베이스와 같은 애플리케이션 구성 요소 정의), networks(서비스 간 통신용), volumes(영구 데이터 저장용) 을 포함합니다. 각 서비스는 이미지, 포트, 환경 변수 및 종속성을 지정합니다.
Docker Compose 를 사용하여 서비스를 확장하는 방법은 무엇인가요?
답변:
Compose 는 주로 단일 호스트 환경용이지만, docker compose up에 --scale 플래그를 사용하여 서비스를 확장할 수 있습니다. 예를 들어, docker compose up --scale web=3은 'web' 서비스의 세 인스턴스를 시작합니다. 진정한 분산 확장을 위해서는 Docker Swarm 또는 Kubernetes 가 사용됩니다.
Docker Swarm 이란 무엇이며 Docker Compose 와 어떻게 다른가요?
답변:
Docker Swarm 은 Docker 엔진 클러스터를 관리하기 위한 Docker 의 네이티브 컨테이너 오케스트레이션 솔루션입니다. Compose 는 단일 호스트에서 다중 컨테이너 앱을 정의하고 실행하기 위한 것이고, Swarm 은 이러한 애플리케이션을 여러 호스트 (노드) 에 걸쳐 내결함성 방식으로 배포하고 확장할 수 있도록 합니다.
Docker Swarm 컨텍스트에서 '매니저' 및 '워커' 노드의 역할을 설명해 주세요.
답변:
매니저 노드는 원하는 상태 유지, 작업 스케줄링 및 서비스 검색과 같은 클러스터 관리 작업을 처리합니다. 워커 노드는 매니저 노드로부터 작업을 받아 실행하며 실제 컨테이너를 실행합니다. 고가용성을 위해 Swarm 은 여러 매니저 노드를 가져야 합니다.
Docker Swarm 을 초기화하고 노드를 추가하는 방법은 무엇인가요?
답변:
docker swarm init을 사용하여 매니저 노드에서 Swarm 을 초기화합니다. 이 명령은 조인 토큰을 출력합니다. 워커 노드를 추가하려면 각 워커에서 docker swarm join --token <token> <manager-ip>:<port>를 실행합니다. 매니저는 다른 조인 토큰으로 유사하게 추가할 수 있습니다.
Docker Swarm 컨텍스트에서 '서비스'란 무엇인가요?
답변:
Docker Swarm 에서 '서비스'는 Swarm 에서 실행하려는 작업의 정의입니다. 사용할 Docker 이미지, 실행할 복제본 수, 노출할 포트 및 기타 배포 구성을 정의합니다. Swarm 은 원하는 수의 서비스 복제본이 항상 실행되도록 보장합니다.
Docker Swarm 은 서비스 검색 및 로드 밸런싱을 어떻게 처리하나요?
답변:
Docker Swarm 은 내장된 DNS 기반 서비스 검색 기능을 갖추고 있어 서비스가 이름으로 서로를 찾을 수 있습니다. 또한 요청이 복제본을 실행하지 않는 노드에 도달하더라도 서비스의 모든 정상 복제본에 요청을 분산하는 내부 로드 밸런싱 (라우팅 메시) 을 제공합니다.
Docker Swarm 에서 '롤링 업데이트' 개념을 설명해 주세요.
답변:
롤링 업데이트를 사용하면 다운타임 없이 서비스를 새 버전으로 업데이트할 수 있습니다. Swarm 은 새 컨테이너가 정상 상태가 될 때까지 충분한 수의 이전 컨테이너가 계속 실행되도록 보장하면서 복제본을 점진적으로 업데이트하여 이전 컨테이너를 하나씩 또는 배치로 교체합니다.
Kubernetes 대신 Docker Swarm 을 선택하거나 그 반대의 경우를 언제 선택해야 하나요?
답변:
더 간단하고 네이티브한 Docker 오케스트레이션, 더 쉬운 설정, 그리고 복잡성이 덜 필요한 경우 Docker Swarm 을 선택하십시오. 매우 복잡하고 대규모 배포, 자동 확장, 자체 복구와 같은 고급 기능 및 더 광범위한 생태계를 필요로 하는 경우 Kubernetes 를 선택하십시오. 종종 더 높은 복잡성과 더 가파른 학습 곡선의 비용이 발생합니다.
Docker 의 네트워킹 및 스토리지
Docker 에서 사용 가능한 기본 네트워크 드라이버와 주요 사용 사례를 설명해 주세요.
답변:
Docker 는 여러 기본 네트워크 드라이버를 제공합니다: bridge(독립 실행형 컨테이너의 기본값, 격리된 네트워크), host(컨테이너가 호스트의 네트워크 스택을 공유, 격리 없음), none(컨테이너에 네트워크 인터페이스 없음). overlay는 Swarm 에서 다중 호스트 통신에 사용되며, macvlan은 컨테이너에 MAC 주소를 할당하여 네트워크에서 물리적 장치처럼 보이게 합니다.
Docker 에서 사용자 정의 브리지 네트워크의 목적은 무엇이며 기본 브리지 네트워크와 어떻게 다른가요?
답변:
사용자 정의 브리지 네트워크는 기본 브리지 네트워크에 비해 더 나은 격리, 이름으로 컨테이너 간 자동 DNS 확인 및 더 쉬운 포트 매핑 관리를 제공합니다. 사용자 정의 브리지의 컨테이너는 호스트에서 명시적인 포트 매핑 없이 서비스 이름을 사용하여 서로 통신할 수 있습니다.
실행 중인 컨테이너를 기존 사용자 정의 네트워크에 연결하는 방법은 무엇인가요?
답변:
docker network connect 명령을 사용하여 실행 중인 컨테이너를 기존 사용자 정의 네트워크에 연결할 수 있습니다. 예: docker network connect my_network my_container. 이를 통해 컨테이너는 해당 네트워크의 다른 컨테이너와 통신할 수 있습니다.
Docker 에서 사용 가능한 다양한 유형의 스토리지와 각각을 언제 사용해야 하는지 설명해 주세요.
답변:
Docker 는 volumes, bind mounts, tmpfs mounts를 제공합니다. Volumes 는 영구 데이터에 대한 선호되는 방법으로, Docker 에서 관리되며 데이터베이스에 이상적입니다. Bind mounts 는 호스트 경로를 컨테이너 경로에 직접 연결하며, 개발 또는 구성 파일에 유용합니다. Tmpfs mounts 는 호스트 메모리에 데이터를 저장하며, 비영구적이고 민감한 데이터에 적합합니다.
Docker 볼륨이란 무엇이며 바인드 마운트보다 어떤 장점이 있나요?
답변:
Docker 볼륨은 Docker 컨테이너에서 생성되고 사용되는 데이터를 영구적으로 저장하는 권장 방법입니다. Docker 에서 완전히 관리되므로 백업, 마이그레이션 및 관리가 더 쉽습니다. 또한 볼륨은 바인드 마운트보다 성능이 뛰어나며, 특히 I/O 집약적인 워크로드의 경우 여러 운영 체제에서 작동합니다.
명명된 Docker 볼륨을 생성하고 사용하는 방법은 무엇인가요?
답변:
명명된 볼륨은 docker volume create my_data를 사용하여 생성할 수 있습니다. 컨테이너와 함께 사용하려면 컨테이너 생성 시 -v 플래그로 지정합니다: docker run -d -v my_data:/app/data my_image. 이렇게 하면 my_data 볼륨이 컨테이너 내부의 /app/data에 마운트됩니다.
Docker 스토리지에서 'copy-on-write' 메커니즘 개념을 설명해 주세요.
답변:
Copy-on-write (CoW) 메커니즘은 Docker 의 이미지 레이어에서 사용됩니다. 컨테이너가 시작되면 변경 불가능한 이미지 레이어 위에 얇은 쓰기 가능한 레이어를 받습니다. 컨테이너에서 발생하는 모든 변경 사항은 이 최상위 레이어에만 기록되며, 하위 이미지 레이어는 그대로 유지됩니다. 이는 스토리지를 최적화하고 여러 컨테이너가 동일한 기본 이미지를 효율적으로 공유할 수 있도록 합니다.
Docker 에서 네트워크 세부 정보 또는 볼륨 정보를 검사하는 방법은 무엇인가요?
답변:
네트워크 세부 정보를 검사하려면 docker network inspect <network_name_or_id>를 사용합니다. 이는 연결된 컨테이너, 서브넷 및 게이트웨이를 포함한 포괄적인 정보를 제공합니다. 볼륨 정보의 경우 docker volume inspect <volume_name>을 사용하여 마운트 지점, 드라이버 및 기타 메타데이터를 표시합니다.
브리지 네트워크 드라이버 대신 호스트 네트워크 드라이버를 선택하는 경우는 언제인가요?
답변:
최대 네트워크 성능이 필요하거나 포트 매핑 없이 호스트 네트워크 서비스에 직접 액세스해야 하는 경우 host 네트워크 드라이버를 선택합니다. 이는 종종 성능이 중요한 애플리케이션에 사용되거나 컨테이너가 호스트 포트에 직접 바인딩해야 하는 경우 Docker 의 네트워크 스택을 우회합니다.
Docker 에서 스토리지를 관리하기 위해 -v 플래그에 비해 --mount 플래그의 중요성은 무엇인가요?
답변:
--mount 플래그는 스토리지 (볼륨, 바인드 마운트, tmpfs 마운트) 를 관리하기 위한 더 새롭고 명시적이며 선호되는 구문입니다. 명확성을 위해 키 - 값 쌍을 사용하여 마운트 유형과 옵션을 더 쉽게 읽고 이해할 수 있습니다. -v 플래그는 소스 경로에 따라 볼륨인지 바인드 마운트인지 모호할 수 있는 축약형입니다.
시나리오 기반 및 문제 해결 질문
Docker 컨테이너는 실행 중이지만 내부 애플리케이션에 액세스할 수 없습니다. 이 문제를 해결하기 위해 어떤 첫 단계를 취하시겠습니까?
답변:
먼저 애플리케이션 오류를 확인하기 위해 docker logs <container_id>를 확인합니다. 그런 다음 docker ps로 포트 매핑을 확인하여 호스트 포트가 올바르게 노출되었는지 확인합니다. 마지막으로 docker exec -it <container_id> bash를 사용하여 컨테이너에 들어가 애플리케이션 프로세스가 실행 중이고 예상 포트에서 수신 대기 중인지 확인합니다 (예: netstat -tulnp).
Docker 컨테이너가 시작 직후 계속 다시 시작됩니다. 일반적인 원인은 무엇이며 어떻게 조사하시겠습니까?
답변:
일반적인 원인으로는 애플리케이션의 엔트리포인트 스크립트 오류, 누락된 종속성 또는 프로세스를 종료시키는 처리되지 않은 예외가 있습니다. 충돌 전에 출력을 보기 위해 docker logs <container_id>를 사용하고 RestartCount 및 ExitCode를 확인하기 위해 docker inspect <container_id>를 사용합니다.
Docker 이미지를 빌드하려고 하지만 'command not found' 오류로 인해 RUN 명령 중에 실패합니다. 이 문제를 어떻게 디버깅하시겠습니까?
답변:
이는 일반적으로 명령이 기본 이미지에 없거나 이전 RUN 단계에서 올바르게 설치되지 않았음을 의미합니다. 실패하는 명령 앞에 echo 문을 추가하여 경로를 확인하거나, RUN 명령을 sh -c 'set -x; <original_command>'로 일시적으로 변경하여 명령 실행 세부 정보를 확인합니다. 또는 실패하는 레이어까지 빌드한 다음 해당 중간 이미지를 docker run하여 대화식으로 디버깅합니다.
Docker 이미지 크기가 너무 큽니다. 이미지 크기를 줄이기 위해 어떤 전략을 사용하시겠습니까?
답변:
빌드 시간 종속성과 런타임 아티팩트를 분리하기 위해 다단계 빌드 (multi-stage builds) 를 사용합니다. 또한 더 작은 기본 이미지 (예: Alpine) 를 선택하고, 불필요한 파일과 캐시를 제거하며, 레이어를 최소화하기 위해 &&를 사용하여 RUN 명령을 결합합니다. 관련 없는 파일을 제외하기 위해 .dockerignore를 사용하는 것도 중요합니다.
여러 Docker 컨테이너 간에 데이터를 공유해야 합니다. 옵션은 무엇이며 각 옵션을 언제 선택하시겠습니까?
답변:
옵션에는 Docker 볼륨, 바인드 마운트 및 공유 네트워크 스토리지가 있습니다. Docker 볼륨은 영구 데이터 및 데이터 수명 주기 관리에 선호되며, 특히 데이터베이스에 적합합니다. 바인드 마운트는 개발에 좋으며 호스트 파일 변경 사항이 즉시 반영되도록 합니다. 공유 네트워크 스토리지 (예: NFS) 는 여러 호스트에 걸쳐 공유 액세스가 필요한 분산 애플리케이션을 위한 것입니다.
Docker 컨테이너가 너무 많은 CPU/메모리를 소비합니다. 문제의 원인을 어떻게 파악하고 문제를 완화하시겠습니까?
답변:
docker stats를 사용하여 실시간 리소스 사용량을 모니터링합니다. 특정 컨테이너가 문제인 경우 docker exec를 사용하여 컨테이너에 들어가 top 또는 htop과 같은 도구를 사용하여 프로세스를 식별합니다. 완화에는 애플리케이션 최적화, docker run 중에 리소스 제한 (--cpus, --memory) 설정 또는 서비스 확장 등이 포함됩니다.
Docker 이미지를 업데이트했지만 docker run은 여전히 이전 버전을 시작합니다. 무슨 일인가요?
답변:
이는 일반적으로 사용 중인 이미지 태그 (예: myimage:latest) 가 로컬에서 업데이트되지 않았음을 의미합니다. 먼저 docker pull myimage:latest를 실행하여 최신 이미지가 다운로드되었는지 확인합니다. 문제가 지속되면 docker images로 이미지 ID 를 확인하여 올바른 이미지를 가져오고 있는지 확인합니다.
Docker 데몬 자체가 다시 시작되거나 호스트 머신이 재부팅될 때 Docker 컨테이너가 자동으로 다시 시작되도록 하려면 어떻게 해야 합니까?
답변:
컨테이너를 실행할 때 --restart unless-stopped 또는 --restart always와 같은 재시작 정책을 사용합니다. unless-stopped는 컨테이너가 명시적으로 중지되지 않는 한 다시 시작하고, always는 수동으로 중지된 경우에도 이전 상태에 관계없이 항상 다시 시작합니다.
동일한 호스트에 있는 두 Docker 컨테이너 간에 네트워크 연결 문제가 발생합니다. 이 문제를 진단하기 위해 어떤 단계를 취하시겠습니까?
답변:
먼저 docker inspect <container_id>를 사용하여 두 컨테이너가 동일한 Docker 네트워크에 있는지 확인합니다. 그런 다음 컨테이너 이름 또는 IP 주소를 사용하여 한 컨테이너에서 다른 컨테이너로 ping 을 시도합니다. 호스트 및 컨테이너 내의 방화벽 규칙을 확인하고 포트를 노출하는 경우 포트 충돌이 없는지 확인합니다.
Docker 컨테이너는 실행 중이지만 내부의 특정 디렉터리에 쓸 수 없습니다. 문제는 무엇일 수 있습니까?
답변:
이는 종종 권한 문제입니다. 컨테이너에 docker exec를 사용하여 들어가 ls -ld <directory>를 사용하여 디렉터리의 소유권 및 권한을 확인합니다. 컨테이너 내부에서 애플리케이션을 실행하는 사용자는 쓰기 액세스 권한이 없을 수 있습니다. Dockerfile 또는 엔트리포인트 스크립트에서 chmod 또는 chown으로 권한을 조정하면 이 문제를 해결할 수 있습니다.
Docker 보안 및 모범 사례
Docker 컨테이너 사용 시 주요 보안 문제는 무엇인가요?
답변:
주요 문제점으로는 컨테이너 탈출 (container escape), 안전하지 않은 이미지, 잘못 구성된 데몬, 권한 상승, 서비스 거부 (denial of service), 민감한 데이터 노출 등이 있습니다. 호스트, 이미지, 컨테이너 및 네트워크를 안전하게 유지하는 것이 중요합니다.
Docker 이미지의 공격 표면을 최소화하려면 어떻게 해야 하나요?
답변:
최소한의 기본 이미지 (예: Alpine) 를 사용하고, 불필요한 패키지 및 종속성을 제거하며, 개발 도구 설치를 피하고, 빌드 시간 종속성과 런타임 아티팩트를 분리하기 위해 다단계 빌드를 사용합니다.
컨테이너를 root 로 실행하는 것이 좋지 않은 이유는 무엇이며 대안은 무엇인가요?
답변:
root 로 실행하면 과도한 권한이 부여되어 컨테이너 탈출 또는 권한 상승의 위험이 증가합니다. 대안은 컨테이너 내부에 전용 비-root 사용자를 생성하고 해당 사용자로 프로세스를 실행하는 것입니다.
Docker 맥락에서 최소 권한 원칙을 설명해 주세요.
답변:
이는 컨테이너 또는 프로세스가 기능하는 데 필요한 최소한의 권한만 부여하는 것을 의미합니다. 여기에는 기능 제한, --privileged 플래그 사용 방지, 볼륨 마운트 제한 및 비-root 사용자로 실행하는 것이 포함됩니다.
Docker Content Trust 와 Docker Notary 는 무엇이며 보안을 어떻게 강화하나요?
답변:
Docker Content Trust (DCT) 는 이미지 게시자가 이미지를 서명하고 소비자가 이미지의 무결성과 인증을 확인할 수 있도록 합니다. Notary 는 암호화 방식으로 안전한 게시 및 검증을 제공하는 기본 기술입니다.
Docker 컨테이너에서 민감한 정보 (예: API 키, 비밀번호) 를 안전하게 관리하려면 어떻게 해야 하나요?
답변:
Dockerfile 에 비밀 정보를 하드코딩하거나 버전 관리에 커밋하지 마십시오. Docker Secrets(Swarm 용) 또는 Kubernetes Secrets(Kubernetes 용), 환경 변수 (주의 필요) 또는 HashiCorp Vault 와 같은 외부 비밀 관리 도구를 사용합니다.
Docker 의 기본 seccomp 프로필 목적은 무엇인가요?
답변:
기본 seccomp(secure computing mode) 프로필은 컨테이너가 커널에 대해 수행할 수 있는 시스템 호출을 제한합니다. 이는 악의적이거나 불필요한 시스템 호출을 방지하여 공격 표면을 크게 줄입니다.
Docker 이미지의 취약점을 어떻게 스캔하나요?
답변:
Clair, Trivy, Anchore Engine 또는 Docker Scout 와 같은 취약점 스캔 도구를 사용합니다. 이러한 도구는 설치된 패키지 및 종속성의 알려진 취약점에 대해 이미지 레이어를 분석하여 실행 가능한 보고서를 제공합니다.
Docker 데몬을 안전하게 보호하기 위한 몇 가지 모범 사례는 무엇인가요?
답변:
Docker 소켓에 대한 액세스를 제한하고, 원격 액세스를 위해 TLS 를 활성화하고, 적절한 로깅을 구성하고, 데몬 및 Docker 엔진을 최신 상태로 유지하며, 신뢰할 수 없는 네트워크에 데몬을 노출하지 않도록 합니다.
Docker 이미지와 Docker 엔진을 정기적으로 업데이트해야 하는 이유는 무엇인가요?
답변:
정기적인 업데이트는 기본 이미지와 Docker 엔진 자체 모두에 대한 최신 보안 패치 및 버그 수정을 확보하도록 합니다. 이는 알려진 취약점을 완화하고 전반적인 시스템 안정성을 향상시킵니다.
고급 Docker 주제 및 성능 최적화
Docker Overlay Networks 의 개념과 사용 시점에 대해 설명해 주세요.
답변:
Docker Overlay Networks 는 서로 다른 Docker 데몬 호스트에서 실행되는 Docker 컨테이너 간의 통신을 가능하게 합니다. 이는 Docker Swarm 또는 Kubernetes 클러스터와 같은 다중 호스트 컨테이너 오케스트레이션에 중요하며, 복잡한 라우팅 구성 없이 서비스가 노드 전반에 걸쳐 원활하게 통신할 수 있도록 합니다.
Docker Content Trust (DCT) 의 목적과 작동 방식은 무엇인가요?
답변:
Docker Content Trust (DCT) 는 이미지 게시자에 대한 암호화 검증 및 무결성을 제공합니다. 레지스트리에서 가져온 이미지가 신뢰할 수 있는 게시자에 의해 서명되었는지 확인하여 변조되거나 승인되지 않은 이미지 사용을 방지합니다. 이는 Notary 를 사용하여 이미지 매니페스트를 서명하고 검증하는 방식으로 작동합니다.
Docker 컨테이너가 소비할 수 있는 리소스 (CPU, 메모리) 를 어떻게 제한할 수 있나요?
답변:
리소스 제한은 docker run 플래그를 사용하여 설정할 수 있습니다. CPU 의 경우 --cpus (예: --cpus='1.5') 또는 --cpu-shares를 사용합니다. 메모리의 경우 --memory (예: --memory='2g') 및 --memory-swap을 사용합니다. 이러한 설정은 단일 컨테이너가 호스트 리소스를 독점하는 것을 방지합니다.
Dockerfile 에서 COPY와 ADD의 차이점을 설명해 주세요.
답변:
COPY는 빌드 컨텍스트에서 로컬 파일 또는 디렉터리를 이미지로 복사합니다. ADD는 유사한 기능을 하지만 소스에서 tar 아카이브를 추출하고 URL 에서 파일을 다운로드할 수도 있습니다. 일반적으로 ADD의 추가 기능이 특별히 필요한 경우가 아니라면 명확성과 보안을 위해 COPY가 선호됩니다.
Docker 의 다단계 빌드란 무엇이며 어떤 이점이 있나요?
답변:
다단계 빌드는 단일 Dockerfile 에서 여러 FROM 명령을 사용하며, 각 FROM은 이전 단계의 아티팩트를 폐기할 수 있습니다. 이는 최종적이고 더 작은 런타임 이미지에 필요한 빌드 아티팩트 (예: 컴파일된 바이너리) 만 복사하여 최종 이미지 크기를 크게 줄여 보안 및 배포 속도를 향상시킵니다.
Docker 이미지 크기와 빌드 속도를 어떻게 최적화하나요?
답변:
다단계 빌드 사용, 더 작은 기본 이미지 (예: Alpine) 선택, .dockerignore 활용, RUN 명령 통합을 통해 이미지 크기를 최적화합니다. 레이어 캐싱을 최대화하기 위해 Dockerfile 명령 순서를 지정하고, .dockerignore 파일을 사용하며, 빌드 컨텍스트가 최소화되도록 하여 빌드 속도를 최적화합니다.
Docker 의 스토리지 드라이버와 성능에 미치는 영향에 대해 설명해 주세요.
답변:
Docker 는 레이어를 저장하고 결합하는 방법을 관리하기 위해 스토리지 드라이버 (예: OverlayFS, AUFS, Btrfs) 를 사용합니다. OverlayFS 는 특히 읽기 집약적인 워크로드에 대해 성능과 단순성으로 인해 일반적으로 권장됩니다. 드라이버 선택은 컨테이너 시작 시간, 쓰기 성능 및 전반적인 디스크 I/O 에 영향을 미칩니다.
Docker Swarm Mode 란 무엇이며 Kubernetes 와 어떻게 다른가요?
답변:
Docker Swarm Mode 는 Docker 엔진 클러스터를 관리하기 위한 Docker 의 네이티브 오케스트레이션 도구입니다. Kubernetes 보다 설정 및 사용이 간편하여 소규모 배포 또는 이미 Docker 생태계에 많이 투자한 경우에 적합합니다. Kubernetes 는 더 강력하고 기능이 풍부하며 복잡한 오케스트레이터로, 대규모 프로덕션 등급 배포에 널리 채택되었습니다.
계속 다시 시작되는 Docker 컨테이너를 어떻게 문제 해결하나요?
답변:
먼저 docker logs <container_id>를 사용하여 컨테이너 로그를 확인합니다. 그런 다음 docker inspect <container_id>로 컨테이너 상태를 검사하여 종료 코드와 재시작 정책을 확인합니다. 컨테이너를 대화식으로 실행 (docker run -it ...) 하여 동작을 직접 관찰하거나 컨테이너에 연결 (docker attach) 해 볼 수도 있습니다.
Docker 네트워킹 모드와 사용 사례를 설명해 주세요.
답변:
Docker 는 여러 네트워킹 모드를 제공합니다: bridge(기본값, 컨테이너를 위한 격리된 네트워크), host(컨테이너가 호스트의 네트워크 스택을 공유), none(네트워크 인터페이스 없음), overlay(다중 호스트 통신용). bridge는 단일 호스트 앱에 일반적이고, host는 직접 포트 액세스가 필요한 성능 집약적인 앱에, overlay는 분산 서비스에 사용됩니다.
역할별 질문 (개발자, DevOps, 관리자)
개발자: Docker 이미지를 가능한 한 작게 유지하려면 어떻게 해야 하나요?
답변:
빌드 시간 종속성과 런타임 종속성을 분리하기 위해 다단계 빌드를 사용합니다. 또한 Alpine 과 같은 더 작은 기본 이미지를 활용하고, RUN 명령을 통합하며, 불필요한 파일이나 캐시를 제거합니다.
개발자: .dockerignore 파일의 목적을 설명하고 사용 예시를 제공해 주세요.
답변:
.dockerignore 파일은 .gitignore 와 유사하게 Docker 이미지를 빌드할 때 제외할 파일 및 디렉터리를 지정합니다. 이를 통해 불필요한 파일이 빌드 컨텍스트에 추가되는 것을 방지하여 빌드 속도를 높이고 이미지 크기를 줄입니다. 예시: *.log 또는 node_modules/.
DevOps: Docker 화된 애플리케이션에 대한 CI/CD 파이프라인을 어떻게 구현하시겠습니까?
답변:
CI/CD 도구 (예: Jenkins, GitLab CI, GitHub Actions) 를 사용하여 코드 커밋 시 Docker 이미지를 빌드하고, 테스트를 실행하며, 이미지를 레지스트리로 푸시한 다음, 대상 환경 (예: Kubernetes, Docker Swarm) 에 배포하는 과정을 자동화합니다.
DevOps: Docker 화된 환경에서 비밀 정보 (예: API 키, 데이터베이스 비밀번호) 를 어떻게 처리하나요?
답변:
개발 환경에서는 환경 변수 또는 .env 파일을 사용할 수 있습니다. 프로덕션 환경에서는 안전한 저장 및 주입을 위해 Docker Secrets 또는 Kubernetes Secrets 를 선호합니다. Vault 또는 유사한 비밀 관리 도구를 통합하여 더 고급 시나리오를 처리할 수도 있습니다.
DevOps: 프로덕션 환경에서 Docker 컨테이너의 롤링 업데이트 및 롤백을 위한 전략은 무엇인가요?
답변:
Docker Swarm 또는 Kubernetes 와 같은 오케스트레이션 도구를 사용하며, 이는 새 컨테이너로 이전 컨테이너를 점진적으로 교체하여 롤링 업데이트를 기본적으로 지원합니다. 롤백의 경우, 오케스트레이션 플랫폼의 기능을 활용하여 이전 이미지 태그 또는 배포 구성으로 되돌릴 수 있습니다.
관리자: Docker 컨테이너 및 Docker 데몬의 상태와 성능을 어떻게 모니터링하나요?
답변:
빠른 확인을 위해 docker stats를 사용합니다. 포괄적인 모니터링을 위해 Prometheus 및 Grafana 와 같은 도구와 통합하여 cgroups 및 Docker API 에서 메트릭 (CPU, 메모리, 네트워크 I/O) 을 수집하고 알림을 설정합니다.
관리자: Docker 네트워킹 모드와 각 모드를 사용하는 시점에 대해 설명해 주세요.
답변:
일반적인 모드로는 bridge(기본값, 컨테이너를 위한 격리된 네트워크), host(컨테이너가 호스트의 네트워크 스택을 공유), none(네트워크 인터페이스 없음) 이 있습니다. bridge는 대부분의 애플리케이션에 사용되고, host는 직접 포트 액세스가 필요한 성능 집약적인 앱에, none은 특수 사례 또는 디버깅에 사용됩니다.
관리자: Docker Swarm 이란 무엇이며 Kubernetes 대신 선택하는 경우는 언제인가요?
답변:
Docker Swarm 은 Docker 호스트 클러스터를 관리하기 위한 Docker 의 네이티브 오케스트레이션 도구입니다. 더 간단하고 소규모 배포이거나 최소한의 오버헤드로 빠른 설정을 원할 때 Swarm 을 선택할 것입니다. Kubernetes 보다 학습 및 관리가 더 쉽기 때문입니다.
관리자: Docker 컨테이너의 영구 데이터를 어떻게 관리하나요?
답변:
컨테이너의 수명 주기와 독립적으로 Docker 에서 관리되는 영구 데이터 저장을 위해 Docker 볼륨을 사용합니다. 개발 또는 호스트 파일 시스템 액세스가 필요한 경우 바인드 마운트도 사용할 수 있습니다.
관리자: Docker Compose 를 사용하는 시나리오를 설명해 주세요.
답변:
Docker Compose 를 사용하여 다중 컨테이너 Docker 애플리케이션을 정의하고 실행합니다. 예를 들어, 웹 애플리케이션, 데이터베이스 및 캐싱 서비스로 구성된 로컬 개발 환경을 설정하는 데 사용하며, 이 모든 것은 단일 docker-compose.yml 파일에 정의됩니다.
실용적이고 직접 해보는 도전 과제
빌드 프로세스가 여러 레이어로 인해 매우 느린 Dockerfile 이 있습니다. 빌드 시간과 이미지 크기를 줄이기 위해 Dockerfile 을 어떻게 최적화하시겠습니까?
답변:
최적화를 위해 자주 변경되지 않는 명령어 (예: FROM, RUN apt-get update) 뒤에 자주 변경되는 명령어 (예: 애플리케이션 코드 COPY) 를 배치하도록 명령어를 재정렬합니다. 또한 &&를 사용하여 RUN 명령어를 통합하여 레이어 수를 줄이고, 동일한 RUN 명령어 내에서 불필요한 파일 (rm -rf /var/lib/apt/lists/*) 을 제거합니다.
작고 프로덕션 준비가 된 Docker 이미지를 만들기 위해 Go 애플리케이션에 대한 다단계 빌드를 어떻게 설정하는지 설명해 주세요.
답변:
첫 번째 단계에서는 Go 빌더 이미지를 사용하여 애플리케이션을 컴파일합니다. 두 번째 단계에서는 scratch 또는 alpine과 같은 최소 기본 이미지를 사용하고 첫 번째 단계에서 컴파일된 바이너리만 복사합니다. 이렇게 하면 빌드 도구와 종속성을 제외하여 최종 이미지 크기를 크게 줄일 수 있습니다.
데이터베이스 컨테이너 (예: PostgreSQL) 와 해당 데이터베이스에 연결되는 애플리케이션 컨테이너를 실행해야 합니다. 두 컨테이너가 통신하도록 하고 컨테이너 재시작 시 데이터베이스 데이터가 유지되도록 하려면 어떻게 해야 하나요?
답변:
Docker 네트워크 (예: docker network create my-app-net) 를 사용하여 두 컨테이너를 연결합니다. 데이터 영속성을 위해 Docker 볼륨 (docker volume create pg-data) 을 사용하고 이를 데이터베이스 컨테이너의 데이터 디렉터리 (-v pg-data:/var/lib/postgresql/data) 에 마운트합니다.
Docker 컨테이너가 빠르게 사라지는 오류 메시지와 함께 시작되지 않고 있습니다. 이 문제를 어떻게 디버깅하시겠습니까?
답변:
docker logs <container_id_or_name>을 사용하여 컨테이너의 출력을 확인합니다. 즉시 종료되는 경우, 컨테이너를 검사할 수 있도록 Dockerfile 의 CMD 또는 ENTRYPOINT에 tail -f /dev/null 또는 sleep infinity 명령어를 추가하거나 (docker run으로 재정의) 컨테이너를 실행한 다음 docker exec로 컨테이너에 진입합니다.
다중 서비스 애플리케이션에 대한 docker-compose.yml 파일이 있습니다. 특정 서비스 (예: 웹 서버) 를 여러 인스턴스로 실행하도록 어떻게 확장하시겠습니까?
답변:
docker-compose up --scale web=3 명령어를 사용합니다. 여기서 web은 서비스 이름이고 3은 원하는 인스턴스 수입니다. 그러면 Docker Compose 는 'web' 서비스에 대해 세 개의 별도 컨테이너를 시작하며, 리버스 프록시가 있는 경우 종종 로드 밸런싱이 적용됩니다.
Dockerfile 에서 COPY와 ADD의 차이점과 각각을 사용하는 시점에 대해 설명해 주세요.
답변:
COPY는 빌드 컨텍스트에서 로컬 파일 또는 디렉터리를 이미지로 복사합니다. ADD는 추가 기능이 있습니다: tar 파일을 추출하고 URL 에서 파일을 다운로드할 수 있습니다. 일반적으로 명확성과 예측 가능성을 위해 COPY가 선호되며, ADD는 추가 기능이 특별히 필요한 경우에만 사용합니다.
디스크 공간을 확보하기 위해 사용되지 않는 Docker 리소스 (이미지, 컨테이너, 볼륨, 네트워크) 를 어떻게 정리하시겠습니까?
답변:
docker system prune을 사용합니다. 이 명령어는 중지된 모든 컨테이너, 모든 댕글링 이미지, 모든 댕글링 빌드 캐시를 제거하고 선택적으로 모든 사용되지 않는 볼륨 (-v) 및 네트워크를 제거합니다. 디스크 공간을 회수하는 포괄적인 방법입니다.
실행 중인 컨테이너에 민감한 정보 (API 키 등) 를 Dockerfile 에 하드코딩하거나 버전 관리에 커밋하지 않고 전달해야 합니다. 이를 안전하게 수행하려면 어떻게 해야 하나요?
답변:
단일 컨테이너의 경우 docker run의 -e 플래그를 통해 환경 변수를 사용합니다. Docker Compose 또는 Swarm 의 경우 Docker secrets 를 사용합니다. 이를 통해 이미지에 포함시키거나 일반 텍스트로 노출하지 않고 런타임에 민감한 데이터를 주입할 수 있습니다.
Docker 컨테이너가 호스트 머신의 파일에 액세스해야 합니다. 어떻게 달성할 수 있나요?
답변:
바인드 마운트를 사용합니다. 예를 들어, docker run -v /host/path:/container/path my-image와 같이 사용합니다. 이는 호스트 파일 시스템의 디렉터리를 컨테이너에 직접 마운트하여 파일에 대한 양방향 액세스를 허용합니다.
애플리케이션 코드를 변경했습니다. 실행 중인 Docker 컨테이너를 이러한 변경 사항으로 어떻게 업데이트하나요?
답변:
실행 중인 컨테이너의 코드를 직접 업데이트할 수는 없습니다. 새 코드로 Docker 이미지를 다시 빌드 (docker build) 한 다음, 이전 컨테이너를 중지 (docker stop) 하고, 제거 (docker rm) 한 다음, 마지막으로 업데이트된 이미지에서 새 컨테이너를 시작 (docker run) 해야 합니다. 오케스트레이션된 환경의 경우 이는 롤링 업데이트를 통해 처리됩니다.
요약
인터뷰를 위해 Docker 를 마스터하는 것은 현대 소프트웨어 개발에 대한 헌신과 이해를 증명하는 것입니다. 이 문서에 설명된 질문들을 철저히 준비함으로써, 여러분은 지식을 효과적으로 설명할 수 있을 뿐만 아니라 컨테이너화에 대한 실질적인 이해를 심화시켰습니다. 이러한 준비는 잠재적 고용주에게 여러분의 가치를 입증하고 원하는 역할을 확보하기 위한 중요한 단계입니다.
기술 환경은 끊임없이 진화한다는 것을 기억하십시오. Kubernetes 와 같은 새로운 Docker 기능, 모범 사례 및 관련 기술을 계속 탐색하십시오. 지속적인 학습을 수용하고, 프로젝트에 기여하며, 호기심을 유지하십시오. 성장에 대한 여러분의 헌신은 역동적인 DevOps 및 클라우드 네이티브 컴퓨팅 세계에서 계속해서 높은 수요를 받는 전문가로 남도록 보장할 것입니다. 여러분의 여정에 행운을 빕니다!
