도커가 무엇일까요?
우선은 위키백과에서 설명하는 도커의 정의는 다음과 같습니다.
도커(Docker)는 리눅스의 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 오픈 소스 프로젝트이다
이렇게만 정의를 보게되면 도커가 도대체 무슨 뜻인지 알아듣지 못 할수도 있습니다. 위의 정의가 뭔지 이해를 하기 위해서는 도커가 왜 필요한지 에 대해서부터 먼저 알아볼 필요가 있습니다.
Why Docker?
우선은 예전에 스프링부트 어플리케이션을 직접 EC2에서 환경설정을 해가면서 배포했던 경험부터 먼저 떠올려봅시다. 저희는 EC2를 Amazon Linux 이미지를 선택해서 스프링부트 어플리케이션을 배포했었습니다. 그 과정에서 저희는 이러한 행위들을 했었습니다.
- JDK를 설치한다.
- GitHub에 Deploy Key를 등록한다.
- Etc...
그런데 저희는 우선 JDK를 설치할 때부터 커맨드가 매우 복잡했던걸로 기억합니다. 우선 기억을 상기시키기 위해서 JDK를 설치하기 위해 거쳐왔던 커맨드부터 한번 봅시다.
# aws coreetto 다운로드
sudo curl -L https://corretto.aws/downloads/latest/amazon-corretto-11-x64-linux-jdk.rpm -o jdk11.rpm
# jdk11 설치
sudo yum localinstall jdk11.rpm -y
# jdk version 선택
sudo /usr/sbin/alternatives --config java
# java 버전 확인
java --version
# 다운받은 설치키트 제거
rm -rf jdk11.rpm제가 굳이 저렇게 JDK를 설치했어야한 이유는, 저희는 스프링부트 어플리케이션을 JDK11 버전으로 개발을 진행했기 때문입니다.
Amazon Linux 이미지에서는 디폴트로 JDK 1.8까지밖에 설치를 하지 못합니다. 그래서 저희는 aws coretto에서 JDK 11버전을 찾아서 설치를 했었던 것입니다.
그런데 저희가 서비스를 확장해야해서 다른 EC2를 파서 서버를 올린다고 가정을 해봅시다. 그런데 EC2를 파는 과정에서 이러한 문제가 충분히 발생할 수 있습니다.
저희 프로젝트 팀에 새로운 멤버 A가 들어왔습니다. 그런데 A라는 멤버는 이전에 스프링부트 어플리케이션을 Amazon Linux를 기반으로 배포를 했는지를 모릅니다. 그래서 Ubuntu 이미지로 가상머신을 생성해서 서버를 배포를 했는데, 위의 커맨드가 먹히지를 않습니다!
저희가 이전에 작성한 코드의 경우 소규모의 코드였기 때문에 위의 이슈가 크게 문제가 되지 않겠으나, 대규모의 서비스에서는 위의 이슈가 발생하면 아주 크게 문제가 될 가능성이 큽니다. 돈이 걸려있으니까
자세하게 알아보겠습니다.
👉 Snowflake Server
직역하면 눈송이 서버 라는 뜻입니다. 눈송이의 경우에는 사람 눈에 보기에는 다 똑같은 눈송이 모양을 가집니다. 그러나, 자세하게 들여다보면 눈송이마다 형상이 모두 다른 것을 관찰할 수 있습니다.
이쁘죠?
이를 서버와 관련되게 대입을 해봅시다.
같은 기능을 하는 서버라고 할지라도 실세계에서는 서버의 형상이 사소하게라도, 혹은 크게 차이가 나는 경우가 많을겁니다. 이러한 경우를 서버의 형상이 다르다 라고 부르기도합니다.
그런데, 같은 기능을 수행하는 서버임에도 불구하고 형상이 각기 다른 경우에는 아래와 같은 문제가 발생할 수 있습니다.
- 새로운 멤버가 합류했다고 하면, 기존에 존재하는 멤버가 서버의 형상에 관련되어서 인수인계를 해줘야한다.
- 서버마다 형상이 다르기 때문에, 서버마다 인력이 추가적으로 붙어야할 가능성이 존재한다.
결국에는, 서버의 운영에 관해서 Cost가 증가하는 현상이 발생한다! 라고 요약이 가능합니다. 조금 더 자세하게 이해를 해보기위해 예시를 들어보겠습니다.
아래의 상황이 있다고 가정하겠습니다.
치타상사에는 MyApp이라는 프로그램으로 밥벌어먹고 살고있습니다. 그런데 MyApp을 굴리기 위해서는 MyBackground라는 프로그램이 필요합니다.
그런데 A라는 서버에서는 MyBackground ver1을 사용하고 있었습니다. 어느 날 B라는 서버에서도 MyApp을 굴려야할 상황이 생겼습니다.
그 사이에 MyBackground는 ver2를 배포하였고, 치타상사의 직원들은 MyBackground ver2를 B서버에 설치를 해서 MyApp을 돌리려고 했습니다. 하지만 MyBackground 프로그램의 일부 기능 지원이 종료되어 먹통이 되버렸습니다.
위의 상황은 생각보다 흔하게 발생할 수 있습니다. 그리고 위의 상황은 치타상사에 큰 손실을 입혔을겁니다.
치타상사는 분명히 이런 사태가 다음에라도 발생하지 않게끔 막고싶을겁니다.
이제부터 Docker에 관해서 알아보겠습니다.
Docker의 역사
Docker는 아래의 영상으로부터 시작이 되었습니다.
위의 영상은 2013년에 Docker 프로젝트를 발표하던 영상입니다.
위의 영상을 그냥 보게되면 이런 생각을 가지실수도 있습니다.
아니 저 사람은 왜 Hello, world를 출력한거 뿐인데 왜 저렇게 박수갈채를 받을까? 나도 그냥 아무데서나 Hello, world!를 출력하면 박수를 받는거임? ㄹㅇㅋㅋ
그런데 위의 발표자가 박수를 받는 이유는 다음과 같습니다.
Hello, world!를 출력하는 프로그램을 개발 환경과 전혀 쌩뚱맞은 환경에서 단순하게 커맨드로 올렸다!
네, 그렇습니다. 위의 영상은 개발자에게 아래의 두가지 큰 충격을 가져다주었습니다.
- 개발 환경과 관계없이 동일한 어플리케이션(프로그램)을 올릴수 있게 해주었습니다. 이는 개발자로 하여금 서버 운영환경 구성에 관해서 어느정도 해방을 시켜줬습니다.
- 서버를 이미지로 관리를 하기 때문에 Load Balancing, 혹은 Scailing-out을 구현하는데 큰 편리함을 가져다줍니다.
다시 Docker가 무엇인지 알아봅시다.
다시, Docker가 무엇인가요?
일단 도커 공식문서에 나온 도커에 대한 소개부터 보겠습니다.
위에 나온 내용을 대충 요약해보자면, 컨테이너란 개발자로 하여금 그들의 어플리케이션을 환경 구성의 고민으로부터 해방을 시켜주는 표준화된 단위 라고 설명을 해주고있습니다. 그리고 도커는 그러한 컨테이너를 기반으로해서 동작을 하고 있습니다.
그러면, 컨테이너가 도대체 무엇인지 알아봅시다!
Container는 뭐에요?
우선 아래의 그림부터 봅시다.
첫 문장을 보시게되면, 컨테이너란 코드와 코드의 모든 Dependency들을 포장하는 규격화된 단위인대, 이는 어플리케이션이 다른 환경에서도 빠르게, 그리고 확실하게 동작하도록 해줍니다 라고 나와있습니다.
그리고 이러한 도커는 어플리케이션의 실행 환경을 DockerImage라는 것으로 관리를하는데, 위의 설명대로라면 Docker의 이미지는 LightWeight(경량), Standalone(독립적, i.e. 개발환경에 관계없다), executable package of software(실행가능한 패키지) 입니다.
그리고 이러한 DockerImage는 Docker Engine을 통해서 container가 되어서 동작을 한다 라고도 소개가 되어있는걸 확인해볼 수 있습니다.
추가적으로, 도커엔진은 위와 같은 구조를 가진다고 공식문서에 소개가 되어있는데, 여기서 저희가 짚고넘어갈 부분은 두 가지가 되겠습니다.
- 위와 같은 구조를 가지는 Docker를 통해서 개발자는 Dependency hell로부터 탈출이 가능하다.
- 그리고, 개발자와 운영팀으로 하여금 it works only on my laptop!(프로그램이 내 환경에서만 돌아가요!) 문제로부터 해방을 시켜준다.
도커를 쓰면 뭐가 좋아요?
사실 이것에 대해서는 위에서 이미 많은 설명을 했기 때문에, 위에서 설명하지 않았던 부분을 위주로, 혹은 더욱 보충적으로 설명을 드리겠습니다.
우선, 아래의 그림을 한 번 보실까요?
왼쪽은 Docker를 이용해서 Application을 Container 단위로 실어서 작동시키는 것, 그리고 오른쪽은 기존의 방식대로 VM을 하나씩 동작시켜서 Application을 동작시키는 방법입니다.
기존의 방식대로 VM을 하나씩 파서 Application을 동작시키기 위해서는, Application을 동작시키기 위한 환경을 각 VM마다 하나씩 하나씩 설정을 해줘야한다 라는 문제가 있습니다. 그리고 Hypervisor라는 것을 두어서 VM을 직접 하나씩 하나씩 관리를 해야한다 라는 문제도 존재합니다.
이는 운영팀에게 큰 불편함과 cost를 유발한다는 사실에는 부정하지 못합니다.
그런데 왼쪽의 그림을 보시게되면, Application을 각자의 VM을 파지않고, Host os만 하나 두고 거기에다가 Docker를 설치하고, Docker Engine 위에다가 Application container를 올려두는 형식으로 Application을 동작시키고 있습니다.
그리고 Docker container들은 모두 Docker CLI를 통해서 조작하는게 가능하기 때문에, Server를 관리하는데도 큰 이점을 가져올 수 있습니다.
Container를 CLI를 통해서 관리를 할수 있다는거는 생각보다 큰 장점입니다. 이는, Docker container들의 동작을 코드를 통해 자동화를 할 수 있다는 의미이기 때문입니다.
지금까지 Docker가 무엇이고, Docker를 사용함으로써 어떤 이점을 가져올 수 있는지 등에 대해서 알아봤습니다.
다음 포스트에서는 제가 개발한 프로젝트를 어떻게 Docker를 이용해서 올리는지에 대해서 알아보도록 하겠습니다.
다음 포스트에서 뵙겠습니다!
출처 링크
도커의 정의 (위키백과)
The future of Linux container
도커 공식사이트(What Container?)
도커 공식사이트(Why Docker?)
도커 공식사이트(도커 엔진의 구조)
