2021.08.05

'컨테이너 혁명을 주도'··· 도커의 의의와 장단점

Scott Carey | InfoWorld
도커(Docker)는 컨테이너에 기반해 애플리케이션을 구축하는 소프트웨어 플랫폼이다. 컨테이너는 운영체제 커널을 공유하지만, 그 외의 경우 서로 격리되어 실행되는 작고 경량의 실행 환경이다. 컨테이너는 리눅스와 유닉스에서 상당 기간 사용됐다. 그러나 2013년 시작된 오픈소스 프로젝트인 도커가 컨테이너 기술을 보편화하는 데 기여했다. 도커에 의해 개발자가 소프트웨어를 패키징 해 ‘한번 구축하면 어디서나 실행할 수 있는(build once and run anywhere)’ 것이 어느 때보다 더 쉬워졌다.
 
ⓒ Getty Images Bank

 
도커의 역사 요약 

2008년 솔로몬 하익스가 프랑스 파리에서 닷클라우드(DotCloud)라는 이름으로 설립한 도커는 원래 서비스 플랫폼(platform as a service, PaaS)로서 시작했다. 이후 2013년 플랫폼이 실행되는 기저의 소프트웨어 컨테이너를 보편화하는 것으로 초점이 변화했다.
 
하익스는 2013년 3월 파이콘(PyCon)에서 도커를 처음 선보였다. 하익스는 도커가 닷클라우드 플랫폼(서비스 플랫폼)을 구동할 기저 기술에 대한 개발자들의 끊임없는 요구를 반영해 개발됐다고 설명했다. 그는 “이 기저 기술이 있다면 리눅스 컨테이너로 무엇이든 할 수 있다. 자체적인 플랫폼을 만들 수 있다. 이게 우리가 하고 있는 것이다”라고 말했다. 

그래서 도커가 탄생했다. 이 오픈소스 프로젝트는 개발자들을 신속히 끌어들였고 유명한 IT 업체인 마이크로소프트, IBM, 레드햇 등이 관심을 보였다. 그리고 벤처 투자자들은 이 혁신적인 스타트업에 수백만 달러를 투입할 용의가 있었다. 이렇게 컨테이너 혁명이 시작됐다. 


컨테이너란 무엇인가? 

하익스가 파이콘에서 설명한 것처럼 컨테이너는 ‘독립형 소프트웨어 단위(self-contained units of software)’로서 서버로부터 서버, 노트북으로부터 EC2, 베어-메탈 자이언트 서버로 전달될 수 있다. 그리고 이는 프로세스 수준에서 격리되어 있기 때문에 동일한 방식으로 실행되고 자체 파일 시스템을 갖는다.” 

이 프로세스를 단순화하는 도커는 컨테이너를 위한 사실상의 업계 표준이 되다시피 했다. 도커를 통해 개발자는 하나의 간소한 방식으로 워크로드를 전개하고 복제하고 이동하고 백업할 수 있다. 일련의 재사용이 가능한 이미지를 이용하기 때문에 기존의 방법들보다 워크로드의 이식성과 유연성이 더 높다. 

가상머신(VM)의 세계에서 이는 동일한 하드웨어에서 실행되는 동안 애플리케이션을 독립적으로 유지함으로써 달성될 수 있다. 그러나 각 VM은 자체 운영체제를 필요로 하고, 이들은 일반적으로 대형이고, 시작이 느리고, 이동이 어렵고, 유지관리와 업그레이드가 까다롭다. 컨테이너가 VM 시대로부터의 본격적인 탈피를 의미하는 이유는 실행 환경을 격리하고 기저의 OS 커널을 공유하면서 개발자에게 경량, 고속의 선택지를 제공하기 때문이다.
 
ⓒ Docker


도커 컴포넌트 

도커는 개발자들의 큰 사랑을 받았는데, 그 이유는 컨테이너를 구축하고 시작하는 데 필요한 도구를 패키징하는 참신한 방법 때문이었다. 이는 과거보다 한층 간결하고 단순했다. 도커를 컴포넌트로 분해한다면 이는 도커파일(Dockerfile), 컨테이너 이미지(container images), 도커 실행 유틸리티(Docker run utility), 도커 허브(Docker Hub), 도커 엔진(Docker Engine), 도커 컴포즈(Docker Compose), 도커 데스크톱(Docker Desktop)으로 나눌 수 있다.
 
