[도커] Docker: a Software as a Service, Operating System-Level Virtualization Framework

DongGu·2021년 3월 12일

데이터센터프로그래밍

목록 보기

2/11

https://journal.code4lib.org/articles/9669?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+c4lj+
를 번역했습니다.

Docker: a Software as a Service, Operating System-Level Virtualization Framework

도커: SaaS, 운영체제 레벨의 가상화 프레임워크

도커는 리눅스 64비트 환경에서 이용가능한 가상화 메소드의 새로운 방법이다. 전통적인 가상화 기술과 비교했을 때, 도커는 시스템 리소스 측면에서 가볍다. 커밋과 태그 같은 기능을 제공한다. 사용자의 랩탑에서 클라우드까지 규모를 확장시킬 수 있다.

Introduction

IT기업에서 일해봤다면 서버룸의 모양을 알 것이다. Novell Netware를 실행하는 PC타워가 대형 멀티 디스크 CD-ROM 어레이에 연결되어 있다. 거대한 비즈니스를 운영하기 위해서, 그에 걸맞는 거대한 장비가 필요하다. 결과적으로 기계실은 서반, 전선, 에어컨 등이 뒤섞여 있는 경우가 많았다.
리눅스가 마이크로컴퓨터에서 작동되면서, 기계실은 작아지고 덜 복잡해졌다. 2000년대 초기 기계실의 변화가 찾아왔다. 쉽게 구현할 수 있는 가상화가 빠르게 도입되면서, 여러 개의 운영체제를 하나의 기계에서 실행할 수 있게 되었다.
비록 현대적인 개념의 가상화는 1960년대 초에 IBM 시스템용 VM 2를 통해 구현되었지만, 2001년에야 VMware가 x86 가상화 제품을 출시하면서 리눅스 기반 가상화가 실제로 이루어졌다. 여러 IT 기술이 대규모로 구축되면 화이트박스 PC, CD ROM 서버룸이 굉장히 커지고 복잡해졌지만, 오늘날엔 최소의 물리적 기계로 여러 대의 가상머신을 운영할 수 있다.

Virtualization in libraries

libraries를 위한 현대 가상화는 기관마다 다르다. 소프트웨어를 전부 개발하지 않는 소규모에서 중규모의 가게들은 소수의 가상 머신만을 필요로 할 수 있다. 예를 들어, 라이브러리의 웹 프레즌스용, ILS용, 후원 워크스테이션용 이미지 제어용 등이 필요할 수 있다. 가능한 이것들은 오래된 white box를 대신할 것이다. 특정 ILS와 같은 일부 인스턴스는 기존 설치에서 가능한 한 작은 편차를 가지도록 규칙이나 라이센스에 의해 구속된다. 다른 기업의 경우, 가상화 프레임워크에 대한 설치를 사용자 지정하는 노력은 성과를 거두기 힘들다. 성능이나 편의성의 향상은 매우 미미할 수 있다.

소프트웨어를 개발하는 직원이 있는 라이브러리에는 더 복잡한 요구사항이 있을 수 있다. 현대의 개발은 끊임없는 반복이다. 코드를 쓰고 테스트하고 쪼개는 작업을 반복한다. 코드를 처음부터 다시 테스트할 때마다 수동으로 환경을 설정해야 하던 것을 가상 컴퓨터로 한다고 가정해보자. 개발자는 반복적인 작업보다 자신이 진짜로 해야할 일에 시간을 투자할 수 있다. Virutalbox 소프트웨어는 GUI 지향성이 매우 높아서 전체프레임워크를 기반으로 하여 VirtualBox VM 생성 및 제거를 스크립팅할 수 있도록 설계되었다.(이 부분의 의미는 저도 잘 모르겠네요)

