1.2 도커가 해결할 수 있는 문제점들
소프트웨어를 사용하는 것은 복잡하다. 설치하기 전에, 운영체제를 고려해야 하고, 소프트웨어를 구동하기 위한 요구사항을 충족해야 한다. 어디에 설치해야 할지를 결정하고 어떻게 설치해야 하는지도 알아야 한다. 이러한 문제는 사용자가 여러 호스트에서 일관된 소프트웨어들을 사용하고자 할 경우 더욱 심화된다.
APT, Homebrew, YUM, npm과 같은 패키지 매니저 소프트웨어가 이러한 역할을 수행하지만 격리 기능은 거의 제공하지 않는다. 대부분의 컴퓨터는 하나 이상의 애플리케이션을 설치하고 구동한다. 그리고 대부분의 애플리케이션들은 의존성을 가진다. 사용하고자 하는 애플리케이션에 의존성 문제가 발생하는 것만큼 골치아픈 일도 없다.
-> 특정 애플리케이션은 업그레이드된 의존성이 필요하지만 다른 애플리케이션은 그렇지 않은 경우
-> 특정 애플리케이션을 삭제한 경우
-> 과거 의존성을 삭제하고자 하는 경우
-> 현재 삭제하고자하는 소프트웨어를 설치하기 위해 변경한 내용을
한 가지 분명한 것은 더 많은 소프트웨어를 사용할수록 유지보수는 더욱 어려워진다. 사용자가 애플리케이션 설치 및 운영과 유지보수를 하기 위한 시간과 에너지를 가지고 있더라도 보안에 대해 얼마나 확신 할 수 있을까? 오픈 소스 프로그램과 유료 프로그램은 지속적으로 보안 업데이트를 릴리즈하며, 사용자가 모든 문제를 인지하는 것은 거의 불가능하다. 더 많은 소프트웨어를 사용할수록 공격에 취약할 가능성이 커진다.
엔터프라이즈급 서비스 소프트웨어 조차도 종속성을 가지고 설치된다. 대형 프로젝트들은 수 백개 이상의 파일과 여러 가지 프로그램들로 구성되고 배포되는 것이 일반적이다. 각각의 파일과 프로그램들은 충돌 가능성과 취약점 등을 발생시킬 가능성을 가진다.
위와 같은 문제점들은 소프트웨어 관리, 계정 관리 등과 같은 여러가지 방법으로 해결할 수는 있지만 굉장히 지루하고 별로 하고 싶지 않은 일들이다.도커를 만든 사람들은 이런 문제점을 인식했고 그들 덕분에 우리는 이러한 문제점들을 손쉽게 해결할 수 있게 되었다.
1.2.1. 의존성 해결
도커를 사용하지 않는 경우, 컴퓨터는 정리되지 않은 서랍처럼 보이게 된다. 애플리케이션은 모든 의존성을 포함한다. 몇몇 애플리케이션들은 사운드, 네트워킹, 그래픽과 같은 범용적인 자원들을 위해 특정 시스템 라이브러리에 의존성을 가지고 있다. 다른 애플리케이션들은 사용된 프로그래밍 언어에 따른 표준 라이브러리에 의존성을 가지며 다른 애플리케이션에 의존성을 가지는 경우도 있다(ex: 자바의 경우 자바 버추얼 머신에 대한 의존성을 가진다). 실행 중인 프로그램은 일반적으로 네트워크 연결이나 파일과 같은 희소한 자원을 독점적으로 사용하고자 한다.도커를 사용하지 않는 경우, 애플리케이션은 파일 시스템 전체에 분산되고, 결국 복잡한 흐름을 가진 웹을 만들어낸다. 아래 그림은 도커을 사용하지 않은 애플리케이션의 의존성을 나타낸다.
<그림 1.5> 의존성 관계도
반면, 도커를 사용하는 경우 필요한 소프트웨어를 자동으로 설치해주며 명령어 하나로 동일한 소프트웨어를 손쉽게 제거할 수 있다. 도커는 컨테이너와 이미지를 사용해서 모든 것을 격리하고 관리한다.
그림 1.6은 의존성을 포함한 동일한 애플리케이션이 컨테이너 내부에서 실행되는 상황을 나타낸다. 복잡한 의존성이 사라지고 각 애플리케이션이 깔끔하게 컨테이너화 되어, 전체 시스템을 보다 이해하기 쉽게 표현할 수 있다.
<그림 1.6> 컨테이너 내부에서 실행되는 프로그램 예시
1.2.2 이식성 개선
또 다른 소프트웨어 문제는 애플리케이션의 종속성이 일반적으로 특정 운영 체제에 의존한다는 것이다. 운영체제 간의 이식성(portability)은 소프트웨어 사용자들에게 중요한 문제다.
리눅스와 Mac OS 간의 호환성이 있을 수도 있지만, 동일한 소프트웨어를 윈도우에서 사용하는 것은 더 어려울 수 있다. 그렇게 하려면 소프트웨어의 전체 포팅 버전(ported version)을 구축해야 할 수도 있다. 그마저도 윈도우에 적절한 대체 의존성이 존재하는 경우에만 가능하다. 대부분의 경우, 해당 애플리케이션을 포팅하지 않는다. 따라서 사용자들은 자신의 시스템에서 해당 애플리케이션을 사용하지 못할 수도 있다.
현재 도커는 기본적으로 리눅스에서 실행되며 Mac OS 및 윈도우 환경을 위한 단일 가상 머신을 제공한다. 이러한 컨버전스(convergence)는 도커 컨테이너에서 실행되는 소프트웨어는 의존성 집합을 포함하여 한번 만 작성하면 된다는 것을 의미한다.
가상머신과 컨테이너 기술은 상호 보완적이다. 가상 머신을 사용하여 단일 프로그램을 실행하는 것은 비효율적이다. Mac OS 및 윈도우에서 도커는 하나의 작은 가상 머신을 사용하여 모든 컨테이너를 실행한다. 해당 방법은 가상 머신을 실행하기 위한 오버헤드를 발생시키지 않고, 컨테이너 개수를 증가시킬 수 있다.
이와 같은 이식성의 장점은 그동안 특정 환경에서는 사용할 수 없었던 소프트웨어를 사용할 수 있게 해준다. 즉 데스크탑, 개발 환경, 회사 서버, 회사 클라우드 서버 등 환경에 상관없이 동일한 소프트웨어를 사용할 수 있음을 의미한다. 동일 환경을 구축하는 것은 매우 중요한 작업이다. 소프트웨어 유지보수 측면에서도 단일 시스템에 대한 코드만 작성하면 되기 때문에 엄청난 노력과 시간을 절약할 수 있다.
예를 들어, 만약 우리가 자바 또는 이식 가능한 언어로 쓰여지지 않은 인기 있는 웹 서버를 사용하고 싶다면, 우리는 해당 웹 서버의 개발자들이 새로운 언어로 웹 서버를 재작성 해줄 수 있을지 의문을 가지게 된다. 이러한 단점 외에도, 프로그래밍 언어간 변환과 소프트웨어 라이브러리는 의존성 문제를 발생시키는 요소이다.
도커는 작성된 언어, 설계된 운영 체제 또는 실행중인 환경의 상태에 관계없이 모든 프로그램의 이식성을 향상시킨다.
1.2.3 호스트 보호
지금까지 살펴본 내용들은 소프트웨어로 작업하는 관점에서의 문제점과 컨테이너 외부에서 작업하는 것의 장점들이었다. 하지만 컨테이너 또한 컨테이너 내부에서 실행되는 소프트웨어로부터 사용자를 보호할 수 있다. 소프트웨어나 프로그램들은 언제든지 오작동 할 수 있고 보안 위협에 노출될 수 있다.
- 특정 프로그램은 공격자에 의해 생성되었을 가능성이 존재한다.
- 선의를 가진 개발자들도 유해한 버그를 만들 수 있다.
- 프로그램의 입력 처리 미흡으로 인해 공격자의 타겟이 될 수 있다.
실제 현실의 감옥과 마찬가지로 컨테이너 내부에 소프트웨어 및 프로그램들은 내부에 있는 자원에만 접근할 수 있다. 사용자가 명시적으로 예외 룰을 생성한 경우에만 예외 상황이 존재할 수 있다.
컨테이너는 특정 프로그램이 실행 중인 다른 프로그램들과 접근할 수 있는 데이터, 그리고 시스템 리소스에 영향을 줄 수 있는 범위를 제한한다.
해당 컨테이너의 특성은 실행 중인 특정 애플리케이션의 보안 위협의 범위가 해당 애플리케이션 내에 제한되어 있음을 의미한다.
강력한 애플리케이션 컨테이너를 만드는 것은 복잡하고 심층 방어 전략(in-depth defense strategy)의 중요한 구성 요소이지만 대부분의 경우 그다지 신경 쓰지 않거나 중요하게 여겨지지 않는다.