- 도커파일. 각 도커 컨테이너는 도커파일과 함께 시작한다. 이 텍스트 파일은 운영체제, 언어, 환경 변수, 파일 위치, 네트워크 포트, 이를 실행하는 데 필요한 여타 컴포넌트를 포함하는 도커 이미지를 구축할 수 있는 일련의 명령을 제공한다. 

- 도커 이미지(Docker image). VM 환경의 스냅샷과 유사한 도커 이미지는 이식 가능하고 읽기 전용의 실행 파일이다. 컨테이너를 생성하기 위한 명령, 그리고 컨테이너가 어떤 소프트웨어 컴포넌트를 어떻게 실행할 것인가에 대한 내역이 담겨 있다. 

- 도커 실행 유틸리티. 도커 실행 유틸리티는 컨테이너를 시작하는 명령이다. 각 컨테이너는 이미지 인스턴스이고, 동일 이미지의 다수의 인스턴스가 동시에 실행될 수 있다.
 
- 도커 허브. 도커 허브는 컨테이너 이미지가 저장되고 공유되고 관리될 수 있는 리포지터리이다. 컨테이너에 특화된 깃허브 도커 버전이라고 생각할 수 있다.
 
- 도커 엔진. 도커 엔진은 도커의 핵심이다. 컨테이너를 생성하고 실행하는 클라이언트-서버 기술이다. 도커 엔진은 컨테이너를 관리하는 이른바 ‘도커 데몬(Docker daemon)’이라는 장시간 실행되는 데몬 프로세스, 도커 데몬과 프로그램 사이의 통신을 담당하는 API, 명령줄 인터페이스를 포함한다. 

- 도커 컴포즈. 도커 컴포즈는 YAML 파일을 이용하는 명령줄 도구이고, 멀티 컨테이너 도커 애플리케이션을 정의하고 실행한다. 이에 의해 사용자는 사용자의 구성 환경으로부터 모든 서비스를 생성하고 시작하고 정지하고 재구축할 수 있고, 아울러 모든 실행 서비스의 현황 및 로그 출력을 열람할 수 있다. 

- 도커 데스크톱. 이들 제반 컴포넌트는 도커 데스크톱 애플리케이션으로 래핑 된다. 이는 컨테이너화 된 애플리케이션과 마이크로서비스를 구축하고 공유하는 사용자 친화적 방식을 제공한다. 


도커의 장점 

도커 컨테이너는 이전의 방법보다 더 쉽게 조립하고, 유지관리하고, 이동시킬 수 있는 애플리케이션 제작 방법을 제공한다. 이는 소프트웨어 개발자에게 다음과 같은 혜택을 제공한다. 

도커는 최소의 요소로 구성되고 이식성을 갖추었다. 도커는 애플리케이션과 이의 환경을 격리시킴으로써 이들을 정연하고 최소한으로 유지할 수 있게 해준다. 이에 의해 미시적 제어와 이식성이 높아진다. 

도커 컨테이너는 컴포저블(composability) 특성을 갖추었다. 컨테이너는 개발자가 애플리케이션의 구성 요소를 쉽게 호환되는 부분들로 된 모듈식 유닛으로 더 쉽게 조합할 수 있게 해준다. 이는 개발 주기, 기능 배포, 버그 수정의 속도를 높일 수 있다.
  
도커 컨테이너는 오케스트레이션과 스케일링이 용이하다. 컨테이너는 경량이기 때문에 개발자는 많은 수의 컨테이너를 시작해 서비스 스케일링을 향상시킬 수 있다. 이 컨테이너 클러스터는 당연히 오케스트레이션이 필요하고 여기서 쿠버네티스가 등장한다.  


도커의 단점 

컨테이너는 수많은 문제를 해결하지만 개발자가 가진 모든 난제를 해결하지는 못한다. 

도커 컨테이너는 VM이 아니다. VM과 달리 컨테이너는 호스트 운영체제 리소스의 제어된 부분을 이용하고, 따라서 요소들이 VM 수준으로 엄격히 격리되지 않는다. 

도커 컨테이너는 베어-메탈 속도를 제공하지 않는다. 컨테이너는 VM보다 더 경량이고 베어 메탈에 더 가깝다. 그러나 이는 성능 오버헤드를 초래한다. 워크로드가 베어-메탈 속도를 요구한다면 컨테이너는 이에 근접한 속도를 제공하지만 동일한 속도는 아니다.   