일반적인 라이브러리 가상화 체계는 대부분 기계 수준의 가상화를 활용한다. 이미 언급된 시스템(KVM, VMware, Xen, Virtualbox)과 DOS 게임을 실행하기 위해 특별히 작성된 다중 플랫폼 에뮬레이터와 같은 제품은 머신 레벨 에뮬레이터이다. 이들은 소프트웨어에서 디스크 드라이브, RAM 할당, 그래픽, 하드 드라이브 공간, 심지어 프로세서 유형까지 가능한 한 많은 컴퓨팅 환경을 따라하려고 시도한다. 예를 들어 일부 머신 레벨 가상화 플랫폼에서는 데스크톱 PC와 같은 Intel 기반 플랫폼에서 라즈베리 파이와 같은 ARM 기반 시스템을 따라할 수 있다. 그러나 이러한 유형의 가상화는 리소스 집약적이고 비효율적일 수 있다. 단일 컴퓨터에서 여러 가상 시스템을 실행하는 경우 대용량 디스크 드라이브를 할당하거나 각 VM 인스턴스에 대해 여러 기가바이트의 전용 RAM을 분할하여 물리적 시스템의 한계를 빠르게 대응할 수 있다. 이러한 문제 중 일부에 대한 해결 방법은 비교적 간단하지만(예: 외장 드라이브를 네트워크 공유로 탑재하는 등), 어려운 경우도 있다.(제한된 RAM 처리 등).

실제시스템을 따라하는 기계 레벨의 가상화에서 벗어나 인스턴스 간에 리소스를 공유하는 운영체제 수준 가상화에 대해 말해보자. 일반적인 운영체제 수준의 가상화체계는 게스트 인스턴스, RAM, 디스크 공간 및 커널을 공유한다. 따라서 운영 체제 수준 가상화 인스턴스의 수가 동일한 수의 기계 수준 가상화 인스턴스보다 호스트 시스템 리소스가 부족할 가능성이 적다. 운영체제 수준 가상화는 유연한 대신 비용이 더 든다. 게스트 인스턴스는 커널을 공유해야 하므로, 프로세스 및 운영체제 유형을 모두 공유해야 한다. 리눅스 호스트에서 가상화 라즈베리파이를 실행할 수 없다. 이러한 제한에도 운영체제 수준의 가상화는 구현이 용이하고 경량성으로 인기를 끌고 있다.

Virtualization with Docker

운영체제 수준 가상화의 오픈소스인 도커는 개발자들 사이에서 빠르게 점유율을 높여가고 있다. 대부분의 우수한 오픈소스 프로젝트와 마찬가지로 도커는 새로운 기능과 함께 많은 기존 리눅스 기술을 통합한다. 이 기술은 Copy-on-write 유니언 파일 시스템(일반적으로 AUFS)과 Linux Containers과 같은 기존 기술을 사용하며, 이러한 기술을 개발자 중심적인 여러 기능과 결합한다. 배포 이동성, 버전 관리, 재사용 및 반복성과 같은 기존 가상 머신의 기능을 최대한 활용하려고 시도한다.

이러한 기능은 고려할 가치가 있다. 그 기능들은 provisining 가상머신의 개념을 바꾸고 있다. 도커 버전 시스템의 git과 유사한 특성에서 증명하듯이 시간 소모적, sys-admin 중심 모델에서 개발자 지향 워크플로우에 더 초점을 맞춘 모델로 변환하고 있다.

도커는 하드웨어를 따라하지 하는 것이 아니라 어플리케이션을 실행하는 것에 초점을 맞춘 가상화 프레임워크다. 처음에는 쉬워보이지만 도커와 같은 운영체제 수준의 가상화 소프트웨어와 머신 레벨 가상화 간의 중요한 차이가 있다. 머신레벨 가상머신은 RAM 할당, 할당할 CPU 수, NIC 에뮬레이션 등 하드웨어를 재생성하기 위한 것이다. 운영체제 레벨의 가상화는 기계가 아니라 어플리케이션에 대한 것이다. 소프트웨어를 개발, 테스트, 출시하는 대부분의 경우는 기존 하드웨어 및 기타 케이스를 모방한 경우를 제외하고, 하드웨어 환경이 아니라 '어플리케이션'에 관심이 있다.

어떤 커뮤니티에 도움을 요청하는 글을 적을 때, 'XX모듈이 잘 작동하려면 Intel Core2Duo 프로세서4개~, 램16GB ~ 등등이 필요하다'고 말하지 않는다. 우리의 문제가 하드웨어에 국한되어있지 않는 한 소프트웨어에 초점을 맞춘다. 이런 일을 도커가 한다. 일반적으로 도커의 메모리 용량, 하드 드라이브의 크기 또는 CPU 사용량을 정의할 이유가 없다. 하물며 일반적으로 데스크톱에 쓰는 코드에도 이 작업을 수행하지 않는다.

