날탱이가 되고픈 개발자

Synology NAS Docker 우분투 컨테이너 생성하기

NAS Info

Ubuntu 17.04 이미지 다운로드 및 실행

• Docker – 레지스트리 – “ubuntu” 검색 후 “ubuntu” 다운로드

• Docker – 이미지 – ubuntu – 실행 – 마법사로 실행

1 단계에서

컨테이너 이름에 원하는 이름(여기서는 ubuntu1) 넣고.. (hostname 으로 사용됨)

로컬 포트에는 실제 접속 시 사용할 포트(여기서는 8081)를, 컨테이너 포트에는 8080, 유형은 TCP로 설정

2 단계(고급 설정)는

"볼륨" 탭에 컨테이너에서 사용할 볼륨을 지정한다.

물론, 기본적인 볼륨이 생성 되기는 하지만, 필요에 의해서 설치하게 될 sw / application / log 를 위와 같이 NAS 의 영역을 매핑하면

컨테이너가 실행되고 있지 않아도 확인 할 수 있다.

"포트 설정" 탭에서는 컨테이너 포트와 로컬(NAS) 포트 매핑을 정의

컨테이너 실행

빨간색 부분의 스위치 버튼을 클릭하여 컨테이너 실행

SSH 를 이용하여 컨테이너에 터미널 접속

SSH 터미널 접속 툴을 사용하여 NAS 에 접속한다.
다음과 같이 명령행에 입력하면 NAS 의 root 로 접속이 가능하다.

sudo su -

현재 실행되고 있는 도커 컨테이너를 확인 하기 위해 다음 명령어를 입력한다.

docker ps

다음 화면처럼 현재 실행되고 있는 컨테이너 목록을 확인 할 수 있다.

컨테이너에 접속 하기 위하여 다음 명령어를 입력한다.

docker exec -it 6c6aa89df191 /bin/bash

터미널 접속을 위해 SSHD 설치 및 접속

1. SSH 서버 설치

apt-get install ssh

2. 서비스 시작

service sshd start

3. 포트 확인

netstat -tulpn | grep :22

4. 설정
    4.1 sshd_config 파일 오픈

vi /etc/ssh/sshd_config

    4.2 root 로그인 금지

PermitRootLogin no

    4.3 특정 사용자만 허용

AllowUsers user1 user2

    4.4 포트 변경

Port 22

    4.5 저장 및 서비스 restart

service sshd restart

초보를 위한 도커 안내서 - 도커란 무엇인가?

docker logo

서버를 관리한다는 것

복잡하고 어려운 서버관리

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

처음 리눅스를 접하며 매뉴얼을 보고 Redhat Linux 를 설치했던 기억은 정확히 기억이 나지는 않지만 설치 매뉴얼은 길고 복잡했고 알 수 없는 이유로 자꾸 설치를 실패하였습니다. 제대로 설치가 되지 않으면 다시 OS를 설치하는 것부터 반복하여 몇 번을 재설치한 끝에 성공하곤 했습니다.

새로운 서버를 셋팅하는 날은 밤을 새는 날이였고 몇 번 밤을 새다보니 ./configure와 make && make install의 달인이 되어 있었습니다. 어느 정도 익숙해졌다고 생각한 시점에도 리눅스 배포판이 바뀌거나 환경이 달라지면 꼭 문제가 생기곤 했습니다.

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

시간이 흐르면서 서버 환경이 계속 바뀌는데 CentOS에 익숙해지면 Ubuntu를 써보고 싶어지곤 했습니다.

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

도커의 역사

도커는 2013년 3월 산타클라라에서 열린 Pycon Conference에서 dotCloud의 창업자인 Solomon Hykes가 The future of Linux Containers 라는 세션을 발표하면서 처음 세상에 알려졌습니다.

