도커란
도커는 컨테이너 기술의 일종입니다. 컨테이너를 생성하고, 관리하도록 도와주는 도구이죠.
따라서, 도커를 이해하기 위해선 컨테이너라는 개념을 이해해야 합니다.
컨테이너란
컨테이너는 표준화된 소프트웨어 단위(standardized unit of software)라고 볼 수 있습니다. 간단히 말하면 코드와, 코드를 실행시키기 위한 dependencies & tools의 묶음입니다.
만약 nodejs 어플리케이션을 작성한다고 생각해본다면, 도커 컨테이너 안에 소스코드와 실행에 필요한 nodeJS 런타임, 그리고 코드를 실행시키기 위해 필요한 여러가지 도구들을 포함시켜 사용할 수 있습니다.
즉, 컨테이너는 소스코드+코드 실행을 위한 환경을 묶어놓은 것 입니다. 이렇게 컨테이너화를 시켜놓으면 누가 어디서 실행시켜도 같은 환경에서 같은 코드가 동작할 수 있게 됩니다. 왜냐하면 코드 실행에 필요한 환경까지 컨테이너에 묶여있기 때문이죠.
처음 듣는다면 약간 생소한 개념일 수 있습니다. 피크닉 박스를 생각해볼까요?
피크닉 박스는 음식과, 임식을 먹기 위한 그릇, 먹을 수 있는 포크와 같은 도구들을 전부 포함하고 있습니다. 단순히 음식만 있는게 아니라, 음식을 먹기 위해 필요한 도구들까지 전부 박스 안에 있죠. 누가 어디서 사용하던, 피크닉 박스를 이용하면 동일한 음식을 어디에서든 동일하게 즐길 수 있습니다. 산이던, 강이던 말이죠.
피크닉 박스의 근본적 아이디어는 이런 것이고 이 아이디어는 컨테이너, 도커의 근본적인 아이디어와 동일합니다.
컨테이너를 이용하면, 어디서 어떻게 실행하더라도 어플리케이션을 동일하게 실행할 수 있습니다. 만약 해외에서 어플리케이션의 실행이 필요하다면, 다른 os에서 작성한 어플리케이션의 실행이 필요하다면, 컨테이너를 이용해 실행 환경까지 패키징하여 전달해주면 됩니다. 사용자는 컨테이너를 받고, 동일하게 어플리케이션을 실행할 수 있습니다. 실행에 필요한 모든 내용이 컨테이너 안에 있으니까요.
도커는 거의 모든 현대 시스템에서 사용할 수 있습니다. 컨테이너를 만들고 관리하는데 편리한 기능을 제공해줍니다.
도커 & 컨테이너의 장점
위에서 간단하게 살펴봤지만, 실제로 왜 사용하고 무슨 장점이 있는지 좀 더 알아보겠습니다. 근본적인 질문은 다음과 같습니다.
왜 우리는 독립적이고 표준화 된 "application packages"가 필요한가?
1. Different Development & Production Environments
컨테이너를 이용하는 가장 큰 이유중 하나는 위와 같습니다. 개발환경과 실제 실행 환경이 다른 경우가 많다는 것이죠.
우리가 Node.js 14.3 버전으로 작성된 어플리케이션이 있다고 가정해봅시다.
위 코드는 top level wait이 들어가 있는 코드입니다. 이게 뭔지 자세히 알 필요는 없고, 동작하기 위해선 노드의 버전이 14.3보다 높아야 한다는 사실만 기억하면 됩니다.
문제는, 개발시에는 node의 버전을 14.3보다 높게 할 수 있지만, 실제로 어플리케이션을 배포하고 실행해야 하는 서버는 노드가 없거나, 14.3보다 낮은 버전일 수 있습니다.
이렇게 되면 개발할때 잘 동작하던 어플리케이션이 서버에선 실행되지 않을 수 있죠.
개발환경과 실제 운영환경은 같지 않은 경우가 많습니다. 사실 실행하기 위한 환경 모든 환경을 개발 환경과 동일하게 만든다는 것 자체가 너무나도 어려운 일이죠. 개인적으로는 불가능에 가깝다고 생각합니다.
하지만 우리는 개발 환경과 완전히 동일한 실행 환경이 필요합니다. 그래야 우리가 테스트한 대로 정확하게 동작하기 때문이죠.
이럴때 바로 도커가 필요합니다. 우리의 도커 컨테이너에 특정한 버전의 node를 넣어 놓으면 소스 코드는 정확히 동일한 버전의 노드로만 돌아가고, 우리가 예측한 그대로 실행되게 되는 것이죠.
2. Different Development Environments Within a Team / Company
우리가 큰 팀에서 일하고 있는 경우를 생각해 봅시다. 상대팀과 함께 협동 프로젝트를 진행하게 되었습니다. 동일하게 노드를 이용한 프로젝트이죠.
만약 상대팀의 개발 환경에 동일한 노드가 깔려있지 않다면(게으름 때문이건 팀 내의 규칙 때문이던) 우리의 소스코드는 상대팀에서 실행할 수 없을 것 입니다. 위에선 간단한 예시였지만 복잡한 어플리케이션에선 이런 복잡도가 더욱 증가하겠죠.
프로젝트와 관련된 모든 개발자의 개발 환경을 동일하게 맞추는 것 역시 불가능에 가깝습니다. 하지만 우리는 개발환경을 쉽게 동일한 환경으로 맞추길 원하죠. 이런 경우에도 도커 컨테이너는 큰 도움을 줄 수 있습니다.
3. Clashing Tools / Versions Between Different Projects
혼자서 개발하는 경우도 마찬가지로 컨테이너가 필요합니다. 어떤 프로젝트는 노드 12버전이 필요하고, 어떤 프로젝트는 노드 14버전이 필요하다고 생각해봅시다. 노드가 아니라 파이썬이던 php던 자바던 동일합니다.
만약 한 프로젝트에서 다른 프로젝트로 옮기게 된다면 문제가 발생하게 되겠죠. 프로젝트를 개발할 때 마다 기존 환경을 삭제하고 새로운 환경을 다운로드 해야 할 겁니다.
이런 경우도 당연히 도커는 도움이 됩니다. 프로젝트마다 환경을 삭제하고 다운로드할 필요가 없는 것이죠. 컨테이너를 이용해 어플리케이션을 실행시키면 됩니다.
위와 같은 예들이 컨테이너와 도커를 사용하며 얻는 장점이라고 할 수 있습니다.
지금까지 도커와 컨테이너에 대한 개념을 살펴봤습니다. 컨테이너를 공부하면서 가상환경을 떠올리신 분들이 많다고 생각합니다. 컨테이너 vs 가상환경의 비교는 수 많은 포스팅에 반드시 등장하는 개념이죠. 해당 부분에 대해서도 간단하게 살펴보면 좋을 것 같습니다.
참고
