Page History

Docker 는 오픈소스 프로젝트 인다. 

Go 언어로 작성된 리눅스 컨테이너 런타임 가상화 오픈 플랫폼으로 리눅스 컨테이너 기술을 자동화 하여 관리 및 유지보스를 용이하게 해준다.

리눅스 컨테이너 기술은 가상화 기술과 비슷한 기술이다. 가상화 기술은 하이퍼바이저란 기술이 반드시 있어야 하며 가상화 기술을 통해 갖춰진 가상화 환경은 호스트를 공유하여 그 위로 각종 OS를 운영하게 해주는 기술이다.

Docker는 하이퍼바이저와 달리 별도 OS를 두지 않고 호스트의 커널을 바로 사용한다.

때문에 리눅스 커널이 작동되는 곳이라면 어느곳에서든 작동한다. 하이퍼바이저 대신 도커 엔진이 올라가는 호스트 와 여러 어플리케이션을 연결해주는 역할을 한다.

따라서 Docker를 사용하면 가상화보다는 내부에서 더 작은 일을 처리하고 어플리케이션을 빠르게 효율적으로 실행할 수 있다.

리눅스 컨테이너는 별도의 CPU와 메모리, 블록 I/O, 네트워크 리소스를 갖추고

호스트 운영체제의 커널을 공유하는, 그 자체로 완전한 실행 환경이다.

일종의 가상머신처럼 느껴지지만

가상머신에 따르는 게스트 운영체제의 무거움과 시작 오버헤드가 없다.

대규모 시스템에서 VM을 실행하는 경우 보통 동일한 OS 인스턴스와

부팅 볼륨이 중복되어 여러 개가 실행된다.

컨테이너는 VM에 비해 더 능률적이고 가벼우므로 같은 하드웨어에서

VM에 비해 6~8배 더 많은 컨테이너를 실행할 수 있다.

따라서 웹 스케일 요구 사항이 있는 애플리케이션 환경에서

컨테이너는 전통적인 서버 가상화에 비해 매력적인 제안이다.

LXC에서 도커까지
최초의 리눅스 컨테이너 기술은 리눅스 컨테이너(Linux Container)다. 보통 줄여서 LXC라고 한다. LXC는 하나의 호스트에서 여러 개의 격리된 리눅스 시스템을 실행하기 위한 리눅스 운영체제 시스템 수준의 가상화 방법이다.

컨테이너는 운영체제에서 애플리케이션을 분리한다. 따라서 사용자는 깨끗한, 최소한의 리눅스 운영체제만을 두고 다른 모든 것은 하나 이상의 격리된 컨테이너에서 실행할 수 있다. 또한 운영체제는 컨테이너에서 추상화되므로 컨테이너 런타임 환경을 지원하는 어떤 리눅스 서버로 컨테이너를 옮길 수 있다.

단일 애플리케이션 LXC 컨테이너를 구축하기 위한 프로젝트로 시작된 도커는 LXC에 여러 가지 중요한 변화를 가미해 컨테이너의 이식성과 사용 유연성을 높였다. 도커 컨테이너를 사용하면 가상머신을 사용할 때보다 더 쉽고 빠르게 워크로드를 배포, 복제, 이동, 백업할 수 있다. 기본적으로 도커는 컨테이너를 실행할 수 있는 모든 인프라에 클라우드 수준의 유연성을 제공한다.

그래서 많은 사람들은 최근 컨테이너 인기가 급상승하는 주 요인으로 도커를 꼽는다. 이제부터 도커를 조금 더 자세히 알아보고 LXC와의 차이점에 대해 살펴보자.

도커의 내부
도커는 특수한 LXC를 빌드하기 위한 오픈소스 프로젝트로 시작됐지만, 이후 자체 컨테이너 런타임 환경으로 발전했다. 높은 수준에서 보면 도커는 효율적으로 컨테이너를 생성, 이동, 실행할 수 있는 리눅스 유틸리티다.

기본적으로 도커와 LXC 컨테이너 모두 cgroup과 namespace를 구현해서 리소스 격리를 관리하는 사용자 공간 경량 가상화 메커니즘이다. 하지만 도커 컨테이너와 LXC 간에의 몇 가지 핵심적인 차이가 있다.

단일 프로세스 대 다중 프로세스. 도커는 컨테이너가 단일 프로세스로 실행되도록 제한한다. 따라서 애플리케이션 환경이 X개의 동시 프로세스로 구성된다면, 도커에서는 각각 별도의 프로세스를 갖는 X개의 컨테이너를 실행해야 한다. 반면 LXC 컨테이너는 일반적인 init 프로세스가 있으므로 여러 프로세스를 실행할 수 있다.

