4 posts tagged with "juju"

MAAS 구축하기를 통해 만들어진 node 들을 사용자들이 acquire 해서 각자의 용도에 맞게 사용할 수도 있지만 juju를 이용하면 자동 배포 및 관리도 가능하다. MAAS를 사용하게 된 이유 중 하나가 ceph을 더 살펴보기 위해서인데 (Juju로 Ceph을 deploy 해보자 참조) 어찌보면 배보다 배꼽이 더 큰 경우일 수도 있겠지만 어디까지나 재미로 혹은 공부한다 생각하니 효율적이지 못해도 괜찮다고 본다.

1. Prerequisites​

Juju를 먼저 설치해야 한다. (getting-started 문서 참조) 나의 경우엔 예전에 설치해 둔 상태라 1.25.3 버전이 설치되어 있는데 현재 최신 버전은 2.0이고 각 버전별로 기능 차이가 있으니(버그도...) 주의가 필요하다. MAAS에 접속해서 사전에 MAAS key를 복사해 두어야 한다.

MAAS에 로그인 후 계정 이름을 클릭해서 Account 메뉴를 선택하면 위 그림과 같은 화면이 표시되는데 기본으로 생성되어 있는 MAAS key를 복사해둔다. 없으면 생성. 또, 이미 MAAS 구축할 때 ssh key 등록을 해놨지만 안해두었다면 본인이 사용하는 host의 ssh public key를 등록해둔다.

2. environments.yaml 파일 수정​

Juju를 설치하면 ~/.juju 경로가 몇개의 파일과 함께 자동 생성된다. 만약 없다면 juju init 명령을 실행하면 생성된다. Juju는 yaml로 각 환경에 대한 설정을 사전에 정의해서 사용하기 때문에 ~/.juju/environments.yaml 파일을 수정해야 한다. 아래 그림처럼 maas 항목을 찾아서 세부 설정을 해주면 된다.

필수 설정 항목을 정리하면 아래와 같다.

maas-server : MAAS 접근 url

maas-oauth : 과정 1에서 미리 복사해 둔 maas-key를 입력

admin-secret : 문서에 의하면 random pass-phrase라고 하는데 어디에 사용되는지는 모르겠지만 없으면 bootstrap이 진행되지 않으니 임의의 값을 입력해준다.

위의 3개 값은 필수이니 설정하고 저장하면 완료.

3. Bootstrap with no-auto-upgrade option​

(1) Switch environment

environments.yaml 파일을 대충 봤으면 알겠지만 여러가지 환경에 대한 설정을 한 파일에 모두 정의하도록 되어있는데 상황에 따라 선택적으로 환경을 지정할 수 있게 되어있다. 현재 juju가 사용하는 환경으로 지정된 것은 ~/.juju/current-environment 파일에 저장된다. 만약 maas가 기본으로 지정되어 있지 않다면 아래의 command를 실행해야 한다. (environments.yaml 파일에 maas라는 이름을 변경하지 않은 경우. 만약 변경했다면 변경된 이름으로 switch)

[bash]

juju switch maas

[/bash]

(2) Ready node

Juju가 MAAS 대상으로 bootstrap 가능한 node는 ready 상태의 node이다. 당연하겠지만 다른 사용자의 소유로 되어있거나 (allocated) OS가 deploy된 상태인 node에는 이미 다른 용도로 사용중이거나 예정인 것이므로 juju가 관여하지 않고 ready로 남아있는 node 중에 하나를 무작위로 골라서 bootstrap을 하게 되므로 주의해야 한다.

(3) Bootstrap

이제 bootstrap만 하면 되는데 juju 1.25.3에서 진행해보니 거의 마지막 과정에서 Waiting for API to become available이 여러번 반복되며 부분적으로만 bootstrap이 성공한 것으로 완료되는 문제가 있어서 bug report를 찾아봤다. 문서 내용에 의하면 newer version이 필요한 상태로 client에 기록되고 그 정보가 bootstrap machine (juju state server가 될 장비)에 넘어가서 bootstrap machine에서 newer version과의 연결을 계속 시도하는 것 같다. 개선될 bug로 보이는데 어찌되었든 1.25.3에서 그런 문제를 방지하려면 아래처럼 no-auto-upgrade option을 추가해준다. (v option은 verbose.혹시 더 많은 로그를 보고 싶으면 v 대신 debug 옵션을 주면 되겠다.)

[bash]