도커 컨테이너는 스테이트리스(stateless)이며, 불변적(immutable)이다. 컨테이너는 해당 콘텐츠를 담은 이미지로부터 시작되고 실행된다. 이미지는 기본적으로 일단 생성되면 변경되지 않는다. 그러나 컨테이너 인스턴스는 일시적(transient)이다. 인스턴스가 시스템 메모리로부터 제거되면 이는 영원히 사라진다. VM처럼 컨테이너를 세션들에 걸쳐 지속시키려면 지속성을 위한 설계가 필요하다.

 
도커의 현실 

컨테이너 사용은 클라우드 네이티브 개발 기법이 소프트웨어를 제작하고 실행하는 주류 모델이 되면서 계속 성장하고 있다. 반면 도커는 이제 컨테이너의 부분에 불과하다. 

도커는 애플리케이션 코드와 이의 모든 디펜던시(dependencies)를 개발자의 노트북으로부터 서버로 쉽게 이동시킴으로써 주류가 되었다. 그러나 컨테이너의 출현은 애플리케이션 개발 방식을 변화시켰다. 다시 말해 획일적 스택으로부터 마이크로서비스(microservices)의 네트워크로 변화했다.
  
구글로부터 유래한 쿠버네티스 오픈소스 프로젝트는 이를 위한 최고의 방법으로 신속히 자리매김했고, 이 문제를 해결하기 위해 만들어진 도커의 스웜 오케스트레이터(Swam orchestrator)를 대체했다. 자금 문제가 가중되자 도커는 2019년 기업 사업을 미란티스(Mirantis)에 매각했고, 미란티스는 도커 엔터프라이즈를 미란티스 쿠버네티스 엔진(Mirantis Kubernetes Engine)에 흡수시켰다. 

도커의 나머지 부분, 다시 말해 원래의 오픈소스 도커 엔진(Docker Engine) 컨테이너 런타임, 도커 허브(Docker Hub) 이미지 리포지터리, 도커 데스크톱(Docker Desktop) 애플리케이션 등은 7년 경력의 전문가인 스캇 존스턴의 지휘 아래 지속되고 있다. 존스턴은 핵심 고객층인 소프트웨어 개발자를 위주로 사업을 재편 중이다. editor@itworld.co.kr 



2021.08.05

'컨테이너 혁명을 주도'··· 도커의 의의와 장단점

Scott Carey | InfoWorld
도커(Docker)는 컨테이너에 기반해 애플리케이션을 구축하는 소프트웨어 플랫폼이다. 컨테이너는 운영체제 커널을 공유하지만, 그 외의 경우 서로 격리되어 실행되는 작고 경량의 실행 환경이다. 컨테이너는 리눅스와 유닉스에서 상당 기간 사용됐다. 그러나 2013년 시작된 오픈소스 프로젝트인 도커가 컨테이너 기술을 보편화하는 데 기여했다. 도커에 의해 개발자가 소프트웨어를 패키징 해 ‘한번 구축하면 어디서나 실행할 수 있는(build once and run anywhere)’ 것이 어느 때보다 더 쉬워졌다.
 
ⓒ Getty Images Bank

 
도커의 역사 요약 

2008년 솔로몬 하익스가 프랑스 파리에서 닷클라우드(DotCloud)라는 이름으로 설립한 도커는 원래 서비스 플랫폼(platform as a service, PaaS)로서 시작했다. 이후 2013년 플랫폼이 실행되는 기저의 소프트웨어 컨테이너를 보편화하는 것으로 초점이 변화했다.
 
하익스는 2013년 3월 파이콘(PyCon)에서 도커를 처음 선보였다. 하익스는 도커가 닷클라우드 플랫폼(서비스 플랫폼)을 구동할 기저 기술에 대한 개발자들의 끊임없는 요구를 반영해 개발됐다고 설명했다. 그는 “이 기저 기술이 있다면 리눅스 컨테이너로 무엇이든 할 수 있다. 자체적인 플랫폼을 만들 수 있다. 이게 우리가 하고 있는 것이다”라고 말했다. 

그래서 도커가 탄생했다. 이 오픈소스 프로젝트는 개발자들을 신속히 끌어들였고 유명한 IT 업체인 마이크로소프트, IBM, 레드햇 등이 관심을 보였다. 그리고 벤처 투자자들은 이 혁신적인 스타트업에 수백만 달러를 투입할 용의가 있었다. 이렇게 컨테이너 혁명이 시작됐다. 