도커에서 단순한 다계층 웹 애플리케이션 하나를 실행하려면 PHP 컨테이너, Nginx 컨테이너(웹 서버), MySQL 컨테이너(데이터베이스 프로세스용), 그리고 데이터베이스 테이블 및 기타 애플리케이션 데이터를 저장하기 위한 몇 가지 데이터 컨테이너가 필요하다.

이런 단일 프로세스 컨테이너의 장점은 많다. 업데이트가 더 쉽고 세분화된다는 것도 그 중 하나다. 웹 서버만 업데이트하면 되는데 데이터베이스 프로세스를 종료할 필요가 있는가? 또한 단일 프로세스 컨테이너는 마이크로서비스 기반 애플리케이션을 구축하기 위한 효율적인 아키텍처이기도 하다.

물론 단일 프로세스 컨테이너에는 제약도 있다. 예를 들어 컨테이너 내에서 에이전트, 로깅 스크립트 또는 SSH 데몬을 실행할 수 없다. 또한 작은, 애플리케이션 수준의 변경 사항을 단일 프로세스 컨테이너로 커밋하기는 쉽지 않다. 사실상 업데이트된 새 컨테이너를 시작해야 한다.

무상태 대 상태. 도커 컨테이너는 LXC에 비해 무상태(Stateless)에 맞게 만들어졌다. 첫째, 도커는 영구 스토리지를 지원하지 않는다. 도커에서 이를 처리하는 방법은 컨테이너에서 호스트 스토리지를 “도커 볼륨”으로 마운트하는 것이다. 볼륨은 마운트되므로 컨테이너 환경에 속하지 않는다.

둘째, 도커 컨테이너는 읽기 전용 계층으로 구성된다. 일단 컨테이너 이미지가 생성되면 변경되지 않는다. 런타임 중에 컨테이너의 프로세스가 내부 상태에 변경을 가할 경우 내부 상태와 컨테이너가 생성된 이미지 사이에 “diff”가 만들어진다. docker commit 명령을 실행하면 이 diff는 원래의 이미지가 아니라 새 이미지의 일부가 된다. 이 새 이미지에서 새 컨테이너를 만들 수 있다. 컨테이너를 삭제하면 diff가 사라진다.

무상태 컨테이너는 흥미로운 개체다. 컨테이너를 업데이트할 수 있지만 연속적으로 업데이트하면 그에 따라 연속적으로 새 컨테이너 이미지가 생성되므로 시스템을 롤백하기가 쉽다.

이식성. LXC에 비해 도커가 앞선 가장 중요한 부분 중 하나다. 도커는 LXC에 비해 더 많은 네트워킹, 스토리지, OS 세부 요소를 애플리케이션에서 추상화한다. 도커에서 애플리케이션은 이러한 저수준 리소스 구성으로부터 진정 독립적이다. 어느 한 도커 호스트에서 다른 도커 지원 시스템으로 도커 컨테이너를 옮기더라도 도커는 애플리케이션의 환경이 동일하게 유지되도록 보장한다.

여기서 얻는 직접적인 이점은 도커를 통해 개발자가 프로덕션 서버와 완전히 동일한 로컬 개발 환경을 구축할 수 있다는 것이다. 개발자는 코드 작성과 테스트를 완료하면 이를 컨테이너에 래핑해서 바로 AWS 서버 또는 프라이빗 클라우드로 게시할 수 있다. 환경이 동일하므로 애플리케이션은 즉각 작동한다.

LXC의 경우 개발자 시스템에서 정상 실행되더라도 서버에 배포된 후에는 제대로 실행되지 않을 수 있다. 서버 환경이 다르기 때문이다. 개발자는 그 차이를 디버깅하고 문제를 수정하기 위해 막대한 시간을 소비해야 한다.

도커는 바로 이런 복잡성을 없애준다. 도커 컨테이너가 다양한 클라우드 및 가상화 환경에서 이식성이 뛰어나고 사용하기 쉬운 이유다.

개발자 친화적인 아키텍처
기반 하드웨어에서 애플리케이션을 분리하는 것은 가상화의 바탕이 되는 기본 개념이다. 컨테이너는 여기서 한 걸음 더 나아가 기반 OS에서 애플리케이션을 분리한다. 이를 통해 이식성과 효율적인 확장을 포함한 클라우드 수준의 유연함을 얻을 수 있다. 컨테이너는 개발자에게 가상화를 뛰어넘는 새로운 차원의 효율성, 이식성, 배포 유연성을 제공한다.

컨테이너의 인기는 지금이 개발자 주도의 시대라는 사실을 반영한다. 클라우드가 인프라 혁신, 모바일이 사용성 혁신을 위한 것이었다면, 컨테이너는 개발자의 능력을 배가하는 데 있어 꼭 필요한 요소다