이 발표 이후 도커가 인기를 얻으면서 2013년 10월 아예 회사이름을 도커(Docker Inc.)로 바꾸고 2014년 6월 도커 1.0을 발표합니다. 2014년 8월 도커에 집중하기 위해 dotCloud 플랫폼을 매각하고 2015년 4월 $95M(약 1,100억원) 투자를 유치한 후 계속해서 빠르게 성장하고 있습니다.

The Evolution of the Modern Software Supply Chain - The Docker Survey, 2016

도커에서한 2016년 설문조사에서 90%가 개발에 사용중이고 80%가 DevOps에 사용할 예정이며 58%가 운영환경에서 사용중이라고 합니다. 2014년 도커 서울 밋업을 시작할 때만 해도 대부분의 사람들이 도커를 잘 모르고 개념도 이해하지 못했는데 이제는 거의 모르는 사람이 없을 정도로 널리 쓰이고 있습니다.

도커란?

도커는 컨테이너를 관리하는 플랫폼

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

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

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

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

컨테이너(Container)

docker container

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

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

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

이러한 상황을 개선하기 위해 CPU의 가상화 기술(HVM)을 이용한 KVM_{Kernel-based Virtual Machine}과 반가상화 _{Paravirtualization}방식의 Xen이 등장합니다. 반가상화 방식은 게스트 OS가 필요하긴 하지만 전체OS를 가상화하는 방식이 아니였기 때문에 전가상화 방식에 비해 성능이 향상되었습니다. 이러한 기술들은 OpenStack이나 AWS, Rackspace같은 클라우드 서비스에서 가상 컴퓨팅 기술의 기반이 되었습니다.

가상머신과 도커

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

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

도커의 기본 네트워크 모드는 Bridge모드로 약간의 성능 손실이 있습니다. 네트워크 성능이 중요한 프로그램의 경우 --net=host 옵션을 고려해야 합니다.

하나의 서버에 여러개의 컨테이너를 실행하면 서로 영향을 미치지 않고 독립적으로 실행되어 마치 가벼운 VM_{Virtual Machine}을 사용하는 느낌을 줍니다. 실행중인 컨테이너에 접속하여 명령어를 입력할 수 있고 apt-get이나 yum으로 패키지를 설치할 수 있으며 사용자도 추가하고 여러개의 프로세스를 백그라운드로 실행할 수도 있습니다. CPU나 메모리 사용량을 제한할 수 있고 호스트의 특정 포트와 연결하거나 호스트의 특정 디렉토리를 내부 디렉토리인 것처럼 사용할 수도 있습니다.

새로운 컨터이너를 만드는데 걸리는 시간은 겨우 1-2초로 가상머신과 비교도 할 수 없이 빠릅니다.

이러한 컨테이너라는 개념은 도커가 처음 만든 것이 아닙니다. 도커가 등장하기 이전에, 프로세스를 격리하는 방법으로 리눅스에서는 cgroups_{control groups}와 namespace를 이용한 LXC_{Linux container}가 있었고 FreeBSD에선 Jail, Solaris에서는 Solaris Zones이라는 기술이 있었습니다. 구글에서는 고급 기술자들이 직접 컨테이너 기술을 만들어 사용하였고 lmctfy(Let Me Contain That For You)라는 오픈소스 컨테이너 기술을 공개했지만 성공하진 못했습니다.

도커는 LXC를 기반으로 시작해서 0.9버전에서는 자체적인 libcontainer 기술을 사용하였고 추후 runC기술에 합쳐졌습니다.

이미지(Image)

Docker image

도커에서 가장 중요한 개념은 컨테이너와 함께 이미지라는 개념입니다.

이미지는 컨테이너 실행에 필요한 파일과 설정값등을 포함하고 있는 것으로 상태값을 가지지 않고 변하지 않습니다(Immutable). 컨테이너는 이미지를 실행한 상태라고 볼 수 있고 추가되거나 변하는 값은 컨테이너에 저장됩니다. 같은 이미지에서 여러개의 컨테이너를 생성할 수 있고 컨테이너의 상태가 바뀌거나 컨테이너가 삭제되더라도 이미지는 변하지 않고 그대로 남아있습니다.

