Synology NAS 패키지 센터에 있는 Gitlab 설치 시에 꼭 해야 하는 것

gitlab….. 상당히 편한 녀석이다. 규링은 시놀로지에서 엄청나게 잘 쓰고 있기도 하고…

근데 어떤 썩을 것 땜에 시놀로지 나스 시스템이 망가졌다. ㅠㅠ

망할 것… 두고보자…

뭐, 이 기회에 욕심나던 작업도 있고 해서 데이터를 일단 외장하드로 다 뜬 다음에, 그대로 공장 초기화를 시키기로 해서 초기화 진행. 그리고 필요한 것들을 하나 하나 설치하고 있는데….

gitlab 설치할 때에는 패키지 구성되어 있는 걸 설치해서 간단하게 설치하자 해서 패키지 센터에 있는 녀석으로 설치를 했다. 자기 혼자 알아서 도커도 깔아주고, 자기 혼자 알아서 이미지 떠서 도중도중 입력한 smtp 정보나 도메인 정보, 관리자 계정 이메일 등의 여러 설정값 넣어준대로 알아서 잘 되나 싶은데…

계속 시작도 못하고 죽는다…!

docket의 상태 로그… 자꾸 데이터베이스 관련해서 죽는다.

자꾸 데이터베이스 관련해서 죽는다….

….이게 왜 이런가 싶어서 자동으로 만들어진 도커들을 살펴보는데 거기에 답이 있었다.

시놀로지 gitlab을 패키지로 설치하면 저렇게 셋이 생긴다. 지금은 문제가 없으니 다 잘 돈다. ㅠㅠ

내가 안되던 때에는 맨 위에 있는 gitlab 본체의 컨테이너만 실행이 안되어있었다. 근데, 그 밑에 DB쪽인 postgresql은 멀쩡하게 돌고, redis도 멀쩡하게 돌고 있었다. 그 말인 즉, 본체에서 디비에 접근을 못해서 지 멋대로 꺼진 건데…

그럼 걍 네트워크 브릿지가 막힌거네..?

해서 브릿지 정보를 확인하고….

브릿지 정보. 설치 당시 만든 브릿지인데 일단 그대로 쓰고 있다. 필요하면 더 만들면 그만이다.

브릿지 정보에 있는 저 IP와 서브넷 정보를 방화벽에서 규칙 허용을 해줘야 한다…! gitlab 포트의 방화벽 허용과는 별개로..!

그전에 정보 적고 올린 것들은 아마 방화벽 설정따윈 하나도 안한 채로 막 쓰고 있는 것들이겠지….!!!! 머리를 장식으로 달고 글쓰는 거냐..!!!!!

방화벽 규칙의 예시.

방화벽을 적용하는 데에는 규칙이 있다. 아무것도 없으면 방화벽은 동작 안하는 거나 마찬가지이다. 그래서 허용할 규칙에 대해서 해당 소스가 되는 ip 정보와 포트 정보를 입력하여 허용을 진행하고, 그 외에는 전부 거부를 하는 것이다. 그렇게 해서 허용하는 목록만 허용하게 되고 나머진 다 막는 것이 방화벽 적용 규칙이다. 이 부분에 허용을 안했으니 막힐 수밖에….ㅠㅠ

분명 아무것도 안하고 그냥 설치했더니 바로 실행되었어요 하는 것들… 방화벽 규칙이나 보안 규칙 빡시게 안잡은 것들일꺼다 분명…

근데 보안 땜에 방화벽을 먼저 설정 싹 다 해놓고 gitlab을 설치해서 쓰니깐 gitlab은 도커 브릿지 네트워크 통해서 네트워크 인터페이스가 되어 있으니 당연하게도 저쪽에서 막힌 것이다. 그러니 저쪽을 열어주면 해결.

참고로 라우터에서 포트포워딩까지는 안열어줘도 된다. 실제로 외부로 포트포워딩을 해야 하는 gitlab 접속할 때 이용할 포트(시놀로지 패키지 기본 설정 포트가 둘 있다. 그 둘만 해줘도 됨.)는 방화벽도 허용해줘야 하는 것이긴 하지만, 라우터의 포트포워딩쪽에서는 브릿지쪽은 안해줘도 외부 접속은 문제 없다. gitlab 구성요소들간의 통신의 문제를 해결하기 위한 것이니 나스의 네트워크 방화벽만 허용되어도 된다.

