Docker란?

Docker

표준화된 소프트웨어 유닛이다. 더 자세히 말하자면, 이는 코드의 패키지를 의미한다. 이 안에는 해당 코드를 실행하는데 필요한 종속성과 tool들이 포함되어 있다는 것이 중요하다.

 

예)  Node.js 애플리케이션을 구축하는 경우 => NodeJS는 서버에서 JavaScript 코드를 실행하는데 사용할 수 있는 JavaScript RunTime이다.

 

NodeJS와 도커로 컨테이너로 빌드된 애플리케이션이 있는 경우 그 컨테이너에는 애플리케이션 소스 코드 뿐만 아니라, NodeJS Runtime 더불어 소스 코드를 실행하는데 필요한 기타 tool들이 있을 것이다. 

 

 도커 컨테이너를 활용한 것의 장점은 특정 도커 컨테이너에 애플리 케이션을 빌드한 경우 그 컨테이너는 항상  동일한 NodeJS 코드, 동일한 NodeJS tool , 동일한 NodeJS 버전 , 동일한 NodeJS 런타임을 이용해서 항상 동일한 동작 결과를 제공한 다는 것이다.

 

더 쉽게 예를 들어 피크닉 바구니를 생각해보자 피크닉 바구니에는 공원에서의 만찬의 필요한 모든것이 들어있다. 그 피크닉 바구니를 가지고 피크닉을 가고자하는 어떤 곳이든지 갈 수 있으며, 언제든 쉽게 준비할 수 있다. 또한 쉽게 이 바구니를 친구들과 공유할 수 있고, 그 피크닉 바구니를 가지고 같은 장소로 피크닉을 간다면, 바구니를 빌린 친구는 내가 했던 피크닉 만찬과 똑같은 경험을 할 수있다.

 

만약 피크닉에서 먹을 음식으로 스프를 가져간다면, 피크닉 바구니에는 스프를 담을 깊이가 깊은 그릇이 없을 수도 있다 하지만, 스스로 자신만의 피크닉 바구니를 다시 꾸려 거기에 깊이가 깊은 접시를 넣는다면, 무리없이 피크닉 만찬에서 스프를 즐길수 있다. => 이것이 피크닉 바구니의 개념으로 도커가 가지는 개념과 동일하다.

 

즉 Docker는 컨테이너를 관리하고 생성하기위한 도구이다.

실제 세계에 존재하는 컨테이너 역시 규격화 표준화 되어 있으며, 이 컨테이너에 다양한 상품을 넣을 수 있지만 컨테이너에 넣은 후에 상품은 그 자체적으로 보관 및 격리된다. 즉 함 컨테이너의 상품은 다른 컨테이너릐 상품과 섞이지 않는다.

 

또한 실제 컨테이너는 규격화 표준화 되어 있으므로  컨테이너를 처리할 수 있는 모든 선박이나 트럭에 실을 수 있다. 그런 점이 Docker 컨테이너와 정확히 동일하다. 우리는 소프트웨어 유닛, 코드가 포함된 패키지 및 코드를 실행하는 종속성을 보관할 수 있으며, 도커가 실행되는 모든 곳에서 이것을 가져올 수있다.

 

즉 동일한 환경에서 정확히 동일한 애플리케이션을 실행 할 수 있다. 필요한 모든 것이 컨테이너에 있기 때문에 애플리케이션을 실행하려는 위치에 추가 도구를 설치해야 하는 것에 대해 걱정할 필요가 없다.

 

도커는 이런 Container를 구축하기 위한 도구일 뿐이다.

 

Docker 장점

 실행하려고 하는 애플리케이션이  최신 운영체제에 환경을 필요로 해도 Docker Container화 되어 있다면 Container의 지원으로 어디서든 쉽게 실행 할 수 있다Docker Container  애플리케이션의 실행과 관리 프로세스를 간소화 하는 도구이다.

 

애플리케이션을 Docker Container를 build하지 않아도 되지만 이는 점점 Standard화 되어간다.

 

왜 Docker Container 일까?

우리는 왜 소프트웨어 개발을 할 때 독립적이고 표준화된 애플리케이션 패키지를 원하는 것 일 까?

첫번째 우리는 흔히 개발하는 환경과 실행환경이 다른 문제에 봉착하기 때문이다.

 