juju bootstrap -v --no-auto-upgrade

[/bash]

아래 그림과 비슷한 내용이 표시되고 완료된다.

bootstrap이 정상으로 완료되고 juju status 명령을 입력해보면 아래 그림처럼 현재 상태가 표시되고,

혹시 ssh로 접속하고 싶다면 아래의 command를 입력하면 간단히 접속된다.

[bash]

# connect to juju machine number '0'

juju ssh 0

[/bash]

Ceph의 manual deploy를 진행해봤으나 앞서 "Ceph을 설치해보자"에서 기술한 것처럼 ceph-deploy를 사용하는 방법만큼 공식 문서에 문제가 있어서 포기하고 juju로 해보기로 했다.

1. 준비​

(1) Bootstrap

Juju로 deploy 하기 위해서는 사전에 bootstrap이 진행되어 있어야 한다. Juju version 1.25 기준 인프라로 AWS, Azure, VMWare, GCE, Joyent, Manual 등을 지원하는데 Azure에서 해보기로 했다. Bootstrap을 완료하고 status를 확인하면 아래 그림처럼 status server가 하나 보인다.

(2) yaml 준비

Ceph charm 문서를 보면 배포하기 전에 설정파일 안에 fsid와 monitor-secret 값을 필수로 넣으라고 명시되어 있다.

<출처 : https://jujucharms.com/ceph/xenial/3>

fsid는 uuid나 uuidgen을 실행하면(없으면 설치) 생성 가능하고 monitor-secret 값은 아래의 명령으로 생성할 수 있는데 cluster 공통으로 사용할 것이라 배포될 ceph node 안에서 생성되는게 맞을 것 같지만 배포 전이므로 임의의 장비에서 생성해봤다. (결론은 문제는 없는데 ceph-common가 설치되어 있어야 monitor-secret 값 생성이 가능해서 좀 이해가 안되는 부분)

# generate monitor-secret
ceph-authtool /dev/stdout --name=mon. --gen-key

Charm 문서에는 osd-devices 라는 항목에 대해서도 기술되어 있는데 굳이 설정파일에 넣을 필요는 없고 나중에 juju set 명령으로 설정하는게 가능하다. osd-devices는 실제 osd가 사용할 경로로 mount 된 disk 이거나 일반 directory를 지정하면 되는데 존재하지 않는 경로라면 생성 후 권한 설정까지 알아서 진행된다. 나중에 설정할거라면 배포 후에 아래의 명령을 사용한다.

juju set ceph osd-devices=path_for_osd

2. Ceph 배포​

Ceph 배포는 간단하게 아래 명령으로 완료된다. 1-(2)에서 ceph.yaml 이란 이름으로 파일을 생성해서 그 파일을 설정파일로 지정했고 3개 instance에 배포하라고 해놨다. 배포를 시작하면 instance를 추가해서 ceph 설정까지 알아서 진행되고 완료되면 서비스가 active 상태로 변경된다.

juju deploy -n 3 --config ceph.yaml ceph

배포는 되었어도 아직은 ceph이 외부와 연결된게 없으므로 3개 중 하나의 instance에 접속해서 sudo ceph -w (ceph-deploy를 사용할 때와는 다르게 root 권한이 필요) 를 실행해보면 아래 그림처럼 상태를 확인할 수 있고 sudo ceph osd tree 명령으로 osd가 모두 정상인 것도 확인 가능하다.

설정했던 osd-devices가 어떻게 되어있는지 확인해보니 위에서 언급했던 것처럼 경로 생성부터 권한 설정까지 모두 완전하게 처리되어 있었다.

3. OSD 확장​

실제 ceph을 활용할 때 확장할 가능성이 높기 때문에 확장이 잘 되는지 살펴보기로 했다. 역시 간편하게 아래의 두가지 명령만 실행하면 확장은 끝난다. 단, 사전에 ceph-osd charm이 사용할 설정 파일을 만들어줘야 하는데 이미 존재하는 ceph cluster에 붙일 것이기 때문에 fsid 등이 필요하지는 않고 osd가 사용할 osd-devices 만 지정해주면 된다. 2에서 cluster 구성을 할 때에는 osd-devices로 /ceph-disk 라는 경로를 설정했는데 확장시 어떻게 되는지 살펴보기 위해 이번에는 /added-disk라고 설정했다.

<출처 : https://jujucharms.com/ceph-osd/xenial/3>