ubuntu이미지는 ubuntu를 실행하기 위한 모든 파일을 가지고 있고 MySQL이미지는 debian을 기반으로 MySQL을 실행하는데 필요한 파일과 실행 명령어, 포트 정보등을 가지고 있습니다. 좀 더 복잡한 예로 Gitlab 이미지는 centos를 기반으로 ruby, go, database, redis, gitlab source, nginx등을 가지고 있습니다.

말그대로 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 더 이상 의존성 파일을 컴파일하고 이것저것 설치할 필요가 없습니다. 이제 새로운 서버가 추가되면 미리 만들어 놓은 이미지를 다운받고 컨테이너를 생성만 하면 됩니다. 한 서버에 여러개의 컨테이너를 실행할 수 있고, 수십, 수백, 수천대의 서버도 문제없습니다.

Docker Store

도커 이미지는 Docker hub에 등록하거나 Docker Registry 저장소를 직접 만들어 관리할 수 있습니다. 현재 공개된 도커 이미지는 50만개가 넘고 Docker hub의 이미지 다운로드 수는 80억회에 이릅니다. 누구나 쉽게 이미지를 만들고 배포할 수 있습니다.

왜 이렇게 핫한가?

도커는 완전히 새로운 기술이 아니며 이미 존재하는 기술을 잘 포장했다고 볼 수 있습니다.

컨테이너, 오버레이 네트워크_{overlay network}, 유니온 파일 시스템_{union file systems}등 이미 존재하는 기술을 도커처럼 잘 조합하고 사용하기 쉽게 만든 것은 없었고 사용자들이 원하는 기능을 간단하지만 획기적인 아이디어로 구현하였습니다.

레이어 저장방식

Docker Layer

도커 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 보통 용량이 수백메가_MB에 이릅니다. 처음 이미지를 다운받을 땐 크게 부담이 안되지만 기존 이미지에 파일 하나 추가했다고 수백메가를 다시 다운받는다면 매우 비효율적일 수 밖에 없습니다.

도커는 이런 문제를 해결하기 위해 레이어_layer라는 개념을 사용하고 유니온 파일 시스템을 이용하여 여러개의 레이어를 하나의 파일시스템으로 사용할 수 있게 해줍니다. 이미지는 여러개의 읽기 전용_{read only} 레이어로 구성되고 파일이 추가되거나 수정되면 새로운 레이어가 생성됩니다. ubuntu 이미지가 A + B + C의 집합이라면, ubuntu 이미지를 베이스로 만든 nginx 이미지는 A + B + C + nginx가 됩니다. webapp 이미지를 nginx 이미지 기반으로 만들었다면 예상대로 A + B + C + nginx + source 레이어로 구성됩니다. webapp 소스를 수정하면 A, B, C, nginx 레이어를 제외한 새로운 source(v2) 레이어만 다운받으면 되기 때문에 굉장히 효율적으로 이미지를 관리할 수 있습니다.

컨테이너를 생성할 때도 레이어 방식을 사용하는데 기존의 이미지 레이어 위에 읽기/쓰기_read-write 레이어를 추가합니다. 이미지 레이어를 그대로 사용하면서 컨테이너가 실행중에 생성하는 파일이나 변경된 내용은 읽기/쓰기 레이어에 저장되므로 여러개의 컨테이너를 생성해도 최소한의 용량만 사용합니다.

가상화의 특성상 이미지 용량이 크고 여러대의 서버에 배포하는걸 감안하면 단순하지만 엄청나게 영리한 설계입니다.

이미지 경로

Docker image url

이미지는 url 방식으로 관리하며 태그를 붙일 수 있습니다. ubuntu 14.04 이미지는 docker.io/library/ubuntu:14.04 또는 docker.io/library/ubuntu:trusty 이고 docker.io/library는 생략가능하여 ubuntu:14.04 로 사용할 수 있습니다. 이러한 방식은 이해하기 쉽고 편리하게 사용할 수 있으며 태그 기능을 잘 이용하면 테스트나 롤백도 쉽게 할 수 있습니다.

