컨테이너와 도커의 이해 (컨테이너를 쓰는 이유 / 일반프로그램과 컨테이너 프로그램의 차이점)
컨테이너란?
- 컨테이너를 왜 배워야 하는가?
- 왜 굳이 리눅스에서 돌리는가?
- 그냥 프로그램과 컨테이너는 어떻게 다른가?
- 그래서 왜 쓰는가?
컨테이너를 왜 배워야 하는가?
- answer : 한마디로 정리하면, 이 시대가 원하기 때문이다.
하드웨어는 좋아지는데 코스트는 낮아지고, IT시스템화 시켜야 할 것은 대규모로 많아지고, IT플랫폼은 점점 커지는 등의 요소에 의해 변화되어 왔다.
과거 엔터프라이즈 시장에서는 대용량의 Bare Metal(소프트웨어가 설치되어 있지 않은 깡통 시스템)에다가 여러개의 어플리케이션을 운영했던 구조로 사용을 해왔다.
여러개의 어플리케이션을 하나의 시스템에서 운영을 시키던 과거에서 시대적으로 하드웨어는 가격이 싸지고, 성능은 좋아지고, 그리고 운영해야하는 플랫폼들은 점점 더 대용량으로 많이 요구하게 되었다.
그래서 Bare Metal 시스템에 Hypervisor라는 것을 만들어서 소프트웨어 기술을 통해 가상 컴퓨터를 (virtual machine)만들고, 그곳에 필요한 어플리케이션을 올려서 사용하는 구조로 발전했다. 이것이 가상화 플랫폼이다.
그리고 가상화 플랫폼에서 시대적으로 더 발전했는데,
예를들어, 어플리케이션을 운영할 때, fornt_end 어플리케이션과 back_end 어플리케이션이 있다고 가정하고,
front_end 어플리케이션을 하나만 운영하는 것이 아니라 2개, 3개, 여러개 등 확장(scale-out) ,혹은 필요하면 다시 축소(sclae-in) 하여 어플리케이션 서비스에서 요구하는 클라우드 요구가 얼마나 많은가에 따라 자유롭게 확장, 축소할 수 있는, 이러한 어플리케이션 요구들이 필요하게 된 것이다.
서비스 중단 없이 어플리케이션을 운영해야 하는 환경!
그러다보니, 기존에 있던 가상환경가지고는 약간의 어려움이 있었다. 그래서 이제는,
Bare Metal 시스템에 OS를 올리고, 그위에 Container Engine을 올리는 것이다.
우리가 알아볼 docker가 Container Engine 중에 하나이다. (docker container)
OS위에 container 플랫폼을 운영해서 거기에다가 컨테이너 어플리케이션을 운영하는 것이다.
이렇게 컨테이너로 운영되는 어플리케이션은 용량이 적다.실제 어플리케이션과 최소화 되어있는 환경만 들어가기 때문에 아주 적은 용량으로 운영이 가능하다.
그리고 하나의 프로그램화가 되어 isolate가 되고, isolate된 공간 안에서 적은 용량이 실행되기 때문에 확장성이 매우 뛰어나며 배포가 쉽다.
즉, 시대가 원하고 있고 컨테이너를 써야한다.
조금 쉽게 설명하자면,
예를들어, 컨테이너에 건조상품을 담아서 배송해야한다고 가정해보자.
그러면, 컨테이너 안에는 건조설비가 필요할 것이다. 그리고 그 안에 상품을 집어넣어 배송할 것이다.
만약에, 상품이 냉동식품이라면, 컨테이너 안에는 냉동 설비가 필요할 것이다.
이렇게 상품에 따라 컨테이너의 설비가 달라진다.
그렇다면, 소프트웨어에서의 컨테이너는 무엇일까?
특정 어플리케이션이 동작하는데에 필요한 환경(라이브러리, 언어, 플랫폼 등)을 갖추어 놓은 독립된 공간을 container라고 한다.
왜 굳이 리눅스에서 돌려야 하는가?
- answer : 리눅스 커널 기능을 써야 하기 때문.
컨테이너는 리눅스 커널의 기능을 가지고 만들어졌다.
리눅스 커널의 어떤 기능을 가지고 만들어졌을까?
- chroot (독립된 공간 형성)
- namespace (isolate 기능 지원, 6가지)
- cgroup (필요한만큼 HW 지원)
그래서 리눅스 커널에 있는 스토리지, 네임스페이스, 네트웍기능들을 도커플랫폼(컨테이너 플랫폼)에서 쓸 수 있도록 지원해주는 것이 container engine 이다.
그렇다면 리눅스 커널이 없는 window, mac에서는 어떻게 사용할까?
리눅스 커널이 있어야 동작을 하는데 어떻게 할까?
바로, Hypervisor를 활성화 한다. 그리고 그 위에서 컨테이너를 돌린다.
그러면 리눅스에서는?
리눅스는 리눅스 커널로 운영하고 있기 때문에, 윈도우나 맥처럼 Hypervisor를 활성화 시킬 필요 없이 바로 리눅스 위에 도커 플랫폼을 올려서 사용할 수 있다.
그래서 사이트(실제 현장)에서는 윈도우나 맥OS기반으로 서비스를 운영하는 것이 아니라,
라이센스 비용이 들어가지 않는 리눅스 기반으로 컨테이너 엔진을 올리고 그 위에서 컨테이너를 동작시켜 운영한다.
그래서 container는 리눅스에서 운영한다.
그냥 프로그램과 컨테이너는 어떻게 다른가?
- answer : 하는 일은 똑같다. 다만, 생긴 모양(구조)이 다르다.
예를 들어 프론트에서 운영되어지는 웹서버 하나를 node.js 소스코드로 만들었다고 가정해보자.
위의 어플리케이션은 동작할 때, "8080 TCP포트를 연다.
8080포트를 열고 listen을 하고 있고, 이곳으로 클라이언트 사용자의 클라이언트 커넥션이 들어올 것이다.
function(req, res)를 통해 들어온 것에 따라서 res.writeHead(200) 응답을 한다. (200번 상태코드를 전달해주고)
Container Hostname으로 실제 컴퓨터 시스템의 호스트의 이름을 찾아서 Container Hostname은 os.hostname()이야" 라는 응답을 전달해주는 웹기반의 어플리케이션을 개발했다고 하자.
이 프로그램 (200번 상태코드와 호스트네임을 전달해주는)을 일반 시스템에서 동작한다면,
컴퓨터에 node.js를 설치해야한다. 왜냐하면 소스코드를 해석해서 실행할 수 있어야 하기 때문이다.
그리고 만들어 놓은 app.js라는 소스코드를 node기반으로 넣어주면 동작이 되는 것이다.
이런식으로 동작을 시켜주는 것이 일반프로그램이다.
그렇다면 똑같은 어플리케이션을 컨테이너 기반에서 동작시켜주면 어떻게 될까?
동일한 소스코드를 가지고 있을 컨테이너를 빌드하는 것이다.
도커 파일이라는 것을 통해서 컨테이너를 빌드 할 수 있는데, 환경을 만들어야 한다.
그 환경이 뭐가 되는 것일까? node가 있어야한다. 왜냐하면, node가 있어야 해당 소스코드를 해석을 할 것이다.
따라서 node라는 환경을 먼저 설치 해주는 환경을 만들고, 그다음 만들어놓은 app.js를 동작시켜주도록 저장하고, 실행해주는 그러한 컨테이너를 빌드하는 것이다.
컨테이너를 만들고, 그 컨테이너 안에는 node(환경)등 app.js를 실행시킬 수 있는 설비를 집어넣고, app.js를 실행하는 것이다.
이렇게 일반 어플리케이션과 컨테이너 어플리케이션은 차이가 있다.
그래서 왜 쓰는 것인가?
- answer : 컨테이너는 개발자가 만든 프로그램을 어디서든 돌릴 수 있고, 확장 / 축소가 쉽고 MSA(마이크로소프트 아키텍쳐), Devops 환경에 아주 적합하다.
현재는 마이크로소프트 아키텍처, 그리고 데브옵스를 요구하는 시대다.
고객의 요구를 빠르게 처리해서 바로바로 응대해 줄 수 있도록 플랫폼을 만들어서 제공해야 하는 시대.
이러한 시대이기 떄문에 컨테이너를 요구하는 것이다.
컨테이너를 사용하면, 개발자가 어플리케이션을 개발해서 (컨테이너 기반으로) 고객사에 제공한다.
하지만 컨테이너를 이용하지 않았던 과거에는 고객사에 H/W가 운영되는 구조 또는 그곳에서 동작하는 어플리케이션의 base등이 다 달랐기 떄문에 개발자가 만든 프로그램이 고객사에서 동일한 모습으로 실행되는데 까지의 어려움이 있었다. 왜냐하면 개환경과 운영환경이 다르기 때문이다.
그런데, 컨테이너는 그 운영환경을 컨테이너 안에다가 넣어버렸다.
OS딴에서 지원해주는 것이 아니라 컨테이너에 집어 넣었기 때문에, 개발자가 개발한 소프트웨어의 운영환경이 고객사에서도 동일하게 운영된다.
만약에 일반프로그램구조에서 프로그램을 확장하고 싶으면, 해당 프로그램을 운영하는 OS도 같이 확장해야 하기 때문에 비효율적인 낭비가 발생한다.
그런데, 컨테이너 구조를 활용하면, 아래와 같이 컨테이너 엔진만 있다면 컨테이너만 확장하면 된다.
어플리케이션 서비스는 작게작게 나눠서 기능별로 만들어내려고 한다.
그것으로 서비스하는게 마이크로서비스 아키텍쳐,
그리고 개발자가 개발에서 서비스 운영까지를 자동화 시켜주는 것을 DevOps 데브옵스라고 한다.
MSA와 DevOps에서는 컨테이너 구조가 매우 유리하다.
컨테이너는 독립적으로 어플리케이션을 돌릴 수 있기 때문이다.
우리가 왜 컨테이너를 배워야 하는지, 잘 이해하고,
docker, docker container를 공부하자.
'DevOps' 카테고리의 다른 글
도커 컨테이너 만들어보기 (feat. 컨테이너 배포) - 실습편 (0) | 2022.03.10 |
---|---|
도커 컨테이너 만들어보기 - 이론편 (0) | 2022.03.07 |
컨테이너 살펴보기 (도커 컨테이너 실행) - 실습편 (1) | 2022.02.18 |
컨테이너 살펴보기 (컨테이너, 컨테이너 이미지, 컨테이너 동작) - 이론편 (0) | 2022.02.17 |
도커 컨테이너 설치하기(feat. Docker, WSL2) (0) | 2022.02.16 |
댓글
이 글 공유하기
다른 글
-
도커 컨테이너 만들어보기 - 이론편
도커 컨테이너 만들어보기 - 이론편
2022.03.07 -
컨테이너 살펴보기 (도커 컨테이너 실행) - 실습편
컨테이너 살펴보기 (도커 컨테이너 실행) - 실습편
2022.02.18 -
컨테이너 살펴보기 (컨테이너, 컨테이너 이미지, 컨테이너 동작) - 이론편
컨테이너 살펴보기 (컨테이너, 컨테이너 이미지, 컨테이너 동작) - 이론편
2022.02.17 -
도커 컨테이너 설치하기(feat. Docker, WSL2)
도커 컨테이너 설치하기(feat. Docker, WSL2)
2022.02.16