# deploy ceph-osd to two instances
juju deploy -n 2 --config osd.yaml ceph-osd

# add relation
juju add-relation ceph-osd ceph

ceph-osd deploy가 완료된 후에 최초 cluster가 구성된 node 중 하나에 접속해서 상태를 보면 아래의 그림처럼 모두 5개의 osd가 올라와있음을 확인할 수 있고 사용 가능한 storage 용량도 증가되었음을 알 수 있다. (약 76GB => 124GB)

마지막으로 확장된 osd에만 다르게 적용했던 osd-devices 경로는 어떻게 되어있는지 확인해보니 이전에 구성된 cluster에는 변화가 없고 추가된 osd만 지정한 경로(/added-disk)를 사용함을 알 수 있었다.

4. 결론​

ceph-deploy를 사용하면서 경험했던 문제들은 charm을 만든 사람이 개선했는지 전혀 나타나지 않았고 너무 간편하게 배포할 수 있었다. 아마 이미 존재하는 instance에 배포할 때를 위해 준비해둔 것이 아닌가 싶은데, 초기에 cluster 구성하면서 설정했던 fsid, monitor-secret은 별도 지정하지 않는 이상 charm 내부에서 생성해서 설정하도록 되어 있으면 더 좋았을 것 같다. 이제 deploy는 가볍게 해결할 수 있으니 실제 활용 측면에서 어떤지 살펴볼 생각이다.

5. 참고​

(1) Ceph charm

(2) Ceph osd charm

(3) Juju commands

1주에 한번씩 스터디 중이고 이번주는 hadoop을 deploy 해서 가야 한다.

Hadoop에 대해서는 잘 모른다. 하지만 배우면 되겠지라고 생각하면서 시작.

1. Juju charm​

Charm을 찾아보니 간단하게 기술되어 있다.

(Charm 자체는 간단하겠지만 hadoop에 대한 내용은 어려울 것이다.)

기술된 내용을 읽다보니 HDFS와 MapReduce가 혼합된 형태로 deploy 하는 부분이 있다.

Scale out을 위해 분리된 형태로 deploy 하는 내용도 있었지만 일단은 가볍게 시작하기로 하고 순식간에 deploy / relation 완료.

2. Web UI​

Apache Hadoop 페이지를 대강이라도 읽어두어야겠다는 생각이 들어서 살펴보니 Hadoop cluster를 올리고나면 web ui가 있으니 확인해보라는 내용이 있었다. Name node는 default 50070, Resource manager라는 애는 default port가 8088이다. 그런데...위의 이미지처럼 간단하게 deploy를 해보니 Azure (연습용이라 Azure를 사용한다)에 생성된 VM에 Endpoint 설정이 SSH 말고는 되어있질 않았다. 역시 이런 부분은 문제가 있다고 생각하며 넘어가기로 했다.

3. Listening port 확인​

설마 혹시 제대로 deploy가 안된 것은 아닌가 다른 문제가 있는 것은 아닌가 의심하기 시작. 하지만 로그를 봤을 때 특이사항이 없었으므로 Apache 문서가 맞다면, 또 deploy가 제대로 되었다면 port는 listen 상태로 있겠지라는 생각이 들었다. 그래서 netstat.

Hadoop의 구조는 잘 모르지만 master, slave로 나뉘어 있는 것으로 보아 master만 보면 되겠다며 port를 확인하니 Apache 문서대로 8088, 50070 등의 port로 들을 준비를 하고 있더라. 그렇다면 문제는 하나.

4. Expose​

Charm 문서에는 기술되어 있지 않지만 Azure endpoint 설정이 안되어 있으므로 expose를 해보기로 했다. (직접 VM에서 열어도 되지만...) 해보니 자동으로 몇 개 설정이 추가된다.

그런데 왠지 중요해보이는 resource manager가 사용할거라던 8088은 추가되지 않았다.

그래서 손으로 추가.

5. Hadoop Resource Manager​

접속해보니 잘 열린다. hadoop-slavecluster를 deploy 한 후 unit을 2개 더 추가했기 때문에 총 3개가 active node로 잡힌다.

근데 이것으로 무엇을 해야하는건지는 모르겠다.

6. 결론​

Juju로 hadoop cluster 구성하는건 매우 간단하다.

하지만 Azure로 진행하는건 여전히 몇가지 문제가 있다.

Azure의 특성 때문이기도 하지만 charm을 만들 때 고려해야할 문제이기도 한 것 같다.

