도커, 컨테이너
Iaas 의 뛰어난 이식성과 PaaS의 저렴한 운영비용을 함께 누릴 수는 없을까
배포방식의 변천사
1. 전통적인 배포
전통적인 배포 방식에 따르면, 컴퓨터 하드웨어 위에 운영체제를 설치한 뒤, 곧바로 어플리케이션을 여러개 깔아서 사용한다.
문제는 어플리케이션 간에 서로 영향을 끼치기 때문에 하나의 어플리케이션을 깐다고 다른 어플리케이션에 문제가 발생할 수도 있다.
2. 가상화 배포
전통적인 배포 방식에서 발전한 것이 바로 가상화 배포 방식이다.
가상머신을 이용하여 배포하는 방식인데, 하드웨어 - 운영체제 위에 hypervisor 기술을 이용하여 여러개의 가상머신을 독립적으로 운영한다.
가상머신 : 컴퓨터의 모든 하드웨어적 부품을 소프트웨어의 형태로 모방한 것이다. CPU, memory 등이 모두 소프트웨어로 되어있어서 마치 하드웨어 부품을 조립하듯이 사용한다.
hypervisor : 하나의 시스템 상에서 여러개의 가상머신을 구동할 수 있도록 해주는 중간계층을 의미한다.
클라우드 역시 이러한 가상화 기술 덕분에 가능한 것이다.
전통적 배포에 비해서는 운영이 편리해졌지만, 가상머신마다 OS 를 설치해주어야 하는 불편함이 있다.
3. 컨테이너 배포
컨테이너 런타임을 이용하여 하나의 운영체제 위해 여러개의 컨테이너를 운영하는 방식을 말한다.
컨테이너는 코드와 코드를 실행하는데 필요한 모든 종속성(라이브러리 등)을 패키징 한 소프트웨어의 표준 단위를 말한다.
즉 컨테이너 = 코드 + 코드 실행에 필요한 모든 종속성 패키지
컨테이너 내의 "이미지"라는 파일에 모든 라이브러리 + 종속성을 포함하는 코드가 저장된다.
가상머신하고 유사해보이지만, 운영체제 격리 속성을 완화하여 가상머신과는 다르게 컨테이너 간에는 운영체제를 공유할 수 있으며, OS 를 매번 설치하지 않아도 되니, 훨씬 경량화 되어있고 빠르다.
즉, 컨테이너나 가상머신을 이용하면 비록 하나의 OS 위에서 프로그램이 돌아가지만, 마치 서로 다른 컴퓨터에서 설치되어 있다고 착각하게 된다.
컨테이너의 경우는 OS 를 공유하기 때문에 어플리케이션의 문제가 OS에 영향을 미치면, OS 에서 구동중인 전체 컨테이너의 문제로 발전할 가능성도 있다.
도커
그렇다면 도커란 무엇인가...!
컨테이너 단위로 어플리케이션을 실행하는 기능을 제공하는 플랫폼이다.
위의 그림에서는 container runtime 에 해당한다고 볼 수 있다.
도커는 Iaas 의 뛰어난 이식성과 PaaS의 저렴한 운영비용을 함께 누릴 수 있도록 해준다.
기존 시스템에 대한 설치 절차는 Dockerfile 스크립트에 작성하고
배포 관련된 사항은 docker swarm 이나 kubernates 에 맞춰 작성하기만 하면 된다.
보통의 구성은 그래서 docker + docker swarm or docker + kubernates
아래와 같은 과정을 거쳐서 컨테이너를 만든다.
Dockerfile 을 빌드
도커 이미지를 생성하고 실행한다.
도커 컨테이너를 실행한다.
docker file : 컨테이너에 설치해야하는 패키지, 환경변수 등을 기록한 하나의 파일이다. (java 를 설치한 뒤, 어떤 스크립트 파일을 실행한다 등)
docker image : 도커가 도커 파일의 단계에 따라서 컴퓨터의 상태를 스냅샷으로 저장한 것을 말한다.
docker container : 도커가 이미지를 불러와 실행할 때, 생성된다. 실행중인 컨테이너는 이미지에 지정된 프로그램과 데이터를 사용해서 일반적인 실제 컴퓨터와 연결되어 사용 가능하다.
kubernates or docker swarm : 컨테이너화된 어플리케이션을 자동으로 배포, 스케일링 및 관리해주는 컨테이너 오케스트레이션이다.
Docker 는 클라우드 가상화 기술이다. IaaS도, PaaS 도 아니지만, 굳이 따지자면 PaaS 의 일부라고 볼 수 있다. 컨테이너 가상화 자체가 커널 레벨이 아니라, 운영체제레벨, 가상 머신의 가상화가 일어나는 레벨보다 하나 더 높은 추상화 계층에서 일어나기 때문이다.
Last updated
