Docker 개념 정리

요즘 로컬 테스트 환경에서도, 실제 운영 환경에서도 docker 컨테이너를 많이 사용하고 있는데요,

업무에서 docker의 사용 비중이 점점 높아질수록 내가 과연 docker를 잘 알면서 사용하고있는지, 누군가 docker가 뭐냐고 물어보면 잘 대답할 수 있을지 궁금했습니다.

 

평소에 궁금했던 점도 해결하고 이후 트러블슈팅을 할때도 도움이 될 수 있도록 docker 개념을 하나씩 간단히 정리해보도록 하겠습니다.

주로 IT인프라 구축을 위한 docker(Asa Shiho) 책을 많이 참고하였습니다.

 

1. Docker

아래는 위키백과의 docker에 대한 정의입니다.

도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다.
여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다.
이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.

 

docker는 앱을 실행하기 위해 필요한 모든 것을 하나의 이미지에 모아두고
그 이미지를 사용하여 다양한 환경에서 애플리케이션을 실행시키기 위한 오픈소스 플랫폼입니다. 

이렇게만 적어놓으면 사실 뭐하는 녀석인지 제대로 알기 어려운데요,

docker에서 가장 중요한 키워드들을 하나씩 보면서 살펴보겠습니다.

 

2. 컨테이너

컨테이너란 os상에 일정 부분의 구획에 앱을 작동시키기 위해 필요한 라이브러리, 애플리케이션등을 모아서 이것이 별도의 서버인 것처럼 사용할 수 있게 만든 것입니다.

 

일반적으로 하나의 물리서버에 여러개의 앱을 설치하면 각각의 앱은 서버의 디렉토리와 ip주소등을 공유합니다. 때문에 각각의 앱들이 사용하는 미들웨어나 라이브러리등이 충돌할 가능성이 있어 각별히 주의를 해야합니다. 컨테이너 기술을 사용하면 os, 디렉토리, ip 주소 등을 각각의 앱이 혼자서만 사용하는 것처럼 할 수 있습니다. 사실은 모든 앱이 os와 자원을 공유하고 있는데도요.

 

컨테이너와 vm이 비슷한 개념처럼 생각이 되지만 컨테이너는 vm보다 훨씬 가볍고 빠릅니다.

Vm은 하드웨어 수준에서 가상화를, 컨테이너는 os 수준에서 가상화를 하기 때문인데요,

 

출처: https://cloud.google.com/containers?hl=ko-KRLTE

위 그림에서 볼 수 있는 것처럼 vm에서는 host os가 존재하고 각각의 앱들이 개별적인 os위에 설치되어 있습니다. Host os는 여러개의 다른 os를 움직여야하기때문에 상당히 무겁고 느립니다. 반면 컨테이너에서는 모든 컨테이너들을 실제 서버의 os 위 에서 구동시키기때문에 가볍고 메모리를 훨씬 적게 차지합니다.

 

Docker에서는 내부에서 이 컨테이너 기술을 사용하고 있습니다. Docker는 리눅스 상에서 이 컨테이너 단위로 서버를 작동시킵니다. 

 

도커와 컨테이너

Docker는 컨테이너를 사용하기 때문에 서버 하나(컨테이너 하나)를 띄우는데 걸리는 시간이 짧습니다. OS상의 프로세스를 띄우는 것과 거의 비슷한 속도로 서버를 띄울 수 있습니다

 

도커 환경에서는 각각의 컨테이너 안에서 작동하는 프로세스를 하나의 그룹으로 관리합니다. 그리고 그 그룹마다 각각 파일시스템, 네트워크  등을 할당합니다. 같은 리눅스 위에서 작동하는 프로세스일지라도 그룹이 다르면 프로세스나 파일에 대한 액세스를 할 수 없습니다. 이러한 구조를 바탕으로 컨테이너들은 서로 독립적으로 작동할 수 있습니다.

 

3. 이미지

어떤 앱 하나를 실행 시키기 위해서는 애플리케이션 소스코드 뿐만 아니라 라이브러리, 미들웨어, os 등이 필요합니다. Docker 환경에서는 이런 구성요소들을 모두 하나로 모아서 docker 이미지로 만듭니다. (이미지라고 부르지만 docker 이미지는 사실 이 모든 파일들이 담긴 디렉토리입니다.)

 