이거 땜에 시간은 날려먹었지만….

잊을만한 내용을 다시 상기하기에는 좋은 것 같아서 공유를 하려고 한다.

이런 정보는 삽질하면서 얻은 거니 블로그 글로 남겨야지….ㅠㅠ

이런 지식을 공유함으로써 얻게 되는 기쁨…?

p.s. 해당 서비스마다의 ip를 열어주는 것도 좋지만, 방화벽 설정 규칙이 너무 번거로워지기 땜누에 별로 추천하고 싶진 않다. 포트 범위는 nmap 같은 곳에서 잘 안잡히지만 특정 포트는 nmap으로 쉽게 스캔되기 때문에 공격 당하기 참 좋은 구실을 만들어 줄 수도 있다.

Docker Hub의 이미지로 도커를 사용해보기 – 1

도커에서 필요로 하는 이미지는 직접 만들어서 쓸 수도 있지만, Docker Hub에 이미 만들어진 것을 가져다가 쓸 수도 있다. 일단 기본적으로 사용하는 명령어들을 익히기 위해서 Docker Hub에서 제공되는 이미지를 이용하여 직접 실행하는 것을 정리해 보려고 한다. 도커를 이용하는 데 있어서 가장 기본적인 명령어들이니 그냥 있는 이미지를 가지고 이용하는 방법으로 작성해 보도록 하겠다.

사실 그냥 Docker Hub에 대해서는 별 거 없다. github를 처음 사용할 때와 비슷한 화면을 볼 수 있을 것이다.

그런데, 실제로 보면 이미 유명한 환경에 대해서는 이미 이미지를 별도로 배포하고 있다. 유명한 리눅스의 배포판, 오픈소스 프로젝트 등의 이미지, 그것도 가장 기본적인 이미지는 Docker Hub에서 제공을 하고 있다.

특히, 이미지와 관련된 모든 명령어는 기본적으로 Docker Hub와 연동이 되어있다. 이제 이 연동되어 있는 내용을 확인하고, 실제로 사용하도록 한다.

search

search 명령어로 이미지를 검색할 수 있다.

여러 목록들이 쭉 나올 것이다. 우분투의 기본 공식 이미지부터 시작해서 다른 사람들이 자기 원하는대로 이용할 수 있는 판까지 다양하게 존재한다. 이 목록들은 docker hub에도 그대로 나타난다.

pull

pull 명령으로 이미지를 직접 받아오도록 한다. docker를 설치하면 기본적으로 이미지를 받아오는 곳은 docker hub에서 받아오도록 되어있다.

받아오는 동안에 여러모로 받아오는데, 바로 컨테이너의 버전에 맞춰서 별도로 받아온 다음에 하나의 컨테이너로 구성해서 이용할 수 있게 해주는 것이다. 업데이트가 많이 되는 이미지들일수록 여러 버전들을 쫙 받아서 가장 최신으로 합쳐주는 작업을 할 것이다.

images

도커에 있는 모든 이미지들을 보려고 할 때 사용하는 명령어이다. 우분투 이미지가 받아졌는지 확인해보자.

제대로 받아져있다.

글이 좀 길어져서 직접 실행하는 run 관련된 부분과 그 후의 내용은 2편에서 작성하겠다.

docker 사용 시 sudo 명령 일일이 치지 않게 하기

사실 좀 위험하다고 생각한다. docker 권한이 root 권한을 이용하기 때문에 sudo 를 사용하도록 해야 그나마 좀 더 보안적인 요소가 되긴 한다만..

자주 쓰는 머신이고, 나 혼자서만 쓴다면 진짜로 귀찮은 게 현실이다. 그렇다면 이걸 항상 root가 아니라 내 계정으로 쓰게 하고 싶은 것이다. 이럴 때에는 할 수 있는 방법이 두 방법이 있다.

  • root로 로그인을 한다
  • 내 계정을 docker 그룹에 추가한다.

root 계정으로 로그인…. 하지마라. 상식이 있다면 안할 것이다.

그럼 선택지는 이거 뿐이다. 내 계정을 docker 그룹에 추가하는 것.

사실 해당 내용에 대해서는 리눅스에서 자동 설치 스크립트로 설치를 하게 되면 하는 방법과 함께 경고를 날려준다. 도커 호스트를 이용하는 작업 자체가 루트 권한을 이용해야 하기 때문에 여러모로 말이 많게 나오는 것이다. 그러나 귀찮다면 직접 입력해보자. 아, 실행 후에 서비스 재시작도 꼭 해줘야 한다.