Ubuntu를 배포하고 있는 Canonical에서 사용자가 cloud 환경에서 쉽게 서비스를 모델링하고 배포하기 위한 tool을 Juju라는 이름으로 내놓았다. Server instance를 간편하게 관리한다는 측면에서는 Chef와 유사하지만 instance 자체를 생성하거나 제거할 수 있기 때문에 또 다른 것 같다. Juju는 instance가 아닌 service 위주의 관리와 배포를 목적으로 하고 있는 것으로 보인다. 실제로 특정 서비스 (charm이라고 부르는)를 deploy하면 신규 instance를 추가해서 charm에 정의된 내용대로 서비스를 배포하게 된다. (option에 따라 이미 추가된 instance에 배포하는 것도 가능)

참고 : 아래의 모든 터미널 이미지에 표시된 dns name과 instance-id 들은 이미 다 destroy 해서 사용할 수 없는 정보들임

1. Juju의 구조​

<출처 : http://www.slideshare.net/LeonardoBorda/leonardo-borda-maas-and-juju-introduction\>

Juju는 위 그림처럼 client가 state server에 상태값을 추가하거나 update 하도록 되어있고 하위의 모든 machine 들은 state의 변경에 따라 특정 동작을 처리하도록 되어있는 것으로 보인다. 예를 들어 wordpress와 mysql을 연결하라는 명령을 client에서 보내면 내부적으로 event가 발생되고 wordpress, mysql이 event에 맞는 hook을 실행해 세부적인 동작을 처리하게 되며 그 과정에서의 상태값들은 모두 state server에 저장되거나 변경된다. (State는 Mongo DB로 관리되는 것으로 보임)

2. Bootstrap​

Juju client 설치 후 내가 사용하는 cloud 환경 (AWS, MS Azure, Openstack, Joyent, GCE, VMWare 등 대부분의 환경을 지원한다)에 대한 설정을 마친 후에 bootstrap 명령을 내리면 bootstrap instance를 생성하고 필요한 tool들의 설치, 설정까지 진행한다. Bootstrap instance는 state server로서 동작하게 된다.

Azure의 경우 vnet 생성 후에 instance를 생성해서 연결하게 되고 hash가 포함된 것으로 보이는 문자열로 DNS name을 설정하는 걸 확인할 수 있다. 사실 Juju로 관리할 경우 DNS name은 크게 중요한 요소는 아닌데 아래의 그림처럼 state server에서 별도로 일련번호(0)나 unit name을 붙이고 있어서 client에서는 DNS name이 아니라 일련번호나 unit name으로 대부분의 관리가 가능하다.

3. Charm​

Juju에서 배포하고자 하는 service들은 charm이라는 이름으로 정의되고 관리된다. (Chef에서 cookbook이나 recipe처럼) Charm의 구성요소는 아래와 같다.

(1) Metadata

(2) Hooks

(3) Custom contents

Metadata는 name, description, relation, configuration option 등으로 구성이 되는데 이 중 중요한 것은 relation이다.

예를 들어, Wordpress charm의 metadata는 위의 그림처럼 정의되어 있는데 requires와 provides, peers로 된 부분이 relation 설정이다. Relation은 interface, kind, name으로 구성되어 있는데 각각의 정의는 이렇다.

Interface : Hook을 통해서 정보를 교환하기 위한 protocol (진짜 interface의 의미도 있지만...)

Kind : Relation의 종류로 requirer, provder, peer 중 하나를 의미하는데 requirer는 이런 relation이 필요해, provider는 이런 relation을 내가 해줄게, peer는 클러스터링 할 때는 이런 걸로 하자로 이해하면 편할 것 같다.

Name : identifier로서의 역할이고 위 wordpress metadata에서 보면 name 항목의 wordpress,  requires: db: interface: mysql 항목의 mysql을 모두 name이라고 생각하면 된다.

Hook은 위에서도 언급했듯이 event가 발생했을 때 실행되는 script로 어떤 언어로 된 script도 관계없다고 명시되어 있다. 그러니까 특정 event 발생시 각 service unit들이 해줘야 하는 동작을 script로 정의하면 되는데 몇 개 charm을 둘러보니 대부분 bash와 python으로 구현하는 것으로 보인다.

4. Deploy​