실제로 도커를 실행하는 컴퓨터는 일반적인 가상 시스템을 실행하는 동일한 컴퓨터보다 더 많은 동시 가상 인스턴스를 실행할 수 있다. 동일한 데스크톱에서 머신레벨 가상화를 쓸 때 두개의 virtualbox 인스턴스를 동시에 실행하는데 어려움을 겪었다. 하지만 도커를 쓰면 40개가 넘는 컨테이너를 호스트 시스템 성능 저하 없이 실행할 수 있었다.

Running Docker

도커를 운영하는 것이 어떻게 보이나요? 도커 소프트웨어를 설치한 후에는 작업을 시작, 중지, 가져오기, 내보내기 및 기타 작업을 수행할 수 이는 기본 이진 도커가 남게 된다. 다음은 몇 개의 컨테이너를 실행하는 도커 호스트의 예시이다 명령줄에서 도커를 실행하면 이를 확인할 수 있다.

개별 도커 인스턴스는 이미지와 컨테이너로 분할된다. 컨테이너는 이미지 인스턴스를 실행한다. 동일한 이미지 또는 해당 이미지의 변형에서 가져온 여러 컨테이너를 사용할 수 있다. 위의 목록에서 커테이너 IDb58946da298c 및 e5a0f8a71f7e가 이미지 "papyrus-demo" 버전을 실행 중임을 알 수 있으며, 이미지에는 공통 이미지의 다른 상태를 나타내는 깃 태그가 있을 수 있음을 보여준다. 파피루스 데모의 이미지에는 "in-process" 태그와 "port6000" 태그가 있으며, 별도의 태그가 없는 이미지는 항상 "latest"입니다.

A simple example: Article-as-container

Docker의 작동 방식을 보여주기 위해 Pandoc를 통해 이 기사가 원래 쓰였던 Markdown을 HTML로 변환하여 Python SimpleHTTPServer 모듈을 사용하여 서비스를 제공하는 컨테이너를 만들었다. 이 문서에 대한 Github 저장소에서 Docker 컨테이너를 가져올 수 있다.

이것은 매우 간단한 도커 컨테이너이며 두 가지 요소로 구성되어 있다. 첫 번째 파일인 도커 파일은 이미지가 처음 작성될 때 실행되고, 두 번째 파일인 start.sh는 이미지가 컨테이너로 인스턴스화될 때마다 실행된다. 기사 텍스트는 c4l-docker-article.md에 있으며, pandoc에 의해 변환되어 Simple과 함께 제공되는 파일이다.

구성 요소와 실행 방법을 알아볼 것이다.

Dockerfile

우리는 도커파일을 한줄 씩 뜯어볼 것이다.

FROM ubuntu:latest
이것은 베이스로 사용할 이미지다. 이 경우엔 도커의 stock인 우분투 이미지를 기반으로 한 building이다.

MAINTAINER John Fink <john.fink@gmail.com>
생성된 이미지의 유지(The maintainer)

Run echo "deb http://archive.ubuntu.com/ubuntu precise universe" >> /etc/apt/sources.list
RUN 선언은 생성된 이미지와 함께 명령을 수행한다. 이 경우엔 우분투의 원본 목록에 universe 저장소를 추가하므로 나중에 Pando를 설치할 수 있다.

RUN DEBIAN_FRONTEND=noninteractive apt-get update RUN DEBIAN_FRONTEND=noninteractive apt-ge -y install python git pandoc
두 개의 RUN 선언은 우부투를 업데이트하고 필수적인 패키지를 설치한다.

ADD ./start.sh /start.sh
ADD는 외부의 building image로부터 파일을 삽입한다. start.sh에 이미지가 더해졌다.

RUN mkdir /article/ ADD ./c4l-docker-article.md/article/c4l-docker-article.md
RUN, ADD 함꼐 디렉토리를 만들고 마크다운 기사를 더했다.

EXPOSE 8888
EXPOSE 도커에게 이미지로 만들어진 컨테이너가 작동되는 프로그램을 가질 것이라고 말한다. 그 프로그램 작동은 port888번에 접근할 수 있게 되어야 ㅏㄴ다. 이 경우엔 Python의 SimpleHTTPServer를 위함이다.