Dockerfile

이것은 굉장히 간단하지만 유용한 아이디어인데, 서버에 어떤 프로그램을 설치하려고 이것저것 의존성 패키지를 설치하고 설정파일을 만들었던 경험이 있다면 더 이상 그 과정을 블로깅 하거나 메모장에 적지 말고 Dockerfile로 관리하면 됩니다. 이 파일은 소스와 함께 버전 관리 되고 원한다면 누구나 이미지 생성과정을 보고 수정할 수 있습니다.

Docker Hub

Docker Hub Hits 5 Billion Pulls(2016/08)

도커 이미지의 용량은 보통 수백메가로 수기가가 넘는 경우도 흔합니다. 이렇게 큰 용량의 이미지를 서버에 저장하고 관리하는 것은 쉽지 않은데 도커는 Docker hub를 통해 공개 이미지를 무료로 관리해 줍니다.

Command와 API

도커 클라이언트의 커맨드 명령어는 정말 자아아알 만들어져 있습니다. 대부분의 명령어는 직관적이고 사용하기 쉬우며 컨테이너의 복잡한 시스템 구성을 이해하지 못하더라도 편하게 사용할 수 있습니다. 또한 http기반의 Rest API도 지원하여 확장성이 굉장히 좋고 훌륭한 3rd party 툴이 나오기 좋은 환경입니다.

유용한 새로운 기능들

도커는 발전속도가 아주 빠른 오픈소스입니다. 사용하면서 부족하다고 느꼈던 부분은 빠르게 개선되고 새로운 버전이 나오면 유용한 기능이 대폭 추가됩니다. 1.13버전에서는 Docker stacks이라는 여러개의 컨테이너를 한번에 관리하는 기능이 정식으로 릴리즈 되었고 system 커맨드가 추가되어 이미지, 컨테이너 관리가 더 편해졌습니다. Secrets Management라는 비밀정보를 관리하는 기능도 추가됩니다.

새로운 기능이 계속 추가되고 있고 다음 릴리즈가 기대됩니다.

훌륭한 생태계

도커는 굉장히 큰 생태계를 가지고 있고 커다란 기업과 협력하여 사실상 클라우드 컨테이너 세계의 de facto가 되었습니다. 로깅, 모니터링, 스토리지, 네트워크, 컨테이너 관리, 배포등 다양한 분야에서 다양한 툴들이 존재하며 아예 도커를 위한 OS(coreos-> container linux)도 존재합니다.

현재 도커를 기반으로한 오픈소스 프로젝트는 10만개가 넘고 굉장히 활발하게 진행되고 있습니다.

커뮤니티 지원

도커는 기술기업답지 않게 홍보와 커뮤니티 관리에 굉장히 신경쓰고 있습니다. 커뮤니티를 위한 스티커나 티셔츠를 무료로 제공하고 필요하면 연사요청도 할 수 있습니다. 홈페이지에서는 전세계에서 열리는 밋업 상황을 볼 수 있고 일주일마다 발송되는 뉴스레터에는 다양한 개발자들의 글이 실려있습니다.

moby dock

Tux(linux) - Moby Dock(docker) - Gopher (golang)

도커는 넘나 귀여운 고래를 로고로 하고 있습니다. 로고 스티커는 항상 인기가 넘치고 로고가 그려진 티셔츠는 입고 돌아다녀도 개발자처럼 보이지 않습니다. 도커가 성공한 가장 큰 이유는 귀여운 고래 덕분이라고 생각합니다.

정리

여기까지 도커에 대해 기본적인 내용을 아주 얕게 살펴보았습니다. 이제 실전으로 들어가봅시다!

이번 글에서는 우분투 이미지를 올린 container 에 web server 를 구축해 보도록 하겠습니다.

개인 데이터 저장 및 홈 미디어 서버로 사용하고 있는 시놀로지 716+2 NAS 에 도커 패키지를 설치 후 필요한 container 를 구축하였으며,
여기서는 이번 글에서 작업할 container 설정을 보도록 하겠다.