이제 이게 제대로 되어있는지 확인해보자. 도커를 이용하여 우분투 컨테이너를 받아오려고 한다.

그냥 잘 받아와지고 있다. 앞으로 예제에 그냥 sudo 안쓰고 하려고 하는데 이게 왜 이러냐고 물어보는 건 더 없기를…

 

리눅스에서의 도커 설치

리눅스 환경에 친화적인 것이 도커이다보니 리눅스쪽의 설치가 좀 더 자세하게 나와있다. 반면 맥과 윈도우의 경우에는 여러모로 프레임워크와 라이브러리화 되어 있기 때문에 그걸 그대로 설치하여 쓰는 형태로 구성되어서, 설치 프로그램으로 만들어져 있다. 그것이 이전 글에서 쓴 Docker Toolbox이다.

리눅스에서 동작하는 도커 환경은 모든 작업이 root 권한을 요구한다. 그래서 죄다 sudo를 이용하여 설치한다는 걸 먼저 알아두면 좋다. 그럼 이제 리눅스에서 설치하는 방법을 이야기하려 한다. 

  • 자동 설치 스크립트를 이용하려 설치하기
  • 패키지 배포판을 이용하여 설치하기
  • 최신 바이너리 받아서 설치하기

일단 가장 쉽게 하는 것이 바로 자동 설치 스크립트를 이용하여 설치하는 것이다. 이걸 이용하면 리눅스 배포판과 버전에 맞춰서 알아서 설치할 수 있도록 해준다. 설치 스크립트는 “sudo wget -qO- https://get.docker.com/ | sh”인데, 아래의 화면을 참고하면 된다. 참고로 규링의 경우에는 이미 설치를 한 경우라서 다시 설치하려 하니깐 오류가 난 것이다.


패키지 배포판으로도 또한 존재한다. 우분투 환경에서는 docker.io라는 이름으로, 레드햇 계열에서는 docker-io라는 이름으로 존재한다. 패키지 배포판에서 검색해서 직접 이름을 확인하고 설치를 하면 된다.

마지막으로 최신 바이너리를 직접 받아서 수동으로 설치하는 방법이 있다. 자동 설치 스크립트가 실패한 경우에 수동으로 직접 압축된 바이너리를 풀어서 사용하는 것이다. 또한 패키지 배포판으로는 도저히 최신 버전이 올라가지 않는 경우나 각각의 리눅스 배포판마다 전부 다 지원하는 것이 아니다보니 직접 이걸로 설치해서 쓰는 경우에도 있다.

참고로 자동 설치 스크립트를 이용하면 기본적으로 hello-world가 있다. 안쓸 경우에는 도커에서 제거 명령어를 이용하면 된다.

Docker Toolbox – 윈도우와 맥에서 도커 설치

도커는 주로 리눅스 환경에서 동작하는 것을 기준으로 한다. 그러나, 맥과 윈도우에서도 도커를 쓰지 못하는 건 아니다. 그걸 위해서 별도의 패키지가 존재한다.

이전에는  Boot2Docker라는 프로젝트로 배포가 되었었는데, 이건 더 이상 업데이트가 되질 않는다. 그리고 나서 도커쪽에서 나온 것이 바로 Docker Toolbox이다. 인스톨러 형식으로 되어 있으며, 동작시키기도 어려운 환경은 아니게 되었다.

홈페이지 화면이다. 다운로드 링크가 있으며, 아래로 내려가거나 메뉴에 보면 튜토리얼이 나와있다. 도커 튜토리얼과도 연동되어 있으니 그냥 그대로 쓰기만 하면 된다.

설치도 인스톨러 방식이다. 이건 윈도우도 마찬가지다. 단, 윈도우의 경우에는 관리자 권한을 허용하는 화면이 마저 나올 것이다.

도커를 시작하는 방법이라면서 나오는데, 어플리케이션에도 똑같은 녀석이 있다. 근데 커맨드 라인에서 동작하는 도커를 별도의 실행 아이콘을 만들어서 터미널로 연동시켜주는 걸 이해를 못하겠다. 아무래도 윈도우 환경을 의식한 거 같다.

어플리케이션에도 똑같은 것이 있고..