Docker의 주요 사용 사례 : 예) NodeJS 애플리케이션을 만들었다고 가정해 보자 이때 이 애플리케이션은  NodeJS 버전 14.3 혹은 이 이상에서만 정상적으로 실행된다. 문제는 해당 버전의 NodeJS가 개발자가 개발하는 환경에만 설치 되어 있을 수 있다는 것이다.

 

하지만 이 어플리케이션이 전세계에 연결 될 수 있도록 호스트 서버를 통해 원격에 배포를 해야하는 경우 원격의 어느 환경 또는 시스템이는 이전 버저의 NodeJS가 설치되어 있을 수도 있다.

 

그러면 개발 컴퓨터에서 로컬로는 정상적으로 작동하던 코드가 갑자기 어떤 특정 원격의 환경에서는 작동하지 않게 되는 것이다. 그리고 그 원격에 환경에서 해당 어플리케이션이 작동이 안되는 문제의 원인을 파악하는데, 상당한 시간이 걸릴 수 도 있다.

 

즉 제품이되는 애플리케이션 개발환경과 원격의 실행환경이 동일하다는것은 상당한 가치가 있다.

 

*Enviroment : 개발하는데, 필요한, 특정 runtime, 언어, 프레임워크등을 의미한다.

 

자세히 설명하자면 특정 NodeJS 버전을 Docker Container에 고정(lock)할 수 있으므로 코드가 항상 실행되는데 필요로하는 환경에서 실행되도록 할 수 있다.

 

그러므로써 잠재적으로 발생할 수 있는 많은 문제들이 해결된다. 애플리케이션이 자체적으로 필요한 NodeJS 버전을 제공한는 'Container'라는 곳 안에서 실행되기 때문이다.

 

두 번째, 회사내에 각각의 팀들이 서로다른 개발 환경을 가질 수 있기 때문이다.

 

Docker의 주요 사용 사례 : 예) 큰 규모의 애플리케이션이 큰 규모의 팀내에서 이루어 진다고 가정해 보자. 각각의 개발 파트를 맡은 여러 사람들이 각자 자신의 개발환경에서 동일한 프로젝트로 어플리케이션을 개발해 낼 것이다.

 

그런데 A개발자가  NodeJS 14.3 이상에서만 작동되는 기능을 가지고, 코드를 작성할 경우 그 이하의 버전의 NodeJS가 설치된 B개발자 입장에서는 A개발자가 작성한 코드가 B개발환경에서 작동하지 않을 것이다.

 

물론 이런 경우 B개발환경을 update하는 것은 어려운 일은 아닐 것이지만, NodeJS 버전이 다른 경우는 하나의 예일 뿐이고, 관리하고 설치해야 하는 더 복잡한 종속성이 있는 더 복잡한 프로젝는 얼마든지 있을 수 있다.

 

소프트웨어를 생산하고 개발하는 환경에서는 같은 환경에서 개발을 하는 재현성을 필요로하고 원하므로 코드가 아직 배포전 단계이더라도  Container에 코드가 필요로하는 모든 것을 포함하는 환경을 보유하는 것은 여전히 상당한 가치를 지닌다.

 

마지막으로, 혼자서 작업하는 경우에도 작업 중이 프로젝트가 여러개인 경우 충돌하는 버전이 존재 할 수 있기 때문이다.

 

Docker의 주요 사용 사례 : 예) 어떤 프로젝트에서는 어떤이유로든 파이썬 버전2를 사용하고 다른 프로젝트에서는 최신 버전의 파이썬을 사용한다고 가정해 보자 NodeJS나 PHP 또는 어떤 종류의 프로젝트에서도 마찬가지 이다.

 

이는 프로젝트 A에서 프로젝트B로 전환할 때마다. 프로젝트와 맞지 않는 버전을 제거하고, 적합한 버전을 다시 설치해야 함을 의미한다.

 

우리는 각 버전을  Container마다 보유하고, 각각 프로젝트에는 그들만읜 컨테이너가 존재하도록 하면 된다. 따라서 프로젝트를  전환하면 그대로 작동하는 것이다. 호스트 컴퓨터가 아닌, Container에 모든 것이 있기 때문이다. 매번 제거하고 설치할 필요가 없다. 다른 컨테이너를 시작하는 것으로 쉽게 프로젝트를 전환할 수 있다.

 

[출처 - https://www.udemy.com/share/106b8i3@uC-jrm0KnQjqGWtxFr4Pafx0cHSLajV1UnYtTipExbXTkI2OGPueJXMl7-KCFCk76w==/ ]