Docker는 Docker, Inc. ( https://www.docker.com/ )가 개발 중인 컨테이너 환경을 제공하기 위한 소프트웨어 입니다.
Docker는 어플리케이션이 움직이는 환경을 컨테이너라는 단위로 가상화하고, 이 컨테이너형 가상화뿐만 아니라 컨테이너의 베이스가 되는 이미지를 효율적으로 만드는( 빌드 ) 기능과 이미지를 배포하기 위한 구조( Docker Hub과 같은 저장소 서비스 )도 갖추고 있는 것이 특징입니다.
여기에서는 Docker의 구조에 대해, 특히 컨테이너형 가상화와 이미지에 관한 부분에 대해 간략하게 설명하겠습니다.
1. 컨테이너형 가상화
Dokcer가 제공하는 가상화의 장점 중 하나가 효율성입니다. 효율성은 컨테이너형 가상화라는 기술에 의해 실현되고 있습니다. 지금까지는 가상화의 주류였던 하이퍼바이저형 기술에서는 가상화 환경의 단위가 하드웨어 전체( VirtualBox나 Fusion 등 ) 및 OS 전체( Xen 및 Hyper-V 등 )였습니다.
Windows 또는 MacOS나 Linux 등 다양한 OS를 그대로 움직일 수 있지만, 하이퍼바이저라는 프로그램이 가상화를 위해 개입되어야 했습니다.
하이퍼바이저 사용에 따라 성능 저하가 발생하거나 메모리 혹은 디스크와 같은 리소스를 가상 환경에 확보할 필요가 있어 리소스 소비량이 많아지는 단점이 있었습니다.
이에 비해 Docker는 컨테이너라는 단위로 환경을 가상화 하고 있습니다. 컨테이너의 실체는 호스트 OS상의 프로세스로써 각각 컨텐이너의 형태로 격리된 상태로 움직입니다. 격리된 컨테이너의 프로세스에서 다른 컨테이너나 호스트 환경의 프로세스에 접속할 수 없습니다.
컨테이너에 대해 별도의 루트 디렉터리( 접속 가능한 파일 범위 )이 할당되어 호스트 환경과는 별도의 네트워크와 IP 주소를 할당할 수 있습니다. 또한, 각각의 컨테이너에서 실행되는 프로세스에 대해 사용할 수 있는 호스트 환경의 CPU나 메모리 자원의 제한량을 설정할 수 있습니다.
프로세스 격리는 호스트 OS에서 실행되는 커널 기능이 사용되며, 프로세스의 실행에 따라 하이퍼바이저와 같은 프로그램이 개입하지 않고, 컨테이너마다 커널이라는 OS 기능이 각각 별도로 실행되지 않습니다.
Linux에서 실행 중인 Docker의 경우 프로세스를 격리하기 위해 Linux 커널이 제공하는 cgroups( control groups )이 사용되며, 루트 디렉터리를 격리하는 데 chroot가 사용됩니다.
Docker는 컨테이너 내에서 볼 수 있는 파일은 이미지 형태로 처리되며, 실제로는 호스트 환경의 파일 시스템에서 파일로 추출됩니다.
파일 시스템의 기능( Linux에서는 Aufs와 OverlayFS 및 Device Mapper )을 사용함으로써 동일한 이미지와 함께 실행 중인 컨테이너가 같은 파일에 기록되지 않으면 동일한 파일을 참조합니다.
이러한 이유로 Docker에서 사용하는 컨테이너형 가상화는 하이퍼바이저형 가상화보다 성능이 저하되는 소비 자원이 적다는 장점을 가지고 있습니다.
2. Docker 이미지
Docker에는 불변 인프라( immutable infrastructure )라는 개념이 도입되어 있습니다.
구체적으로는 일단 이미지로 만들어진 환경을 변경하지 않고, 컨테이너가 움직이는 동안은 파일을 변경해도 오리지널 이미지가 변경되지 않습니다.
통상적인 서버 관리에서 행해지는 어플리케이션 이나 패키지의 업데이트도 Docker에서는 그것들이 적용된 이미지를 만들고, 새로운 이미지를 바탕으로 한 컨테이너를 다시 시작하여 수행합니다. 이렇게 함으로써 컨테이너의 구성을 고정화 할 수 있습니다.
또한 정상적인 환경에서 서비스가 실행 중인 상태에서 패키지 설치 등이 실행되지만, Docker 이미지를 빌드할 때는 서비스가 움직이지 않은 상태에서 커맨드 자체만 실행됩니다. 따라서 Docker 이미지 빌드에 필요한 과정은 간단하게 마칠 수 있습니다. 예를 들어 패키지 버전을 최신으로 업데이트 하는 경우를 생각해 봅니다. 이미 서비스가 실행중인 일반적인 환경에서는 업데이트 시 기존 패키지가 이미 설치되어 있는지를 고려하거나, 기존의 설정 파일을 섣불리 변경하지 않는 등의 주의가 필요합니다.
Docker 이미지의 빌드는 항상 이전 단계의 이미지에 변경 사항을 저장하는 형태로 실행되기 때문에 항상 새로운 환경에서 새로운 패키지를 넣는 형태로 실행됩니다. 또한 서비스가 실행되는 시점은 빌드가 아닌 컨테이너가 실행되는 시점이므로 빌드 때 변경된 설정을 다시 읽어 들이거나 재시작하는 과정도 필요 없습니다.
3. Docker를 개발 운영 개선의 솔루션으로 고려하기
Docker를 사용하여 개발 환경과 운영 환경의 차이를 줄일 수 있는 장점을 소개했습니다. 이러한 것들을 발전 시켜 개발과 운영의 흐름을 개선하기 위한 솔루션으로 Docker를 이용할 수도 잇있습니다.
어플리케이션을 컨테이너화함으로써 각가의 환경에서 어플리케이션 고유의 설정 및 프로비저닝을 해야 할 필요가 ( 거의 )없습니다. 이러한 작업 대부분은 OS 내부의 패키지와 파일을 제공함으로써 이미 이미지를 빌드하는 시점에 포함되기 때문입니다.
배포에 필요한 절차나 과정도 새로운 이미지를 취득하여 컨테이너를 실행하면 되기 때문에 프로덕션 환경의 운영 절차도 간소화 할 수 있습니다.
이전의 이미지를 남겨둠으로써, 그 이미지를 사용하여 컨테이너를 실행하는 것만으로도 배포를 롤백할 수 있는 것도 장점입니다.
4. Docker Compose
Docker Compose는 여러 컨테이너로 실행되는 어플리케이션을 정의하고 관리하기 위한 도구입니다. Docker Compose를 사용하여 여러 컨테이너를 프로젝트와 서비스라는 단위로 관리할 수 있습니다.
프로젝트 및 서비스의 설정은 YAML 파일에 의해 정의되고 Docker Compose가 YAML 파일을 읽는 방식으로 컨테이너를 조작합니다.
'Docker' 카테고리의 다른 글
[Docker] 커맨드와 명령 (0) | 2024.03.07 |
---|