Docker란 무엇인가?

일반적으로 서버를 관리한다는건 복잡하고 어려우며 고급 개발자들의 섬세한 작업이 필요한 영역입니다.

예전에는 회사에서 사용하는 리눅스와 오라클 버전이 딱 정해져 있었고, 버전을 업데이트 하는것은 엄청난 리스크였기 때문에 서버는 최대한 건드리지 않고 그대로 두는게 최선의 방법이였습니다.

하나의 서버에 여러개의 프로그램을 설치하는 것도 문제였는데 서로 사용하는 라이브러리의 버전이 다르거나 동일한 포트를 사용하는 경우는 설치가 굉장히 까다롭습니다. 차라리 서로 다른서버에 설치하는게 더 나은 방법이였고, 그렇게 조립 PC는 늘어나고 자원은 낭비되었습니다.

시간이 흐르면서 서버 환경이 계속 바뀌는데 CentOS 에 익숙해지면 Ubuntu 를 써야하는 일이 생기고, AWS 에 익숙해지면 Azure 를 써야하는 일이 생깁니다.

DevOps 의 등장으로 개발주기가 짧아지면서 배포는 더 자주 이루어지고, 마이크로서비스 아키텍쳐가 유행하면서 프로그램은 더 잘게 쪼개어져 관리는 더 복잡해집니다. 새로운 툴은 계속해서 나오고, 클라우드의 발전으로 설치해야 할 서버가 수백, 수천대에 이르는, 답이 없는 상황에서 Docker 가 등장하고 서버관리 방식이 완전히 바뀌게 됩니다.

도커는 컨테이너 기반의 오픈소스 가상화 플랫폼 입니다.

컨테이너라 하면 배에 싣는 네모난 화물 수송용 박스를 생각할 수 있는데, 각각의 컨테이너 안에는 옷, 신발, 전자제품, 술, 과일 등 다양한 화물을 넣을 수 있고, 규격화되어 컨테이너선이나 트레일러 등 다양한 운송수단으로 쉽게 옮길 수 있습니다.

서버에서 이야기하는 컨테이너도 이와 비슷한데, 다양한 프로그램, 실행환경을 컨테이너로 추상화하고, 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 해줍니다. 백엔드 프로그램, 데이터베이스 서버, 메시지 큐 등 어떤 프로그램도 컨테이너로 추상화 할 수 있고, 조립 PC, AWS, Azure, GCP 등 어디에서든 실행할 수 있습니다.

컨테이너를 가장 잘 사용하고 있는 기업은 구글인데, 2014년 발표에 따르면 구글은 모든 서비스들이 컨테이너로 동작하고 매주 20억 개의 컨테이너를 구동한다고 합니다.

컨테이너(Container)란?

컨테이너는 가상화 기술 중 하나로 대표적으로 LXC(Linux Container)가 있습니다. 기존 OS를 가상화 시키던 것과는 달리 컨테이너는 OS 레벨의 가상화로 프로세스를 격리시켜 동작하는 방식으로 이루어집니다.

한 서버의 여러 OS를 가상화 하여 사용하는 것과 컨테이너 방식으로 프로세스를 격리시켜 동작하는 방법은 어떠한 차이점이 있을까요?

VM 가상화 플랫폼 VS Docker 가상화 플랫폼

컨테이너는 격리된 공간에서 프로세스가 동작하는 기술입니다. 가상화 기술의 하나지만 기존 방식과는 차이가 있습니다.

기존의 가상화 방식은 주로 OS를 가상화 하였습니다.

우리에게 익숙한 VMware나 Virtual Box 같은 가상머신은 호스트 OS위에 게스트 OS 전체를 가상화 하여 사용하는 방식입니다. 이 방식은 여러가지 OS를 가상화(리눅스에서 윈도우를 돌린다던가) 할 수 있고, 비교적 사용법이 간단하지만 무겁고 느려서 운영환경에선 사용할 수 없었습니다.

