Docker란?
개강을 한 후 드디어 깨달았다. 학교 수업과 블로그 운영을 병행하는 것은 아주아주 힘든 일이라는 것을. 따라서 하루에 하나 배우기라는 폴더의 의미를 지키기보다는 내가 글을 쓸 여유가 될 때 찾아오는 방법을 선택해야겠다.
오늘은 교수님께서 Reading article로 추천해주신 기사를 읽어보도록 하겠다. 오역이 있을 수 있으니 꼭 원문 참조.
The Code4Lib Journal – Docker: a Software as a Service, Operating System-Level Virtualization Framework
Issue 25, 2014-07-21 Docker: a Software as a Service, Operating System-Level Virtualization Framework Docker is a relatively new method of virtualization available natively for 64-bit Linux. Compared to more traditional virtualization techniques, Docker is
journal.code4lib.org
Docker: a Software as a Service, Operating System-Level Virtualization Framework
Docker는 64-bit Linux에서의 상대적으로 새로운 virtualization(가상화) 방법이다. 더 전통적인 방법들과 비교했을 때, Docker는 더 가볍고 git과 비슷한 commit, tags 시스템을 가지고 있다. 또한 당신의 컴퓨터에서 Cloud(클라우드 컴퓨팅)에 이르기까지 사용될 수 있다.
By John Fink, Digital Scholarship Librarian, McMaster University
Introduction
만일 당신이 지난 세기에 library IT에서 일했었다면, server room이 주로 어떤 모습이었는지 기억할 것이다. 아주 큰 멀티디스크 CDROM의 배열에 네트워크 운영체제인 Novell Netware를 구동중인 PC 타워가 붙어있었다. 냉장고 크기의 Sun boxes이었다. ... (중략)
크기가 작은 마이크로컴퓨터에서도 돌아가는 Linux 운영체제의 이점에도 불구하고, 복잡한 서버 룸에 진정한 변화는 2000년대 초기에 생기기 시작했다. 그것은 바로 가상화였다. 가상화는 여러 개의 운영체제를 하나의 기계에서 돌릴 수 있게 만들었다.
1960년대에 이미 VMs for IBM System을 통해 현대적 의미의 가상화가 존재했으나, 2001년 VMWare가 x86 프로세서의 리눅스 기반 가상화 제품을 내놓았을 때 진정한 의미가 실현되었다.
(다음 문장은 해석이 애매해서 해석하지 않고 원문 첨부)
With technologies like KVM and Xen looming large for local deployment and products like Amazon Web Services and the OpenStack framework claiming the cloud, the jumbled, messy, white-box-PC-and-CDROM-tower-laden server room is more or less extinct;
오늘날 당신은 최소한의 기계를 이용하여 다수의 가상 머신을 만들 수 있다.
Virtualization with Docker
운영 체제 수준 가상화의 오픈 소스 구현인 Docker는 개발자들 사이에서 빠르게 공유되고 있다. 대부분의 훌륭한 오픈 소스 프로젝트와 마찬가지로, Docker는 새로운 기능과 함께 많은 기존 Linux 기술을 통합하고, Copy-on-write Union Filesystems 및 Linux Containers 와 같은 기존 기술을 사용하며, 개발자 중심(따라서 전통적인 가상 머신과 구별됨)인 여러 기능을 결합한다. 개발 휴대성, 버저닝, 재사용성 등
이러한 특징들은 생각해 볼 가치가 있다. 이들은 가상 머신 프로비저닝 개념을 시간이 많이 걸리는 '시스템 중심의 모델' 보다는 '개발자 중심의 워크플로우'에 초점을 맞춘 모델로 변환한다. 이것은 특히 Docker의 버저닝 시스템의 git과 유사한 특성(diffs & tags)에서 입증된다.
핵심적으로, Docker는 하드웨어 에뮬레이션이 아닌 실행 중인 애플리케이션에 초점을 맞춘 가상화 프레임워크로, 자세히 알아보기 전에는 특별한 것이 없어 보인다. 하지만 Docker와 같은 '운영 체제 수준의 가상화 소프트웨어'와 머신 수준의 가상화 에는 강조할 만한 차이가 있다. 시스템 수준 VM은 하드웨어의 충실한 재생성(RAM 할당량, 할당할 CPU 수, NIC 에뮬레이션 등)에 관한 것이며 운영 체제 수준 가상화는 시스템이 아니라 애플리케이션에 관한 것이다.
우리는 소프트웨어를 개발, 테스트 및 출시할 때 애플리케이션에 관심을 둘뿐, 특정 하드웨어 환경(실제 하드웨어 또는 가상 하드웨어 환경)을 신경쓰지 않는다. 예를 들어 작동하지 않는 모듈에 대해 도움을 요청하는 글을 쓸 때, "4개의 Intel Core2Duo 프로세서와 16GB의 70ns RAM과 2개의 Atheros 100GB NIC 카드가 있는 Dell PowerEdge 5100을 가지고 있는데 이 Drupal 모듈이 올바르게 작동하도록 할 수 없다"고 말하지 않는다. 우리의 문제가 하드웨어에 묶여 있다는 아주 강력한 지표가 없는 한, 우리는 소프트웨어에 초점을 맞춘다. Docker도 이러한 방식을 사용한다. 일반적으로 Docker에 대한 메모리가 얼마나 있어야 하는지, 하드 드라이브의 크기가 얼마나 되어야 하는지 또는 어느 정도의 CPU를 차지해야 하는지를 정의하려고 할 이유가 없다. 데스크톱에 쓰는 코드에 대해서도 일반적으로 이 작업을 수행하지 않는다.
실제로 이는 Docker 를 실행하는 컴퓨터가 일반적인 가상 시스템을 실행하는 동일한 컴퓨터보다 더 많은 동시 가상 인스턴스를 실행할 수 있다는 것을 의미한다. 예를 들어 2007년부터 빈약한 데스크톱에서 머신 수준 가상화를 위해 두 개의 Virtualbox 인스턴스를 동시에 실행하는 데 문제가 있었다. 하지만 같은 데스크톱으로 호스트 시스템의 큰 성능 저하 없이 40개 이상의 Docker 컨테이너를 실행할 수 있었다.
Running Docker
Docker 를 운영하는 것은 어떤 모습인가? Docker 소프트웨어가 설치된 후에는 시작, 중지, 가져오기, 내보내기 및 기타 작업을 수행할 수 있는 기본 바이너리("docker")가 남게 된다.
Docker 호스트가 여러 개의 컨테이너를 실행하는 예가 있는데, 우리는 도커 ps를 커맨드 라인에서 실행함으로써 이것을 볼 수 있다.
개별 Docker 인스턴스는 이미지와 컨테이너로 분할된다. 컨테이너는 이미지의 인스턴스를 실행한다. 우리는 동일한 이미지 또는 해당 이미지의 변형에서 나오는 여러 개의 컨테이너를 가질 수 있다. 위의 목록에서 컨테이너 id 'b58946da298c'와 'e5a0f8a71f7e'가 "papyrus-demo" 이미지의 서로 다른 버전을 실행 중임을 알 수 있는데, 이는 이미지가 git tags와 유사하게 작용하는 tags를 가지고 있어 공통 이미지의 다른 상태를 나타낼 수 있음을 보여준다. 파피루스 데모의 이미지에는 "in-process"이라는 태그와 "port6000"이라는 태그가 있는데, 뚜렷한 태그가 없는 이미지는 항상 "latest"이다.
A simple example: Article-as-container
Docker가 어떻게 작동하는지 보여주기 위해 나는 Markdown으로 써야하는 이 기사를 Python SimpleHTTPServer 모듈을 사용하여 제공하는 컨테이너를 만들었다. 이 기사에 대한 Docker 컨테이너를 Github 저장소(https://github.com/jbfink/c4l-docker-article)에서 확인할 수 있다.
이것은 매우 간단한 Docker 컨테이너로, 두 가지 컴포넌트와 함께 빌드되어있다. 첫째는 Docker 이미지가 처음 빌드될 때 실행되는 'Dockerfile'이다. 둘째는 'start.sh'으로, 이미지를 컨테이너로 인스턴스화할 때마다 실행된다. 기사 텍스트는 'c4l-docker-article.md'에 있으며, 이 파일은 'start.sh'내에서 pandoc에 의해 변환되어 SimpleHTTPServer와 함께 제공된다.
구성 요소와 실행 방법을 분리해보자.
Dockerfile
Dockerfile을 한 줄씩 살펴보면,
FROM ubuntu:latest
이것은 베이스로 사용할 이미지다. 이 경우, Docker의 stock Ubuntu image에서 만들어지고 있다.(내장 우분투 이미지란 뜻인듯하다.)
MAINTAINER John Fink <john.fink@gmail.com>
생성된 이미지의 유지 관리자를 설정한다.
RUN echo "deb http://archive.ubuntu.com/ubuntu precise universe" >> /etc/apt/sources.list
RUN문은 빌드 중인 이미지 내에서 명령을 실행한다. 이 경우에는 Ubuntu 의 소스 리스트에 유니버스 리포지토리를 추가해서 나중에 pandoc을 설치할 수 있도록 한다.
RUN DEBIAN_FRONTEND=noninteractive apt-get update
RUN DEBIAN_FRONTEND=noninteractive apt-get -y install python git pandoc
Ubuntu 업데이트 및 필요한 패키지를 설치하는 두 개의 RUN문이다.
ADD ./start.sh /start.sh
ADD문은 빌드 중인 이미지 외부의 파일을 삽입한다. 이때 'start.sh' 파일이 이미지에 추가된다.
RUN mkdir /article/
ADD ./c4l-docker-article.md /article/c4l-docker-article.md
RUN문과 ADD문을 함께 사용하여, 디렉토리를 만들고 거기에 기사 Markdown을 추가한다.
EXPOSE 8888
EXPOSE문은 이미지에서 빌드된 컨테이너에 8888 포트에 액세스해야 하는 프로그램이 실행될 것이라고 Docker에 알린다. 이 경우엔 파이썬의 SimpleHTTPServer가 8888 포트에 액세스해야한다는 것이다.
CMD ["/bin/bash", "/start.sh"]
CMD 문에는 특별한 명령이 없는 경우 컨테이너 내부에서 실행할 기본 프로그램이 정의되어 있다. 여기서는 컨테이너가 /bin/bash를 사용하여 'start.sh '파일을 실행하기를 원한다.
start.sh
매우 기본적인 start.sh 파일은 다음과 같다.
cd /article/
pandoc c4l-docker-article.md -o index.html
python -m SimpleHTTPServer 8888
기사가 있는 디렉토리로 가서 Markdown에서 html로 기사를 변환하고, 기사를 서비스할 SimpleHTTPServer를 지정(?)해주고 있다.
Building the article container
docker build -t c4l-docker-wordpress git://github.com/jbfink/c4l-docker-article
'docker build' 명령을 실행하면 컨테이너가 빌드된다. 명령은 Docker 파일의 각 줄을 구문 분석하여 각 단계를 Commit하여 저장하고 다음 Commit을 맨 위에 레이어링한다. 이를 통해 오류가 감지되면 롤백(roll back)하기 쉽다. 보너스 성능으로, 이후 'docker build'의 호출은 이전 레이어를 캐시로 사용하며, 라인이 변경되었을 때만 새로운 레이어를 구축한다. 이것은 빌드중인 이미지를 빠르게 수정할 수 있게 한다.
빌드 후 다음을 사용하여 컨테이너를 시작한다.
docker run -Pd c4l-docker-article
새로운 컨테이너가 c4l-docker-article 이미지에서 생성될 때마다 (우리가 'docker run' 명령을 내릴 때와 같이) Dockerfile의 CMD 문장이 실행된다; 이 경우, 우리의 start.sh 파일을 실행하는 것이다. 'flag P'는 Docker에게 호스트의 임의 포트를 컨테이너 포트 8888에 노출하도록 지시하므로 컨테이너 외부에서 SimpleHTTPServer에 접근할 수 있으며, 'flag d'는 도커에게 백그라운드에서 분리된 컨테이너를 실행하도록 지시한다. 'docker ps'를 실행하면 새 컨테이너와 여기에 할당된 임의 포트가 표시될 것이다. 웹 브라우저를 사용하여 해당 포트의 도커 호스트로 이동하면 기사가 렌더링된다.
A real-world example: WordPress
2013년 봄, 저자는 사내 개발 프로젝트에서 사용할 목적으로 Docker WordPress 컨테이너를 만들기 시작했다. 왜 WordPress인가? WordPress는 라이브러리 소프트웨어의 실험실 쥐로, 어디에서나 사용되고, 잘 지원되며, 잘 이해되며, 일반적으로 관리하기 쉽고, 그 뒤에 많은 보조 소프트웨어가 있다. 그것은 도커의 능력을 테스트하기 위한 좋은 사례가 될 수 있었다. 처음에 나는 수작업으로 컨테이너를 제작했다. 즉, Bash Shell을 실행하는 단일 Docker 컨테이너를 시작하고 기본적으로 위의 'Docker file'이 수행하는 단계를 직접 수행했다(apt-gets 및 파일의 vim 편집). 저자는 그것을 'Docker index'(Docker 계의 Github 같은 곳)에 올렸고, 몇몇 사람들로부터 어떻게 그것을 만들었는지에 대한 연락을 받았다. 2013년 8월, 나는 사람들이 가지고 놀 수 있고 빌드할 수 있도록, 내가 수동으로 했던 것을 만드는 구조적인 방법 을 'docker-wordpress'이란 이름으로 만들기 시작했다(http://github.com/jbfink/docker-wordpress). WordPress를 정상적인 방식으로 설정하여 Docker 이미지로 만들어 이를 다른 곳에서 실행하는 데 있어 중요한 것은 구성(configuration)이 컨테이너 전체에서 동일하게 유지돼야 하는 것이다. 즉, 동일한 MySQL 암호와 WordPress 솔트 및 키(PHP) 말이다. 이상적으로 도커 워드프레스(docker-wordpress)가 실행될 때마다 모든 불안정한 워드프레스(WordPress) 구성 옵션에 대해 서로 다른 값이 있어야 하므로, 도커 워드프레스에는 wp-config.php의 중요한 값을 설정하기 위해 처음 시작할 때 일련의 명령을 실행하는 start.sh 를 포함하고 있다.
-작성중