아래 그림에서 중요한 부분은 그림 왼편 하단의 포트 설정 부분을 잘 보시면 되실 것 입니다.

첫번째 설정은 SSH 접속을 위하여 외부 222 포트를 컨테이터의 22 포트로 포워딩하며 두번째 설정은

앞으로 우리가 설치할 webtob 접속을 위한 8081 포트를 8080포트로 포워딩 하는 설정을 보여주고 있습니다.

그리고 이 컨테이너에 할당된 이름은 ubuntu-web 이라는 것을 확인 할 수 있으며, 이것은 ssh 터미널 접속을 할 경우 hostname 으로 보여지게 됩니다.

webtob 설치를 위하여 container 로 ssh 터미널 접속을 해 보도록 하겠습니다.

위 그림의 첫 줄에 보면 192.168.0.117 서버(NAS)의 222 포트로 접속하고 있는 것을 확인 할 수 있습니다.

접속이 정상적으로 수행되면 root 계정으로 ubuntu-web 서버(container)에 접속 하였다는 것을 확인 할 수 있습니다.

그럼 이제 본격적으로 webtob 를 설치해 보도록 하겠습니다.

(아래 설치 과정은 이전 글에서 이미 webtob 설치 과정을 작성한 것을 재 활용 하였습니다.)

1. 설치 이미지 확인

2. WEBTOB4_1_SP9_Fix0_LinuxK2_6_ia64.bin 실행

3. License 정책 확인 (Y 입력)

4. Install Set 선택 (난 가상머신에 Jeus 연동까지 진행할 것이라 1번 WebtoB 만을 설치)

5. 설치 경로 입력

6. 설치 경로 입력 정보 확인

7. 설치 정보 및 디스크 여유 공간 확인

8. 설치 확인

9. 설치 완료

10. 환경 파일 컴파일    

webtob 설치 후 환경 파일 컴파일 시에 위와 같은 라이브러리를 찾을 수 없다는 메세

지가 나오면서 컴파일이 안 되는 경우가 있다.

아래 화면과 같이 .profile 에 환경변수 "LD_LIBRARY_PATH" 를 확인 하여야 한다.

설치하는 OS 에 따라 환경 변수 명이 조금씩 다르기 때문이다.

아래 화면은 우분투16.04에서 확인 한 내용이다.

11. 컴파일 성공

위 화면과 같이 컴파일을 성공하면 기본적인 webtob 설치및 환경은 구성이 되었다고

보아도 된다. 구성하고자 하는 내용에 따라 환경 파일을 작성하고 컴파일 후 webtob

를 기동하면 웹서버 기동이 되는 것이다.

아래 그림은 실제로 container 에 설치된 webtob 를 구동하는 것을 보여 줍니다.

이렇게 구동이 되었으면 이제 실제로 브라우저를 통해서 webtob webserver에 접속 해 보겠습니다.

짜잔!! 192.168.0.117:8081 로 접속한 화면 입니다.^^

오늘은 ubuntu 이미지를 올린 컨테이너에 web server(webtob)를 구축하는 것 까지 해 보았습니다.

다음 글에서는 또 하나의 ubuntu 이미지를 올린 컨테이너에 was server(jeus)를 구축하고 오늘 구축한 webtob와의 연결까지 해 보도록 하겠습니다.

이번 글에서는 우분투 이미지를 올린 Container 에 Oracle java6 환경을 구축해 보도록 하겠습니다.

기존 sun사의 java에서 oracle로 변경 되면서 java 설치 방법이 변경되었고, 기본 패키지로 설치가 불가능합니다. 기본 패키지로 설치시에는 open jdk 설치가 가능합니다. open-jdk를 설치할 경우 호환성의 문제가 간혹 발생하여 oracle의 java 설치를 가급적 권합니다.

java6의 설치와 주 버전 선택 방법까지 알아보겠습니다.