Bootstrap 한 이후에 위의 charm을 가지고 deploy하는 과정은 단순히 juju deploy <charm name> 형태의 command만 실행하면 된다. 정말 간단하다. 실행하면 charm이 올라갈 instance를 생성하고 instance 생성이 완료되면 charm에 정의된 install hook이 실행되서 필요한 tool을 설치하거나 설정하게 된다. 그리고 deploy 후에 state server (bootstrap instance)에 상태 정보를 요청하면 아래와 같은 내용을 확인할 수 있다.

5. Instance에 접속하고 싶다면​

대부분의 관리가 juju command로 가능하지만 그래도 배포된 instance에 접속해야하는 상황이 있을 수 있다. 그 경우 juju ssh 0 (0번은 bootstrap instance에 대해서 붙여진 번호), juju ssh <unit_name> 형태의 command를 사용하면 ssh로 접속이 가능하다. 실제로 bootstrap instance나 다른 instance를 생성할 때 juju client에서 관리하는 public key를 전송해서 각 instance (machine)의 authorized_keys에 추가하기 때문에 juju command가 싫다면

ssh -i <private_key_path> ubuntu@<dns_name>

으로 접속할 수 있다. (Juju client가 설치된 장비의 private key는 기본적으로 ~/.juju/ssh 경로에 생성됨)

6. Add relation​

4에서처럼 charm을 deploy 하고나면 단지 설치만 된다. Wordpress charm의 경우 설치했을 때 wordpress만 설치되고 mysql 등의 DB는 별도로 설치되지 않는다. MySQL이 필요하니 deploy를 한다해도 역시 설치만 되고 각 service는 별개의 것으로 남아있게 된다. juju add-relation wordpress mysql 명령을 실행해보자. (wordpress, mysql은 charm의 이름이지만 이미 설치된 것이고 state server에서 각 service unit에 대한 상태를 관리하고 있으니 문제없다)

위 그림은 순서대로 mysql과 wordpress가 설치된 instance에서 수집한 로그인데 add-relation 명령 실행시 mysql에서는 db-relation-joined, wordpress에서는 db-relation-changed가 순차적으로 실행되는 것을 확인할 수 있다. db-relation-joined와 db-relation-changed는 각각 mysql과 wordpress charm에 정의되어 있는 hook으로 add-relation 명령이 수행되면 wordpress와 mysql이 provide하고 require하고 있는 항목인 db에 대한 relation-joined hook이 실행되는데 db-relation-joined hook은 mysql에만 정의되어 있으므로 먼저 실행된다.

db-relation-joined hook의 내용을 살펴보면 위 그림처럼 relation-set 명령을 호출해서 db 접속정보를 설정하는 것을 알 수 있다. 위의 접속정보는 state server에 저장되고나면 변경사항이 발생되었기 때문에 db-relation-changed hook이 실행되는데 이것은 wordpress에만 정의되어 있는 hook이므로 wordpress에서만 실행되며 state server에 저장된 db 접속정보를 받아와서 설치된 wordpress에 설정파일들을 수정하거나 다른 조작을 가하도록 정의되어 있어 wordpress와 mysql 사이의 연결이 가능해진다.

7. Expose​

Deploy와 relation의 과정을 거치고 나더라도 바로 wordpress를 이용할 수는 없다. Cloud service 들의 특성상 보안 등의 이유로 대부분의 port는 연결이 되지 않도록 막혀있기 때문에 특정 port를 열어주는 작업이 필요하다. 위의 과정으로 deploy 한 것은 wordpress와 mysql 뿐이고 wordpress만 열면 되기 때문에 간단하게

juju expose wordpress

명령만 실행하고 나면 약간의 시간 후에 아래의 그림처럼 endpoint 설정이 추가된 것을 확인할 수 있다. (Azure 기준)

Wordpress나 MySQL charm에서 어떤 부분이 expose를 가능하게 하는지 아직 찾지 못했다. MySQL을 expose 해보니 status에서 exposed flag 값만 false에서 true로 바뀔 뿐 실제 endpoint 설정이 추가되지는 않는데 이 부분은 좀 더 살펴볼 필요가 있을 것 같다.

8. 참고​

https://jujucharms.com/docs/stable/getting-started

http://blog.labix.org/2013/06/25/the-heart-of-juju

http://askubuntu.com/questions/55179/what-is-the-purpose-of-the-bootstrapping-instance-in-juju

http://www.slideshare.net/LeonardoBorda/leonardo-borda-maas-and-juju-introduction