데이터의 영속성과 데이터의 안정성 : 컨테이너가 삭제되거나 재시작될 때, 컨테이너 내부의 파일 시스템은 사라질 수 있다. 그러나 Volume은 컨테이너와 별도로 저장되기 때문에 데이터를 안전하게 유지할 수 있다.
데이터 공유의 용이성 : 여러 컨테이너가 동일한 Volume을 마운트하여 데이터를 공유하거나 협업할 수 있다. 이는 여러 서비스가 같은 데이터에 접근해야 할 때 유용하다.
데이터 관리와 백업의 편리성 : Volume은 Docker의 관리 하에 있으므로, 데이터를 백업하거나 복원할 때 더 편리하게 작업할 수 있다. 그리고 데이터가 컨테이너 외부에 저장되기 때문에 데이터와 컨테이너의 생명 주기를 분리할 수 있다. 또한 다른 컴퓨터로 데이터를 옮기기 편리하다.
호스트 시스템과의 상호작용을 단순화 : Volume을 사용하면 컨테이너와 호스트 간에 파일을 쉽게 공유하거나 컨테이너의 데이터를 호스트 시스템에 저장할 수 있다.
속도 향항 : 경우에 따라 볼륨을 쓰는 게 데이터를 더 빠르게 처리가능, 특히 많은 양의 데이터를 다룰 때 유용하다.
Bind Mount
호스트 시스템의 특정 디렉토리를 컨테이너의 파일 시스템에 직접 연결하는 방식이다. 사용의 예로는 호스트 시스템의 /path/on/host 디렉토리를 컨테이너의 /path/in/container에 마운트할 때 사용한다.
호스트 시스템과 컨테이너 간의 파일 및 디렉토리 구조가 직접 연결된다. 컨테이너에서 파일을 수정하면 호스트에서도 실시간으로 변경이 반영된다. 주로 호스트와 컨테이너 간에 데이터나 구성 파일을 공유할 때 유용하다.
Tmpfs Mount
메모리 기반의 파일 시스템을 컨테이너에 마운트하는 방식이다. 이 파일 시스템은 휘발성으로, 컨테이너가 종료되면 데이터가 사라진다. 사용 예로는 컨테이너의 /path/in/container 디렉토리에 메모리 기반 파일 시스템을 마운트할 때 사용한다.
디스크 대신 메모리에 저장되므로 I/O 성능이 매우 빠르며, 컨테이너가 종료되면 데이터가 사라지기 때문에 임시 데이터나 캐시 데이터 저장에 적합하다. 따라서 메모리 사용량을 관리할 필요가 있다.
Docker 네트워크 모델인 CNM은 Docker의 네트워크 기능을 정의하는 구조적 모델로, 네트워크의 설계와 구현을 표준화하고 유연하게 지원하기 위해 고안되었다. CNM은 Docker 네트워크의 기본 개념과 아키텍처를 설명하며, 네트워크를 설정하고 관리하는 데 필요한 구성 요소를 정의한다.
샌드박스
샌드박스는 컨테이너를 외부 세계로부터 완전히 분리시킨다. 바깥에서 들어오는 네트워크 연결은 이 샌드박스 안의 컨테이너로는 들어올 수 없으며 엔드포인트를 추가하면 소통가능하다.
Endpoint
컨테이너와 네트워크 간의 연결 지점을 정의한다. 각 컨테이너는 하나 이상의 Endpoint를 가지며, 이를 통해 네트워크에 연결된다. Endpoint는 IP 주소와 MAC 주소를 포함하여 컨테이너가 네트워크에서 어떻게 식별되는지를 결정한다.
Network
네트워크는 컨테이너가 연결될 수 있는 가상의 네트워크 공간을 정의한다. 네트워크는 컨테이너 간의 통신을 가능하게 하며, IP 주소와 네트워크 정책을 관리한다.
Network Driver
네트워크의 구현 방식을 결정하는 드라이버이다. 드라이버는 네트워크의 기능을 제공하며, 다양한 드라이버를 통해 Bridge, Overlay, Macvlan 등 여러 네트워크 유형을 지원한다.
Network Plugin
사용자 정의 네트워크 드라이버를 지원하기 위한 플러그인 시스템이다. 네트워크 플러그인을 통해 Docker는 기본 제공 드라이버 외에도 사용자 정의 네트워크 구현을 지원한다. 이를 통해 더 많은 네트워크 요구사항을 충족할 수 있다.
Docker 컨테이너는 애플리케이션과 그 실행 환경을 격리하여 패키징하는 데 사용되는 가벼운 가상화 기술이다. 컨테이너는 애플리케이션과 그 의존성(라이브러리, 설정 파일 등)을 함께 묶어서, 일관된 실행 환경을 제공한다. 이로 인해 애플리케이션이 어디에서나 동일한 방식으로 실행될 수 있다.
격리(Isolation)
컨테이너는 서로 독립적인 실행 환경을 제공하여, 하나의 컨테이너에서 발생하는 문제나 오류가 다른 컨테이너나 호스트 시스템에 영향을 미치지 않도록 한다.
경량화(Lightweight)
컨테이너는 가상 머신과 달리 운영 체제의 커널을 공유하기 때문에, 상대적으로 적은 자원으로 실행된다. 따라서 빠른 시작 시간과 낮은 오버헤드를 제공한다.
이식성(Portability)과 플랫폼 독립성
컨테이너는 애플리케이션과 그 의존성을 함께 패키징하기 때문에, 개발 환경, 테스트 환경, 프로덕션 환경 등 어떤 환경에서도 동일하게 실행될 수 있다.
일관성(Consistency)
애플리케이션이 컨테이너 내에서 실행되면, 의존성 문제나 환경 설정 문제를 최소화할 수 있다. 이는 개발자와 운영팀 간의 일관된 환경을 보장한다.
빠른 배포(Fast Deployment)
컨테이너는 빠르게 시작할 수 있어, 애플리케이션의 배포와 확장을 신속하게 할 수 있다.
개발 및 테스트와 CI/CD
개발자들은 컨테이너를 사용하여 애플리케이션의 개발 및 테스트 환경을 빠르게 설정하고, 일관된 환경에서 작업할 수 있다. 또한 컨테이너는 지속적인 통합 및 배포(CI/CD) 파이프라인에서 테스트와 배포를 자동화하는 데 사용된다.
마이크로서비스 아키텍처
각 마이크로서비스를 독립된 컨테이너로 실행하여, 서비스 간의 의존성을 최소화하고, 서비스를 독립적으로 관리할 수 있으므로 마이크로 아키텍처에 주로 사용된다. 또한 이런 이유로 devOps에 유용하다.
하이브리드, 멀티클라우드
컨테이너는 어디서든 잘 돌아간다. 노트북이든, 회사 데이터 센터든, 클라우드든. 이런 점 때문에 여러 클라우드 서비스를 섞어 쓰는 하이브리드나 멀티클라우드 환경에서도 잘 맞는다.
클라우드 마이그레이션
많은 기업이 클라우드로 옮겨가면서 앱을 컨테이너로 바꾸는 방법을 많이 쓴다. 이렇게 하면 앱을 클라우드로 쉽게 옮길 수 있고, 관리도 편하다.