실행된 터미널에서 docker라고 입력만 한 화면이다. 제대로 실행되어 사용 방법을 알려주는 걸 보여준다.

이처럼 윈도우랑 맥에서는 진짜 쉽게 설치를 할 수 있다. 리눅스에서는 여러모로 설치 방법들이 나와있기 때문에 좀 별도로 내용을 작성해야 한다.

Union File System

도커의 이미지와 컨테이너 개념글에서 다뤘던 내용입니다만, 도커는 실행중에 변경된 부분을 이미지로 생성할 수 있다고도 적었습니다. 이게 가능하도록 하는 것이 바로 Union File System(UnionFS)입니다.

이 파일 시스템은 읽기 전용의 파일 혹은 디바이스에서 변경 사항을 기록하여 저장할 수 있도록 해주는 파일 시스템이다. 읽기 전용 파일을 실행할 경우, 해당 파일에 대해 쓰기가 가능한 임시 파일을 생성하여 읽기 파일을 그대로 복제하여 실행을 하게 된다. 그 다음, 수정이 된 내용에 대해 모두 사용하였다면 쓰기 작업을 진행한 다음, 기존의 읽기 파일을 대체한다. 이러한 방식을 Union Mount라고 한다.

도커에서도 해당 이미지 파일을 기본적으로 UnionFS가 지원되는 파일이다. 이 파일을 위의 Union Mount 처리를 하여 지속적인 변경 사항을 작성하여 업데이트 되는 것이다.

UnionFS를 잘 이용한 방식은 리눅스 배포판 중에 크노픽스(Knoppix)라는 배포판이 있다. 이 배포판은 CD 혹은 DVD에서 실행하는 라이브 운영체제 형식으로 배포되는데, 부팅 과정과 운영체제의 기본 실행은 램디스크에서 부팅 및 실행을 하면서도 변경된 사항에 대해서는 컴퓨터에 연결된 보조 저장장치(쓰기 가능)에 저장을 하여 다음에 실행될 때 해당 변경사항을 부팅 후 읽어들여서 적용시킨다.

유저랜드(userland) = 사용자 공간(user space)

운영체제에서는 메모리 사용을 기준으로 커널 영역(커널 공간)과 사용자 영역(사용자 공간)을 나눕니다. 운영체제가 부팅될 때, 부팅을 위해 이용되는 맨 앞의 작은 용량 다음에 운영체제 자체의 핵심 기능들을 실행하기 위해 올려놓는 공간을 주로 커널 영역이라 하고, 그 외에 영역에 대해서는 사용자가 이용할 수 있는 영역이라 하여 사용자 영역이라고 합니다.

이제 여기서 사용자 영역에서 실행되는 실행 파일과 라이브러리를 유저랜드라고 합니다. 특히 리눅스의 경우에는 커널만으론 부팅을 할 수 없습니다. 그래서 파일시스템에서 데이터를 불러오는데, 이때 불러오는 것은 부팅에 필요한 최소한의 실행 파일과 라이브러리, 그리고 고유의 패키징 시스템을 포함한 데이터를 불러옵니다. (시스템 데몬, 윈도우 라이브러리, 그래픽 라이브러리, 그 외 각종 라이브러리 등) 이 라이브러리들을 불러오면서 가상 메모리를 이용할 수 있게 되는 것 뿐만 아니라 사용자가 사용할 수 있는 공간을 만들 수 있도록 해줍니다. 운영체제 내용 정리할 때 다시 저세히 다루기로 하죠.

도커의 이미지와 컨테이너 개념

음.. 뭐랄까. 도커에는 이미지와 컨테이너라는 개념이 있는데, 이 기본적인 부분에 대해서도 사실 좀 나눠서 설명할 수 있느냐 아니냐에 따라서도 이야기가 좀 달라집니다. 조금만 보면 금방 다른 이야기라는 것이 알 수 있지만, 한번의 설명글이 있는 쪽이 좀 더 좋겠군요. 우선 이미지가 좀 많이 좋은 것이 있어서 그걸 가져와서 설명을 하겠습니다.