이러한 상황을 개선하기 위해 CPU의 가상화 기술 HVM 을 이용한 KVM(Kernel-based Virtual Machine 과 반가상화 (Paravirtualization) 방식의 Xen 이 등장합니다. 이러한 방식은 게스트 OS가 필요하긴 하지만, 전체 OS를 가상화하는 방식이 아니였기 때문에 호스트형 가상화 방식에 비해 성능이 향상되었습니다.

이러한 기술들은 OpenStack 이나 AWS , Rackspace 같은 클라우드 서비스에서 가상 컴퓨팅 기술의 기반이 되었습니다.

전 가상화든 반 가상화 든 추가적인 OS를 설치하여 가상화하는 방법은 어쨌든 성능문제가 있었고 이를 개선하기 위해 프로세스를 격리 하는 방식이 등장합니다.

리눅스에서는 이 방식을 리눅스 컨테이너라고 하고, 단순히 프로세스를 격리시키기 떄문에 가볍고 빠르게 동작합니다. CPU나 메모리는 딱 프로세스가 필요한 만큼만 추가로 사용하고 성능적으로도 거의 손실이 없습니다.

OS가상화는 컨테이너기반 가상화보다 더 높은 격리 레벨을 지원합니다. 이는 보안적인 측면에서 더욱 유리합니다. 또한 OS 가상화의 커널을 공유하지 않는 장점 또한 있습니다. 커널을 공유하지 않는 만큼 멀티 OS가 가능하다는 것입니다. 커널을 공유하지 않아 멀티 OS가 불가능 하다는 것은 예를들어 Linux위에 Window를 올릴 수 없다는 단점이 있는 것이죠.

그럼에도 Docker를 쓰는 이유는 성능향상, 뛰어난 이식성, 쉽게 Scale Out을 할 수 있는 유연성 입니다.

Docker Image

Docker Image란, 컨테이너를 실행할 수 있는 실행파일, 설정 값 들을 가지고 있는 것이라고 생각하면 됩니다.

그림과 같이 Image를컨테이너에 담고 실행을 시킨다면 해당 프로세스가 동작하게 되는 것 입니다.

이러한 이미지는 아래와 같이 만들어집니다.

다음 그림을 보면 Ubuntu 이미지를 만들기 위해 Layer A,B,C가 들어갑니다. 그럼 nginx 이미지를 만든다고 가정했을때, 이미 만들어진 Ubuntu 이미지를 베이스 이미지로 사용하여 베이스 이미지에 nginx만 더하면 됩니다.

web App을 올릴때도 마찬가지입니다. ubuntu이미지를 올리고 nginx를 올리고 web app을 올리는게 아니라 이미 만들어진 nginx 베이스 이미지에 web app을 올려서 이미지를 만들면 됩니다.

이러한 이미지는 Docker File 을 이용하여 만들 수 있습니다.

Docker File

Docker Image 들을 저장하고 배포하는 Docker Hub는 잘 활성화 되어 있습니다. 이미 여러 회사들은 소프트웨어를 Docker Hub를 통해 배포하기 시작했고, 우린 Docker Hun에서 Image를 Pull 하여 간단하게 컨테이너에 넣어 사용할 수 있습니다.

하지만 만약 배포판이 없을수도 있습니다. 혹은 이러한 배포판 보다 더욱 보완하고 싶을 때는 Docker File 을 사용할 수 있습니다.

Docker File 은 이미지 생성 출발점에서 부터 이미지를 구성하기 위한 명령어들을 작성하여 이미지를 구성할 수 있습니다.

즉, Docker File 을 읽을 수만 있다면, 해당 이미지가 어떻게 구성되어 있는지도 알 수 있다는 의미가 됩니다.

FROM jdk8:latest
    
WORKDIR /app

RUN mkdir /app/nexus-2.14.9-01
RUN mkdir /app/sonatype-work
RUN yum -y install httpd

ENV JAVA_HOME /usr/local/jdk1.8.0_181
ENV PATH=$JAVA_HOME/bin:$PATH
ENV CLASSPATH=.

EXPOSE 3411 
ADD run.sh /app/
           
CMD ["/app/run.sh"]

Docker Hub & Docker Registry

Docker Hub에서는 이미지를 저장하고 관리해줍니다. 위에서도 많은 회사들이 Docker로 소프트웨어를 배포하기 시작했고 공개이미지들을 공유할 수 있습니다. Docker Hub를 이용하면 손쉽게 imaer를 pull 받아 컨테이너에 적용 시킬 수 있습니다. (사실 Github와 동일하게 생각해도 무관하다고 합니다)

그렇다면 Docker Registry는 무엇일까요?

Docker Hub 처럼 공개된 방식이 아닌 비공개적으로 격리된 저장소를 구축할 수 있습니다.

그것이 바로 Docker Registry 입니다.
아래 링크는 참조 글 작성자가 제공한 Docker Registry를 구축하는 방법입니다.
Docker Registry 구축하기

Reference

Docker Registry 구축하기