CMD ["/bin/bash", "/start.sh"]
CMD 선언은 기본 프로그램을 정의한다. 그 프로그램은 만약 특정한 명령이 주어지지 않았다면 컨테이너에서 실행될 프로그램이다. 우리는 start.sh가 /bin/bash를 이용하여 작동하길 원한다.

start.sh

cd /article/
pandoc c4l-docer-article.md -o index.html
python 0m SimpleHTTPServer 888

매우 간단한 start.sh 파일은 위와 같이 생겼다.
해야할 것은 article's directory에 들어가는 것이다. markdown에서 html로 기사를 변환하고, 기사에 제공할 Python SimpleHTTPServer를 실행한다.

Building the article container

도커 빌드 명령어를 실행하면 컨테이너를 만든다. 명령은도커 파일의 각 행을 구문분석하여 각 단계를 커밋으로 저장하고 다음 커밋을 맨 위에 계층화한다.오류가 감지되면 롤백하기가 쉽다. 성능 보너스로 도커 빌드의 후속 호출은 이전 레이어를 캐시로 사용하며, 라인이 변경될 때만 새로운 레이어를 구축한다. 이렇게 하면 일반적으로 편집한 이미지를 매우 빠르게 만들 수 있다.

docker build -t c4l-docker-wordpress git://github.com/jbfink/c4l-docker-article

빌드한 후에 컨테이너를 아래 명령어와 함께 시작한다.
docker run -Pd c4l-docker-article

도커 실행 명령을 실행할 때처럼 c4l 도커 아티클 이미지에서 새 컨테이너가 생성될 때마다 도커파일에서 CMD 선언이 실행된다. 이 경우엔 start.sh가 실행된다. 이 파일은 기사를 마크다운에서 html로 변환하고, 파일을 제공하기 위해 SimpleHTTPServer를 작동시킨다. P 플래그가 도커에 호스트의 임의 포트를 커테이너 포트8888에 노출하도록 한다. 그러면 SimpleHTTPSErver는 외곽에서 컨테이너에 도달할 수 있다. 도커 ps를 실행하는 것은 새로운 컨테이너와 그 컨테이너에 무작위로 배정된 포트를 보여준다. 웹 브라우저가 있는 해당 포트의 도커 호스트로 이동하면 아티클이 렌더링된다.

A real-world example: WordPress

2013년 봄, 나는 사내에서 개발 프로젝트에 사용할 목적으로 도커 워드프레스 컨테이너를 만들기 시작했다. 왜 워드프레스인가? WordPress는 라이브러리 소프트웨어의 white lab rat이다. 어디에서나 사용되고, 잘 지원되고, 잘 이해되며, 일반적으로 관리하기도 쉽고, 많은 보조 소프트웨어를 갖추고 있다. 도커의 능력을 테스트하는 실제 사례다. 처음에는 수동으로 컨테이너를 빌드했다. 즉, bash 셸을 실행하는 단일 Docker 컨테이너를 시작하고 기본적으로 위의 Docker 파일의 단계를 수동으로 수행한다(구성 파일의 일반적인 apt-gets 및 vim 편집). 도커 인덱스[27]에 올렸고, 몇 명의 사람들이 이메일로 어떻게 만들었는지 연락을 받았다. 2013년 8월, 나는 사람들이 가지고 놀 수 있고 만들 수 있는 구조화된 방식으로 제가 했던 것을 만들 수 있는 도커 워드프레스[28]에 대한 작업을 시작했다. WordPress를 정상적으로 설정하고 Docker 영상으로 고정한 다음 다른 곳에서 실행하면 구성이 동일한 컨테이너(동일한 MySQL 암호 및 WordPress salts 및 PHP의 키)에서 동일하게 유지된다. 이상적으로는 도커 워드 프레스를 실행할 때마다 모든 Fiddly WordPress 구성 옵션에 대해 다른 값이 있어야 하므로, 도커 워드 프레스에는 wp-config.silt와 같은 것에 대한 값을 설정하기 위해 처음 시작할 때 일련의 명령을 실행하는 start.sh [29]가 포함되어 있다.

