Docker란
Docker란 리눅스의 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 오픈 소스이다.
컨테이너는 Host OS 상에서 리소스를 논리적으로 구분하여 마치 별도의 서버인 것처럼 사용할 수 있게 하는 기술이다.
가상화를 사용하는 이유는?
향상된 컴퓨터의 성능을 더욱 효율적으로 사용하기 위해 가상화 기술이 많이 등장하였다.
CPU 사용률이 저조한 서버들은 리소스 낭비라고 볼 수 있다. 그렇다고 모두 한 서버에 올린다면 안정성 문제가 발생한다. 이에 따라 안정성을 높이며 리소스도 최대한 사용하기 위해 서버 가상화를 사용한다.
컨테이너란?
컨테이너는 가상화 기술 중 대표적인 예시이다. 기존 OS를 가상화 시키던 것과 달리 컨테이너는 OS레벨의 가상화로 프로세스를 격리시켜 동작하는 방식으로 이루어진다.
컨테이너는 "OS레벨의 가상화로 프로세스를 격리시킨다."가 핵심이다. 가상화의 대표적인 다른 예시인 VM과 비교해보겠다.
VM은 Host OS위에 가상화를 시키기 위한 Hypervisor 엔진 그리고 그 위에 Guest OS를 올려 사용한다.
이는 가상화된 하드웨어 위에 OS가 올라가는 형태로 거의 완벽하게 Host와 분리된다고 볼 수 있다.
컨테이너 기반 가상화는 Docker엔진 위에 Application 실행에 필요한 바이너리만 올라가게된다.
즉 Host OS + Hypervisor engine + Guest OS VS Host OS + Docker Engine + bins/libs이다.
전가상화든 반가상화든 추가적인 OS를 설치하여 가상화하는 방법은 어쨋든 성능문제가 있었고 이를 개선하기 위해 프로세스를 격리 하는 방식이 등장합니다.
리눅스에서는 이 방식을 리눅스 컨테이너라고 하고 단순히 프로세스를 격리시키기 때문에 가볍고 빠르게 동작합니다. CPU나 메모리는 딱 프로세스가 필요한 만큼만 추가로 사용하고 성능적으로도 거어어어어의 손실이 없습니다.
Docker엔진 위에서 바로 동작하며 host의 커널을 공유한다.
host의 커널을 공유하기 때문에 IO처리가 쉬워져서 성능의 효율을 높일 수 있다.
컨테이너를 사용하는 것은 가상 머신을 생성하는 것이 아니라 Host OS가 사용하는 자원을 분리하여 여러 환경을 만들 수 있도록 하는 것이다.
그렇다고 컨테이너가 무조건 좋지는 않다.
OS가상화는 컨테이너 기반 가상화보다 높은 격리를 지원한다. 이는 보안적인 측면에서 더욱 유리하다.
또한 OS 가상화는 커널을 공유하지 않는다. 커널을 공유하지 않는 만큼 멀티 OS가 가능하다.
즉 Linux 위에 Windows를 올릴 수 있다.
그럼에도 Docker를 쓰는 가장 중요한 이유는 성능 향상, 뛰어난 이식성, 쉽게 Scale Out을 할 수 있는 유연성이다.
Docker image란 컨테이너를 실행할 수 있는 실행파일, 설정 값 들을 가지고 있는 것이라고 생각하면 된다.
Image를 컨테이너에 담고 실행을 시키면 해당 프로세스가 동작하게 된다.
이미지는 컨테이너를 실행하기 위한 모오오오오든 정보를 가지고 있기 때문에 더 이상 의존성 파일을 컴파일하고 이것저것 설치할 필요가 없습니다. 이제 새로운 서버가 추가되면 미리 만들어 놓은 이미지를 다운받고 컨테이너를 생성만 하면 됩니다. 한 서버에 여러개의 컨테이너를 실행할 수 있고, 수십, 수백, 수천대의 서버도 문제없습니다.
도커 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 보통 용량이 수백메가MB에 이릅니다. 처음 이미지를 다운받을 땐 크게 부담이 안되지만 기존 이미지에 파일 하나 추가했다고 수백메가를 다시 다운받는다면 매우 비효율적일 수 밖에 없습니다.
도커는 이런 문제를 해결하기 위해 레이어layer라는 개념을 사용하고 유니온 파일 시스템을 이용하여 여러개의 레이어를 하나의 파일시스템으로 사용할 수 있게 해줍니다. 이미지는 여러개의 읽기 전용read only 레이어로 구성되고 파일이 추가되거나 수정되면 새로운 레이어가 생성됩니다. ubuntu 이미지가 A + B + C의 집합이라면, ubuntu 이미지를 베이스로 만든 nginx 이미지는 A + B + C + nginx가 됩니다. webapp 이미지를 nginx 이미지 기반으로 만들었다면 예상대로 A + B + C + nginx + source 레이어로 구성됩니다. webapp 소스를 수정하면 A, B, C, nginx 레이어를 제외한 새로운 source(v2) 레이어만 다운받으면 되기 때문에 굉장히 효율적으로 이미지를 관리할 수 있습니다. (개이득)
컨테이너를 생성할 때도 레이어 방식을 사용하는데 기존의 이미지 레이어 위에 읽기/쓰기read-write 레이어를 추가합니다. 이미지 레이어를 그대로 사용하면서 컨테이너가 실행중에 생성하는 파일이나 변경된 내용은 읽기/쓰기 레이어에 저장되므로 여러개의 컨테이너를 생성해도 최소한의 용량만 사용합니다.
가상화의 특성상 이미지 용량이 크고 여러대의 서버에 배포하는걸 감안하면 단순하지만 엄청나게 영리한 설계입니다.
어떻게 이미지가 만들어 질까?
Docker File
Docker Hub & Docker Registry
Docker Hub에서는 이미지를 저장하고 관리해줍니다. 위에서도 많은 회사들이 Docker로 소프트웨어를 배포하기 시작했고 공개이미지들을 공유할 수 있습니다. Docker Hub를 이용하면 손쉽게 imaer를 pull 받아 컨테이너에 적용 시킬 수 있습니다. (사실 GitHub와 동일하게 생각해도 무관함)
그렇다면 Docker Registry는 무엇일까요?
Docker Hub처럼 공개된 방식이 아닌 비공개적으로 격리된 저장소를 구축할 수 있습니다.
다음은 Docker Image를 Pull받기 위한 url 입니다. 그림과 같이 앞에있는 url을 적지 않으면 default로 Docker Hub에서 Image를 pull 받게되고 url을 적어준다면 사설 저장소에서 이미지를 받을 수 있습니다.
Docker Archtecture
// 쿠버네티스 미작성
'Infra' 카테고리의 다른 글
| Keda (0) | 2024.04.29 |
|---|---|
| Jenkins VS Travis VS Github action (0) | 2022.03.21 |
| Jenkins (0) | 2022.02.04 |
| 클라우드, 인프라 (0) | 2021.11.01 |