우선은 가장 기본이 되는 베이스 이미지가 있습니다. 이는 리눅스 배포판의 유저랜드만 설치된 파일을 말합니다. 보통은 리눅스 배포판 이름으로 구성되어 있습니다. 아니면 리눅스 배포판 유저랜드(사용자 공간)에 Redis나 Nginx 등이 설치된 베이스 이미지도 만들 수 있습니다. 그래서 도커의 이미지라고 하면 주로 베이스 이미지에 필요한 프로그램과 라이브러리, 소스를 설치한 뒤 파일 하나로 만들어낸 것을 가리킵니다. 각 리눅스의 배포판 이름으로 된 베이스 이미지는 배포판 특유의 패키징 시스템을 이용할 수 있습니다. 우분투라면 apt-get을, 레드햇 계열이라면 요즘은 DNF를 이용하겠군요. 또한 원하는 베이스 이미지는 직접 만들어서 사용할 수 있습니다.

근데 이것이 매번 베이스 이미지에다가 필요한 프로그램과 라이브러리, 소스 등을 추가하다 보면 용량이 큰 이미지가 지속적으로 생길 것이라고 생각하는데, 위의 그림과 같이 변화된 곳만 별도로 이미지가 생기고, 실행할 때에는 베이스 이미지와 바뀐 부분이 합쳐져서 실행됩니다. 그래서 도커는 초기 환경이나 업데이트된 환경이나 그렇게 큰 구조를 가지지 않습니다.

아래에는 도커 이미지에 대한 버전 업데이트의 의존 트리를 보여줍니다. 구조를 보시면 개발자들이 개발한 소스코드의 버전 관리 트리와 비슷한 구조인 것을 보실 수 있습니다.

거의 git하고 비슷하죠. 16진수의 특정 ID로 구분되고, 각 이미지에 대해서는 독립적인 형태로 진행됩니다. consumer, nodeflakes, nodeflakes-server로 최종적인 구조에서 별도의 작업 단위로 branch가 진행되어 조금씩 수정되어 이용되는 구조인 듯 합니다. 정리하자면, 도커는 이미지를 통째로 생성하지 않고, 바뀐 부분에 대해서만 생성을 진행한 뒤, 부모 이미지를 계속 참조하는 방식으로 동작합니다. 도커에서는 이를 “레이어”라고 합니다.

도커의 이미지는 파일입니다. 그렇기 때문에 저장소에 올린 뒤에 다른 곳에서도 받을 수 있습니다. 그리고 저장소에 올릴 때에는 자식 이미지와 부모 이미지를 함께 올립니다. 받을 때도 똑같습니다. 이후에는 수정된 이미지만 주고 받는 구조입니다.

이미지에 대한 설명은 여기까지이고 이제 컨테이너에 대한 설명을 하겠습니다. 컨테이너는 이미지를 “실행한 상태”입니다. 이미지로 여러 개의 컨테이너를 만들 수 있습니다. 운영체제로 생각해 본다면 이미지는 [실행 파일]이고 컨테이너는 [프로세스]입니다. 이미 실행된 컨테이너에서 변경된 부분을 이미지로 생성할 수도 있습니다. 이렇게 운영체제와 비교해서 보니, 도커는 특정 실행 파일 또는 스크립트를 위한 특정 실행환경이라고도 볼 수 있겠군요. 그러면 이제 앞에서 봤던, 아래의 그림과 같은 설명이 이해가 되는 겁니다. 하이퍼바이저와 게스트 운영체제의 자리를 도커가 가지고 가는 구조죠.

리눅스와 유닉스 계열에서는 파일 실행에 필요한 모든 구성요소가 잘게 쪼개져 있습니다. 이는 시스템 구조가 단순해지고 명확해지는 장점이 있습니다만 의존성 관계를 해결하기 어려워지는 단점을 가지고 있습니다. 그래서 리눅스와 유닉스 계열에서는 각 배포판마다 미리 컴파일 된 형식으로 프로그램을 배포하고 그 의존성을 미리 검사할 수 있는, 일명 패키지라는 시스템이 만들어지게 됩니다. 하지만 서버를 실행할 때마다 일일이 소스를 컴파일하거나 패키지를 설치하고 설정하고 하는 작업은 상당히 귀찮은 작업입니다. 서버 대수가 많아지면 더 할 말이 없습니다. 이때 도커 이미지를 사용하면 실행할 서버가 몇 대든간에 이미지를 실행하여 컨테이너를 계속 만들어 쓰면 됩니다.

도커하면 빠지지 않는 기본 이야기: 리눅스 컨테이너