sed -e "s/database_name_here/$WORDPRESS_DB/
s/username_here/$WORDPRESS_DB/
s/password_here/$WORDPRESS_PASSWORD/
/'AUTH_KEY'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'SECURE_AUTH_KEY'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'LOGGED_IN_KEY'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'NONCE_KEY'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'AUTH_SALT'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'SECURE_AUTH_SALT'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'LOGGED_IN_SALT'/s/put your unique phrase here/`pwgen -c -n -1 65`/
/'NONCE_SALT'/s/put your unique phrase here/`pwgen -c -n -1 65`/" /var/www/wp-config-sample.php > /var/www/wp-config.php

이렇게 하면 처음 도커 워드 프레스를 실행할 때마다 중요 변수에 대한 다른 값이 로드된다. 이것을 초기 빌드 [30]의 소스 출력과 결합하면 시작 시간이 상당히 길지만 이후 실행에는 보통 30초도 걸리지 않으며, 재구축(캐슁할 수 있음)은 구성 요소 소프트웨어에 대한 주요 업데이트가 발생할 때만 수행되어야 한다. 도커 워드 프레스 이미지를 실행하는 것은 매우 간단한 문제이며, 새 컨테이너를 생성하는 데 약 1초가 소요되며, 이후 내부 IP를 통해 액세스하거나 호스트 시스템의 외부 포트를 지정할 수 있다.

도커 워드프레스는 하나의 이미지이고, 하나의 컨테이너에서 실행할 수 있고, 이해하기 쉽다는 점에서 큰 장점이 있다. 하지만 그것을 생산형 인스턴스에 좋은 모델로 간주하는 것은 실수일 것이다. 특히, 로그(Logstash [31])에 대한 slapdash 접근법과 로컬 MySQL 인스턴스 포함은 현재 작성되고 있는 프로덕션 환경에서 판매하기 어렵게 만든다. 각각 자체 데이터베이스를 사용하는 도커 워드 프레스를 20개 실행하는 것을 고려해 보라. 여러 WordPress 인스턴스를 지원하는 단일 MySQL 서버를 사용하는 것이 훨씬 더 현명할 것이다.

Conclusion

도커는 본격적으로 1년 넘게 개발되고 있으며, 그 기간동안 창작자들은 사람들이 생산성이 뛰어난 준비된 프레임워크로서 도커를 사용하는 것을 단념시켰다. 그러나 6월 9일 Docker는 1.0[32]의 상태에 도달했고, 생산 인스턴스에 대한 준비가 된 것으로 간주해야 한다. 더 중요한 것은 Docker 1.0은 모든 이전 버전의 도커와 호환되므로 도커를 처음 출시했을 때 작업했던 프로젝트를 계쏙 쓸 수 있다는 것이다.

그러나 더 난해한 애플리케이션을 도커에 포팅하는 것은 아직 쉬운 절차가 아니다. 도커는 MySql과 아파치 같은 일반적인 프로그램을 일반적인 백그라운드 모드에서 포그라운드 모드로 변환해야 하며, 도커는 컨테이너당 하나의 애플리케이션에 초점을 맞춘 것(감독자의 신중한 사용을 통해 많은 다른 도커 응용 프로그램에서 달성)을 통해 실행 중인 제품을 만든다. 기존 VM 또는 베어 아이언 구현에 더 적합하고 최적의 설치 절차보다 다소 덜 복잡한 설치 절차를 거친다.

Docker에서 아직 수행되지 않은 작업에도 불구하고, 안정적인 상태[32]에 빠르게 접근하고 있으며 라이브러리의 가상화 활동에 통합할 수 있는 확실한 가능성을 보여주고 있다. 소프트웨어 개발의 경우 프로그래머가 코드를 체크할 때, 도커 파일을 소스 코드에 포함시켜 원격 서버에서 코드를 빠르게 테스트하거나, 다른 사용자가 특정 건물 지침이나 종속성 관리에 대해 걱정할 필요 없이 응용 프로그램의 버전을 빠르게 가져올 수 있도록 하는 데모 도구로서 사용할 수 있습니다. e. Docker는 백업 전략으로 사용될 수 있습니다. 즉, 라이브러리 웹 사이트의 백업 스크립트의 일부로, 서비스 중단 시 신속한 배포를 위해 Docker 이미지를 구축할 수 있다. 그리고 정기적인 시스템 관리 작업의 경우, 대규모 설치 절차를 단일 명령으로 요약하는 것은 누구나 좋아할 것이다.