이미지는 위에서 말한 컨테이너의 바탕이 되는데요, 이 이미지가 있고 docker가 설치되어있다면 어디서든 같은 환경의 앱을 실행시킬 수 있고 한 서버에 여러개의 같은 컨테이너를 구동시키는 것도 가능합니다. 때문에 도커는 클라우드 시스템과 친화력이 높습니다.

클라우드서비스가 달라지더라도 이미지만 있다면 앱에 수정을 거의 하지않고 이동 시킬 수가 있습니다.

 

 

 

어떤 앱을 한번 만들어놓고 수정 없이 사용하는 경우는 거의 없을텐데요, docker 환경에서 실행되는 앱을 수정하면 당연히 이미지 또한 변경해주어야 합니다. docker에서는 이미지에 변경이 있는 부분을 레이어로 관리합니다.

 

docker 이미지를 빌드 해보면 아래처럼 빌드 작업이 쪼개져서 처리되는 것을 볼 수 있습니다.

a17976c8a466: Waiting 
48907045977f: Pushed 
f1b12069bc34: Layer already exists 
2498cf3276d1: Layer already exists 
9a234e481d01: Layer already exists 
68bd60410aac: Layer already exists 

이 친구들이 바로 레이어입니다. 변경점이 없는 레이어는 이미 캐싱된 데이터를 사용하고, 변경점이 있는 레이어만 처리하기 때문에 빌드 시간이 크게 단축됩니다. 위의 예시에서는 위 두개의 레이어를 빼고는 변경사항이 없어 이전 캐시를 그대로 사용합니다.

 

4. docker 컴포넌트

 

docker는 몇개의 컴포넌트로 구성되어있습니다.  이 컴포넌트들을 조합해서 앱의 실행환경을 구축할 수 있습니다.

 

1) docker engine

docker 이미지를 생성하고 컨테이너를 가동시키기 위한 docker의 핵심 기능입니다. 

docker명령의 실행이나 dockerfile에 의한 이미지도 생성합니다.

 

2) docker register

docker 이미지를 공유하기 위한 레지스트리 기능입니다.

 

3) docker compose

다중 컨테이너 애플리케이션을 정의하고 공유할 수 있도록 개발된 도구입니다.

yaml파일을 이용해서 실행환경을 구성할 수 있습니다.

 

4) docker machine

로컬, 혹은 클라우드 환경에 docker의 실행환경을 명령으로 자동생성하기 위한 도구입니다.

 

5) docker swarm

여러 docker 호스트를 클러스터화 하기 위한 툴입니다. Manager가 클러스터 관리, api 제공을 하는 역할을 하며,

node가 실제 docker 컨테이너를 실행하는 역할을 합니다. 

 

5. 작동구조

1) namespace

위에서 컨테이너 안에서 작동하는 프로세스를 하나의 그룹으로 관리하고 각 컨테이너들은 서로 독립적으로 작동한다고 설명했습니다. 이 기술은 linux의 커널의 namespace라는 기능을 사용해서 구현합니다. 데이터에 namespace를 붙여 구분함으로서 충돌 가능성을 줄이고 참조를 쉽게 할 수 있습니다. PID, network, UID 등의 namespace를 사용해서 컨테이너들의 독립적인 작동을 보장할 수 있습니다.

 

2) cgroups

docker에서 컨테이너들은 사실 실제 물리적 서버의 자원을 공유하는데요 이때 linux의 croups 기능을 사용합니다. cgroups는 프로세스와 스레드를 그룹화해서 그룹별로 cpu나 메모리같은 자원을 제한할 수 있습니다. 이렇게 cgroups을 사용하면 하나의 프로세스가 서버의 자원을 독점해서 다른 프로세스들에 영향을 끼치는 일을 막을 수 있습니다.

cgroups는 계층 구조를 사용할 수도 있는데요, 계층 구조를 사용한다는 것은 디렉토리 구조처럼 그룹의 그룹을 만들 수 있다는 얘기입니다. 예를들어 사용자 앱, 데몬으로 구분해 실제 앱의 부모격인 그룹을 만들어 줄 수 있습니다. 부모 자식관계에서는 자식의 설정은 부모의 설정에 제한을 받습니다. 자식은 부모그룹의 제한을 초과하여 할당할 수 없습니다.

 

 

출처: https://cloud.google.com/containers

ko.wikipedia.org/wiki/%EB%8F%84%EC%BB%A4_(%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4)

도커 (소프트웨어) - 위키백과, 우리 모두의 백과사전

 IT인프라 구축을 위한 docker(Asa Shiho)