도커에 대한 설명을 하다보면 거의 항상 설명하고 하는 것이 있는데, 바로 LXC(LinuX Container)입니다. 오래전부터, 리눅스/유닉스 환경에서는 chroot라는 명령어를 제공했습니다. 이 명령어는 파일 시스템에서 루트 디렉터리(/)를 변경하는 명령어입니다.

이렇게 특정 디렉토리를 루트 디렉토리로 변경하게 되면chroot jail이라는 환경이 생성되는데, 이 안에서는 바깥의 파일과 디렉터리에 접근할 수 없게 됩니다. 경로 자체가 격리되기 때문에 서버 정보의 유출과 피해를 최소화하는 데 주로 이용되어 왔던 기술입니다. 그러나 chroot는 chroot jail에 들어갈 실행 파일과 공유 라이브러리를 직접 준비해야 하고 설정 방법 또한 상당히 복잡합니다. 또한 완벽한 가상 환경이 아니기 때문에 제약 또한 상당히 많습니다. 이러한 환경을 Confined Environment라고 합니다.

이후에 리눅스에서는 LXC라는 시스템 레벨의 가상화를 제공하게 됩니다. LXC는 컴퓨터를 통째로 가상화하여 OS를 실행하는 것이 아니라 리눅스 커널 레벨에서 제공하는 일종의 격리된 가상 공간을 제공합니다. 이 가상 공간에는 운영체제가 설치되지 않고 호스트의 리눅스를 그대로 이용하기 때문에 가상 머신이라고 안하고 컨테이너라고 합니다. 아래의 이미지가 LXC를 설명하기 가장 좋은 이미지인 듯 하군요.

리눅스 커널의 자원 일부를 그대로 이용합니다. 리눅스 커널의 cgroups(control groups)를 통해 CPU, 메모리, 디스크, 네트웤 자원을 할당하여 완벽한 가상 공간을 제공합니다. 또한 프로세스 트리, 사용자 계정, 파일 시스템, IPC 등을 별도로 격리시켜서 호스트와 별개의 공간을 따로 만듭니다. 이렇게 격리된 곳이 바로 namespaces입니다. 마지막으로 보안 관리를 제공하는 SELinux(Security-Enhanced Linux) 또한 가상화된 공간에서 제공하여 보안도 호스트와 같은 수준으로 제공합니다. 즉, cgroups와 namespaces, SELinux 기능을 활용하여서 가상 공간을 제공하게 되는 겁니다. 추가적으로 필요한 자원이 있다면 드라이버를 가상 환경에 연결하여 지원해줍니다.

하지만, LXC는 격리된 공간에 대한 지원만을 할 뿐, 개발 및 서버 운영에 필요한 부가 기능에 대해서는 상당히 부족한 상황입니다. 도커는 이 리눅스 커널에서의 cgroups, namespaces, SELinux 기능을 기반으로 하여 이미지, 컨테이너의 생성 및 관리 기능과 다양한 부가 기능을 지원할 수 있도록 개발된 것입니다. 그래서 도커에 대한 설명을 하다 보면 자연스럽게 LXC에 대한 설명도 같이 들어가게 됩니다.

도커가 처음 개발될 당시에는 LXC를 통해 구현되었다고 과거 문서들에는 많이 나와있지만, 0.9 버전 이후로부터는 libcontainer를 개발하여 이용하는 것으로 알려져 있습니다. 도커 문서에는 실행 드라이버라고 하는데, native, lxc 중 선택해서 사용할 수 있습니다. lxc는 LXC에서 이용하던 라이브러리입니다. 어떤 것을 이용하는 것이 더 좋은지에 대해서는 여러모로 논의가 이어지고 있습니다만, 양쪽 다 열심히 업데이트 되고 있어서 어떻게 될지는 모르겠군요.

가상머신과 도커의 차이: 성능의 가벼움

도커 자체를 사용하는 입장에서는 그렇게 어렵게 사용하진 않습니다. vmware, kvm, virtualbox, hyper-v 등의 가상 머신을 써왔다면 충분히 쓸 수 있습니다. 구조 또한 비슷합니다. 가상 머신을 만들어서 리눅스를 설치하고, 각종 프로그램과 DB를 설치 후 개발한 프로그램을 올리고 서비스를 실행했습니다. 그리고 이 가상 머신을 여러 서버에 복사해서 실행하면 이 가상 머신 하나로 여러 서버를 계속 만들어냅니다. 도커 또한 마찬가지입니다. 이미지를 만들고, 각종 프로그램과 DB를 설치 후 개발한 프로그램을 올리고 서비스를 똑같이 실행합니다.