컨테이너란 무엇인가? 

하익스가 파이콘에서 설명한 것처럼 컨테이너는 ‘독립형 소프트웨어 단위(self-contained units of software)’로서 서버로부터 서버, 노트북으로부터 EC2, 베어-메탈 자이언트 서버로 전달될 수 있다. 그리고 이는 프로세스 수준에서 격리되어 있기 때문에 동일한 방식으로 실행되고 자체 파일 시스템을 갖는다.” 

이 프로세스를 단순화하는 도커는 컨테이너를 위한 사실상의 업계 표준이 되다시피 했다. 도커를 통해 개발자는 하나의 간소한 방식으로 워크로드를 전개하고 복제하고 이동하고 백업할 수 있다. 일련의 재사용이 가능한 이미지를 이용하기 때문에 기존의 방법들보다 워크로드의 이식성과 유연성이 더 높다. 

가상머신(VM)의 세계에서 이는 동일한 하드웨어에서 실행되는 동안 애플리케이션을 독립적으로 유지함으로써 달성될 수 있다. 그러나 각 VM은 자체 운영체제를 필요로 하고, 이들은 일반적으로 대형이고, 시작이 느리고, 이동이 어렵고, 유지관리와 업그레이드가 까다롭다. 컨테이너가 VM 시대로부터의 본격적인 탈피를 의미하는 이유는 실행 환경을 격리하고 기저의 OS 커널을 공유하면서 개발자에게 경량, 고속의 선택지를 제공하기 때문이다.
 
ⓒ Docker


도커 컴포넌트 

도커는 개발자들의 큰 사랑을 받았는데, 그 이유는 컨테이너를 구축하고 시작하는 데 필요한 도구를 패키징하는 참신한 방법 때문이었다. 이는 과거보다 한층 간결하고 단순했다. 도커를 컴포넌트로 분해한다면 이는 도커파일(Dockerfile), 컨테이너 이미지(container images), 도커 실행 유틸리티(Docker run utility), 도커 허브(Docker Hub), 도커 엔진(Docker Engine), 도커 컴포즈(Docker Compose), 도커 데스크톱(Docker Desktop)으로 나눌 수 있다.
 
- 도커파일. 각 도커 컨테이너는 도커파일과 함께 시작한다. 이 텍스트 파일은 운영체제, 언어, 환경 변수, 파일 위치, 네트워크 포트, 이를 실행하는 데 필요한 여타 컴포넌트를 포함하는 도커 이미지를 구축할 수 있는 일련의 명령을 제공한다. 

- 도커 이미지(Docker image). VM 환경의 스냅샷과 유사한 도커 이미지는 이식 가능하고 읽기 전용의 실행 파일이다. 컨테이너를 생성하기 위한 명령, 그리고 컨테이너가 어떤 소프트웨어 컴포넌트를 어떻게 실행할 것인가에 대한 내역이 담겨 있다. 

- 도커 실행 유틸리티. 도커 실행 유틸리티는 컨테이너를 시작하는 명령이다. 각 컨테이너는 이미지 인스턴스이고, 동일 이미지의 다수의 인스턴스가 동시에 실행될 수 있다.
 
- 도커 허브. 도커 허브는 컨테이너 이미지가 저장되고 공유되고 관리될 수 있는 리포지터리이다. 컨테이너에 특화된 깃허브 도커 버전이라고 생각할 수 있다.
 
- 도커 엔진. 도커 엔진은 도커의 핵심이다. 컨테이너를 생성하고 실행하는 클라이언트-서버 기술이다. 도커 엔진은 컨테이너를 관리하는 이른바 ‘도커 데몬(Docker daemon)’이라는 장시간 실행되는 데몬 프로세스, 도커 데몬과 프로그램 사이의 통신을 담당하는 API, 명령줄 인터페이스를 포함한다. 

- 도커 컴포즈. 도커 컴포즈는 YAML 파일을 이용하는 명령줄 도구이고, 멀티 컨테이너 도커 애플리케이션을 정의하고 실행한다. 이에 의해 사용자는 사용자의 구성 환경으로부터 모든 서비스를 생성하고 시작하고 정지하고 재구축할 수 있고, 아울러 모든 실행 서비스의 현황 및 로그 출력을 열람할 수 있다. 

- 도커 데스크톱. 이들 제반 컴포넌트는 도커 데스크톱 애플리케이션으로 래핑 된다. 이는 컨테이너화 된 애플리케이션과 마이크로서비스를 구축하고 공유하는 사용자 친화적 방식을 제공한다. 


