코어OS(CoreOS) - 서버 클러스터링을 위한 도커 전용 리눅스 배포판

CoreOS 시작하기

여기서는 coreos-vagrant를 사용한다고 가정한다. 먼저 CoreOS에 접속한다. (vagnant를 사용하지 않더라도 접속 후 과정은 같다)

$ git clone git@github.com:coreos/coreos-vagrant.git
$ cd coreos-vagrant
$ vagrant up
$ vagrant ssh core-01
Last login: Sat Aug  9 09:30:27 2014 from 10.0.2.2
CoreOS (alpha)
core@core-01 ~ $

도커(Docker)

먼저 Docker version을 확인해본다.

$ docker --version
Docker version 1.1.2, build d84a070

다음으로 Docker를 실행해본다.

$ docker run -i -t base echo 'Hello, World.'
Hello, World.

정상적으로 작동하고 있는 걸 알 수 있다.

Systemd(서비스)

이번엔 도커(Docker)를 이용해 서비스를 만들어본다. /etc/systemd/system/app.1.service 파일을 생성하고 아래와 같이 수정한다. CoreOS에는 기본적으로 vi 에디터만 사용이 가능하다. 다른 에디터를 사용하고자 할 때는 아래의 ToolBox 절을 참조한다.

[Unit]
Description=My Service 1
Requires=docker.service
After=docker.service

[Service]
ExecStart=/usr/bin/docker run --rm --name app1 busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop=/usr/bin/docker kill app1

서비스를 실행해본다

$ sudo systemctl start app.1.service

서비스가 정상적으로 작동중인지 status 명령어로 확인해본다.

$ sudo systemctl status app.1.service
● app.1.service - My Service 1
  Loaded: loaded (/etc/systemd/system/app.1.service; static)
  Active: active (running) since Sat 2014-08-09 11:14:03 UTC; 1min 12s ago
Main PID: 3503 (docker)
  CGroup: /system.slice/app.1.service
          └─3503 /usr/bin/docker run --rm --name app1 busybox /bin/sh -c while true; do echo Hello World; sleep 1; done

Aug 09 11:15:06 core-01 docker[3503]: Hello World
Aug 09 11:15:07 core-01 docker[3503]: Hello World
Aug 09 11:15:08 core-01 docker[3503]: Hello World

정상적으로 작동하고 있음을 알 수 있다. 도커를 통해서도 정상적으로 작동중인지 확인해본다.

$ docker ps -l
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS               NAMES
9b224aba3cbd        busybox:latest      /bin/sh -c 'while tr   4 minutes ago       Up 4 minutes                            app1 

app1이 정상적으로 작동중임을 알 수 있다. 서비스의 로그는 docker logsjournalctl를 통해서 확인할 수 있다. 여기서는 journalctl을 사용해본다.

$ journalctl -u app.1.service

이 때 -f 옵션을 사용하면 프로세스에 attach해서 로그를 계속해서 확인할 수 있다.

이제 서비스를 멈추고 상태를 확인해본다.

$ sudo systemctl stop app.1.service
$ sudo systemctl status app.1.service
● app.1.service - My Service 1
  Loaded: loaded (/etc/systemd/system/app.1.service; static)
  Active: failed (Result: exit-code) since Sat 2014-08-09 11:20:43 UTC; 2s ago
 Process: 3972 ExecStop=/usr/bin/docker kill app1 (code=exited, status=0/SUCCESS)
Main PID: 3503 (code=exited, status=255)

...
Aug 09 11:20:43 core-01 systemd[1]: Stopping My Service 1...
Aug 09 11:20:43 core-01 docker[3972]: app1
Aug 09 11:20:43 core-01 systemd[1]: app.1.service: main process exited, code=exited, status=255/n/a
Aug 09 11:20:43 core-01 systemd[1]: Stopped My Service 1.
Aug 09 11:20:43 core-01 systemd[1]: Unit app.1.service entered failed state.

정상적으로 서비스가 종료됐음을 알 수 있다.

Toolbox(CoreOS 시스템 보조 컨테이너)

위에서 언급했듯이 CoreOS에서는 기본적으로 vi 에디터만을 사용할 수 있다. 다른 에디터를 사용하고자 패키지 메니저로 에디터를 설치를 시도해본다면, 금방 CoreOS에 어떠한 패키지 관리자도 없다는 사실을 깨닫게 될 것이다.

이에 다른 에디터를 사용하고자 할 때는 Toolbox를 사용해야한다. Toolbox 실행하는 방법은 매우 간단하다. toolbox 명령어를 실행한다.

$ toolbox
unknown
Spawning container core-fedora-latest on /var/lib/toolbox/core-fedora-latest.
Press ^] three times within 1s to kill container.
[root@core-01 ~]#

툴박스는 페도라로 실행되는 호스트에 대한 특별 권한이 주어진 특수한 컨테이너라 할 수 있다. 위의 출력처럼 프롬프트가 달라진 것을 알 수 있다. 먼저 시스템을 확인해본다.