가상 머신 서버를 독자적으로 운영하거나 클라우드에서 서비스 형태로 운영되는 PaaS에서도 가상 머신을 이용한 서버 구성을 할 수 있게 되었는데, 이 가상머신으로의 작업은 편하고 이해하기 쉽지만 성능이 좋지 못한 단점이 있습니다. 가상화를 한 CPU나 디스크의 속도는 실제 머신에 비해 훨씬 느리기 때문입니다.

클라우드에서 쓰이는 가상화 환경들은 기존에 데스크톱에서 다른 머신들을 가상화하기 위해 쓰이던 전가상화 (full virtualization) 방식이 아닌 반가상화(para virtualization)을 이용하는 방식으로 구성되었고, 현재도 널리 쓰이지만 실제 머신에 직접 이용되기에는 아직 성능적으로 부족한 부분이 있는 것이 사실입니다.

전가상화와 반가상화는 이 그림이면 설명이 될 거 같군요. 사실 가상화 이론 자체에는 이것 외에도 여러 이론들이 있습니다만, 우선은 이정도만 보면 되겠습니다. 가상 머신 자체에는 게스트 운영체제, 즉 항상 그 안에도 운영체제를 설치해야 합니다. 그러나 도커의 컨테이너 이미지에는 운영체제가 포함되지 않습니다. 그렇기 때문에 가상머신에 비해 훨씬 가벼운 상태가 됩니다. 또한 가상머신 이미지를 여러 서버에 옮겨가는 작업은 네트워크로 이루어지게 될 텐데, 네트워크 속도가 아무리 빨라졌다고 하더라도 운영체제가 설치된 이미지 자체의 용량을 생각하면 결코 적은 용량이 아니게 됩니다. 따라서 배포에 대해서도 부담이 되게 됩니다. 반면에 도커는 게스트 운영체제를 설치하지 않고 이미지에 서버 운영을 위한 프로그램과 라이브러리만 특정하게 격리해서 설치할 수 있고(샌드박스 상태라고 보시면 됩니다.), 운영체제의 자원은 호스트의 자원을 그대로 이용합니다. 이렇게 되면 이미지 용량 자체가 크게 줄어들게 되니 배포에도 부담이 없게 됩니다.

가상 머신과 비교되는 구조입니다. 한 눈에 봐도 도커를 이용한 시스템은 호스트와 그대로 작업이 처리되는데 반해 가상 머신을 이용한 쪽은 중간에 있는 게스트 운영체제에 의해 또 다시 제어되는 걸 볼 수 있습니다.

하드웨어를 가상화하고 운영체제를 가상화 하는 곳 자체가 없기 때문에 메모리 접근 속도, 파일시스템 사용 속도, 네트워크 속도 등에서 가상머신에 비해 월등히 빠른 속도를 가집니다. 도커에서 동작하는 속도를 측정한 표가 검색해서 나왔길래 같이 보도록 하죠. Linpick이라는 테스트 툴을 이용하여 호스트, kvm(가상머신), 도커를 비교한 표입니다.

어떤 상태에서는 도커가 호스트보다 빠를 때도 있지만, 대게 호각이거나 거의 차이가 나지 않을 정도라 해도 될 정도로 미미한 차이가 발생하는 수준이군요. 그에 비하면 가상머신인 kvm의 속도는 확실히 차이가 납니다.

이러한 도커는 관리 몇에 있어서도 이미지 생성과 배포 자체에 특화된 관리 기능을 가지고 있습니다. 앞의 글에서도 도커는 파일 형태로 되어 있으며, 소스 코드 버전 관리처럼 관리할 수 있다고 했는데, 실제로 도커 이미지는 소스 관리하듯 관리할 수 있습니다. 또한 중앙에서 이미지를 올리고 받을 수 있는데, git에서 소스코드 올리고 받는 기능과 같다고 보면 됩니다. (push/pull 기능) github와 같은 기능을 하는 Docker hub(유료)도 존재합니다. 또한 API를 다양하게 지원하기 때문에 원하는 만큼 자동화도 할 수 있습니다. 따라서 개발 및 운용에서도 유용하게 할 수 있습니다.