도커의 장점 

도커 컨테이너는 이전의 방법보다 더 쉽게 조립하고, 유지관리하고, 이동시킬 수 있는 애플리케이션 제작 방법을 제공한다. 이는 소프트웨어 개발자에게 다음과 같은 혜택을 제공한다. 

도커는 최소의 요소로 구성되고 이식성을 갖추었다. 도커는 애플리케이션과 이의 환경을 격리시킴으로써 이들을 정연하고 최소한으로 유지할 수 있게 해준다. 이에 의해 미시적 제어와 이식성이 높아진다. 

도커 컨테이너는 컴포저블(composability) 특성을 갖추었다. 컨테이너는 개발자가 애플리케이션의 구성 요소를 쉽게 호환되는 부분들로 된 모듈식 유닛으로 더 쉽게 조합할 수 있게 해준다. 이는 개발 주기, 기능 배포, 버그 수정의 속도를 높일 수 있다.
  
도커 컨테이너는 오케스트레이션과 스케일링이 용이하다. 컨테이너는 경량이기 때문에 개발자는 많은 수의 컨테이너를 시작해 서비스 스케일링을 향상시킬 수 있다. 이 컨테이너 클러스터는 당연히 오케스트레이션이 필요하고 여기서 쿠버네티스가 등장한다.  


도커의 단점 

컨테이너는 수많은 문제를 해결하지만 개발자가 가진 모든 난제를 해결하지는 못한다. 

도커 컨테이너는 VM이 아니다. VM과 달리 컨테이너는 호스트 운영체제 리소스의 제어된 부분을 이용하고, 따라서 요소들이 VM 수준으로 엄격히 격리되지 않는다. 

도커 컨테이너는 베어-메탈 속도를 제공하지 않는다. 컨테이너는 VM보다 더 경량이고 베어 메탈에 더 가깝다. 그러나 이는 성능 오버헤드를 초래한다. 워크로드가 베어-메탈 속도를 요구한다면 컨테이너는 이에 근접한 속도를 제공하지만 동일한 속도는 아니다.   

도커 컨테이너는 스테이트리스(stateless)이며, 불변적(immutable)이다. 컨테이너는 해당 콘텐츠를 담은 이미지로부터 시작되고 실행된다. 이미지는 기본적으로 일단 생성되면 변경되지 않는다. 그러나 컨테이너 인스턴스는 일시적(transient)이다. 인스턴스가 시스템 메모리로부터 제거되면 이는 영원히 사라진다. VM처럼 컨테이너를 세션들에 걸쳐 지속시키려면 지속성을 위한 설계가 필요하다.

 
도커의 현실 

컨테이너 사용은 클라우드 네이티브 개발 기법이 소프트웨어를 제작하고 실행하는 주류 모델이 되면서 계속 성장하고 있다. 반면 도커는 이제 컨테이너의 부분에 불과하다. 

도커는 애플리케이션 코드와 이의 모든 디펜던시(dependencies)를 개발자의 노트북으로부터 서버로 쉽게 이동시킴으로써 주류가 되었다. 그러나 컨테이너의 출현은 애플리케이션 개발 방식을 변화시켰다. 다시 말해 획일적 스택으로부터 마이크로서비스(microservices)의 네트워크로 변화했다.
  
구글로부터 유래한 쿠버네티스 오픈소스 프로젝트는 이를 위한 최고의 방법으로 신속히 자리매김했고, 이 문제를 해결하기 위해 만들어진 도커의 스웜 오케스트레이터(Swam orchestrator)를 대체했다. 자금 문제가 가중되자 도커는 2019년 기업 사업을 미란티스(Mirantis)에 매각했고, 미란티스는 도커 엔터프라이즈를 미란티스 쿠버네티스 엔진(Mirantis Kubernetes Engine)에 흡수시켰다. 

도커의 나머지 부분, 다시 말해 원래의 오픈소스 도커 엔진(Docker Engine) 컨테이너 런타임, 도커 허브(Docker Hub) 이미지 리포지터리, 도커 데스크톱(Docker Desktop) 애플리케이션 등은 7년 경력의 전문가인 스캇 존스턴의 지휘 아래 지속되고 있다. 존스턴은 핵심 고객층인 소프트웨어 개발자를 위주로 사업을 재편 중이다. editor@itworld.co.kr 

X