$ cat /etc/fedora-release
Fedora release 20 (Heisenbug)

페도라롤 실행되는 것을 확인할 수 있다. 여기서는 yum(패키지 관리자)를 사용해 시스템 패키지를 설치할 수 있다. 여기서는 nano를 설치해본다.

$ yum install nano

정상적으로 설치되었는 지 확인해본다.

$ nano --version
GNU nano version 2.3.2 (compiled 11:46:37, Aug  9 2013)
(C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
2008, 2009 Free Software Foundation, Inc.
Email: nano@nano-editor.org    Web: http://www.nano-editor.org/
Compiled options: --enable-color --enable-extra --enable-multibuffer --enable-nanorc --enable-utf8

이제 원하는 파일을 nano로 편집하면 된다. 참고로 호스트의 파일들에 대해서는 /media/root로 접근할 수 있다. 툴 박스를 종료하기 위해서는 ^]나 셸에서 빠져나가면 된다. Toolbox 안에서는 systemctl 등을 실행할 수 없으므로, 편집이 끝나면 밖으로 빠져나갈 필요가 있다.

CoreOS 클러스터링

CoreOS의 핵심은 도커 서버들을 쉽게 클러스터링하고, 이 위에서 돌아가는 서비스들을 유연하게 스케일 아웃할 수 있다는 점일 것이다. 이 절에서는 CoreOS를 클러스터링하는 방법에 대해서 다룬다. 여기서도 coreos-vagrant를 사용한다고 가정한다.

vagrant destroy

먼저 실행중인 coreos-vagrant가 있다면 destroy 명령어로 가상 머신을 삭제한다. 작업 디렉토리에서 아래 명령어를 실행한다.

$ vagrant destroy

설정 파일

config.rb

먼저 클러스터링을 위해서는 하나 이상의 CoreOS를 실행할 필요가 있다. 이를 위해서 config.rb을 수정해야 한다. 먼저 샘플 파일을 config.rb로 이름을 변경한다.

$ cp config.rb.sample config.rb

config.rb에서 다음으로 아래 부분을 수정해준다.

$num_instances=3

여기서는 가상 머신의 개수를 3대로 지정하였는데, 이 숫자는 1대만 아니면(클러스터링을 해야하므로) 원하는 만큼 지정하면 된다.

user-data

다음으로 user-data의 etcd 서버 설정을 수정해야한다. etcd는 CoreOS에서 서비스 디스커버리 역할을 하는 데몬에 해당한다. 먼저, 샘플 파일을 user-data로 복사한다.

$ cp user-data.sample user-data

다음으로 etcd 서버가 필요하다. etcd 서버를 직접 실행할 수도 있지만 아래 주소에 접속하면 coreos에서 제공해주는 etcd 서버를 발급 받을 수 있다.

위 주소에 접속하면 http://discovery.edcd.io/<TOKEN> 형태로 된 주소가 보일 것이다. 이를 복사해서 user-data의 아래 부분에 덮어씌워준다.

discovery: <ETCD 서버 주소>

이로써 CoreOS 클러스터를 실행할 준비는 끝이 났다. 이제 vagrant를 실행해준다.

$ vagrant up

status 명령어로 정상적으로 실행되었는지 확인한다.

vagrant status
Current machine states:

core-01                   running (virtualbox)
core-02                   running (virtualbox)
core-03                   running (virtualbox)

클러스터링 확인하기

가상 머신에 접속해 fleetctl로 클러스터링 상태를 확인할 수 있다. 먼저 가상 머신에 접속한다.

$ vagrant ssh core-01

접속이 되면 fleetctl 명령어로 다른 서버들과 클러스터링이 되었는 지 확인한다.

$ fleetctl list-machines -l
MACHINE                                 IP              METADATA
35cf7e5deccb450c8f2831bdd20a859f        172.17.8.101    -
489bc9c3349c42e0925b2885108add01        172.17.8.103    -
89403ce1cf574e42a47f804a4d2f6a3c        172.17.8.102    -

클러스터링된 것을 확인할 수 있다. 다음으로 core-02와 core-03에 들어가서도 확인해본다.

$ vagrant ssh core-02
$ fleetctl list-machines -l
MACHINE                                 IP              METADATA
35cf7e5deccb450c8f2831bdd20a859f        172.17.8.101    -
489bc9c3349c42e0925b2885108add01        172.17.8.103    -
89403ce1cf574e42a47f804a4d2f6a3c        172.17.8.102    -
$ vagrant ssh core-03
$ fleetctl list-machines -l
MACHINE                                 IP              METADATA
35cf7e5deccb450c8f2831bdd20a859f        172.17.8.101    -
489bc9c3349c42e0925b2885108add01        172.17.8.103    -
89403ce1cf574e42a47f804a4d2f6a3c        172.17.8.102    -

위와 같이 나오면 정상적으로 클러스터링 된 것이다.

etcd

fleet

참조

내부 페이지

외부 사이트


Who am I?