MAAS는 Metal As A Service의 약자로 물리적인 서버들을 관리하기 위한 용도로 사용된다. OS가 설치되지 않은 베어메탈 장비들을 단순히 같은 네트웍 대역에 두는 것만으로 등록부터 프로비저닝까지 손쉬운 관리가 가능하다.

1. MAAS가 왜 필요했나?​

결론적으로는 자동화 때문에 MAAS가 필요했는데 juju를 사용하기 위함이었다. 과거에는 클라우드 서비스를 사용하고 있었기 때문에 사용하던 클라우드 인프라 위에서 어렵지 않게 juju state machine을 만들고 사용하는게 가능했는데, 몇가지 이유때문에 클라우드 이용에 제약이 생기고 동시에 집 안에 장비를 들이면서 MAAS 위에서 자동화하는게 낫겠다 생각했다. 또, 가상화 환경에서 VM 생성 후에 OS 설치 등의 과정을 거치는게 좀 귀찮았는데 MAAS 컨셉과는 조금 다르더라도 VM을 MAAS에 등록하고 사용하면 좀 덜 귀찮아질 것 같았다.

2. MAAS network​

MAAS 구축 전에 준비할 것들이 몇가지 있는데 그 중에 가장 중요한 것은 MAAS cluster network 분리이다. MAAS가 사용할 네트웍을 분리하지 않더라도 구축과 사용에 문제가 발생하는 것은 아니지만 MAAS에 등록하게 될 network interface와 동일한 네트웍 대역에서 생성되는 VM은 PXE로 부팅되면서 자동으로 MAAS에 등록하는 과정을 거치게 되기 때문에 의도와는 다르게 진행될 수 있다.

아래 그림처럼 나의 경우에는 공유기에서 관리하는 192.168.10.0/24 대역이외에 가상 스위치를 하나 더 생성했고 vyos를 써서 가상 스위치에 연결될 네트웍을 NAT 되게 함으로써 vyos가 관리할 192.168.100.0/24 네트웍 대역을 하나 더 만들고 192.168.10.0/24와는 분리시켰다. (vyos를 이용한 네트웍 설정은 다른 글에서 다룰 예정 VyOS를 이용한 NAT network 구성 참조)

MAAS는 기존 공유기에서 관리되는 네트웍 대역을 통해 접근할거라 network interface를 2개 (eth0, eth1)를 만들어서 양쪽에 연결했고 MAAS에서 eth1에 대해 설정할 것이라 eth1이 연결된 네트웍 대역 192.168.100.0/24에 붙는 VM들은 모두 MAAS에 등록될 것이다. 이렇게 되면 192.168.10.0/24에 어떤 VM이나 서버가 붙는다고 해도 MAAS가 관여하는 일은 없을 것이다.

3. Install MAAS​

MAAS 설치는 상당히 간단한데 아직 불안정한 요소들은 있는 것 같다. Ubuntu 14.04 버전에서 진행했을 때 아래의 command로 기본 설치는 완료된다.

sudo add-apt-repository ppa:maas/stable
sudo apt-get update
sudo apt-get install -y maas

설치 과정에서 bind9도 설치하고 로딩하게 되는 것 같은데 처음엔 실패하지만 다른 작업을 거치고 나중엔 정상적으로 처리되는 것으로 보인다. 설치 이후에는 관리자 계정을 만들어주어야 한다. 관리자 계정 생성 명령은 버전별로 약간 다른 것 같은데 Ubuntu 14.04에서 설치한 경우라면 아래의 command가 유효하다.

sudo maas-region-admin createadmin

관리자 계정 생성까지 완료되면 브라우저에서 web ui에 접근해 생성한 계정 정보로 로그인해서 나머지 과정을 진행하면 되는데 만약 연결할 VM이 VMware의 가상화 솔루션 ESXi 위에서 만들어진 것이라면 나중에 문제가 생길 수 있으니 하나의 python package를 추가로 설치해주어야 한다. 설치하지 않으면 node 등록시 아래와 같은 오류가 발생하는데 web ui에서는 특별한 반응이 없으므로 문제를 인지하기 어려울 수 있다.

아래의 명령으로 python-pyvmomi까지 설치하고 나면 이제 web ui에서 설정하는 일만 남았다.

sudo apt-get install python-pyvmomi

브라우저에서 http://{maas_host}:5240/MAAS 로 접속.

4. Node 추가 전에 설정할 것들​

(1) Import images

Images 메뉴로 가서 import 할 image를 선택해서 import를 해야 한다. 이 image들은 MAAS에 연결될 VM이나 베어메탈에 실제 설치될 OS들이다. 상황에 따라서 몇 분에서 몇 시간이 걸릴 수도 있는데 import 시작만 해두는 것으로도 일부 작업은 가능하지만 결국은 import가 완료되어야 원하는 모든 작업을 처리할 수 있다.

만약 image import가 완료되지 않은 상태에서 VM 생성 후 등록을 위해 부팅해보면 아래 그림처럼 PXE 부팅 과정에서 OS image를 가져오지 못해서 MAAS에 등록이 안되기 때문에 결국 image import 과정이 완료될 때 까지 기다려야 한다.

(2) Network interface 설정

Clusters > Cluster master > Interfaces 메뉴로 진입해서 MAAS에 연결될 VM들이 사용할 interface 설정을 해야한다. 나의 경우엔 eht1을 MAAS cluster network으로 사용할거라 eth1을 수정했다. Network interfaces 설정은 크게 네 가지로 나눌 수 있는데 Management 항목에서 DHCP / DHCP and DNS을 선택해야 하고, gateway / subnet mask 등의 일반적인 네트웍 설정, dynamic ip range, static ip range 설정이다. 이 중 dynamic ip와 static ip는 range가 겹치면 안되는데 dynamic ip는 MAAS에서 commission 까지의 과정에서 사용하는 ip로 보이고 사용자에게 allocate 되고 사용자가 원하는 OS가 deploy 될 때 static ip를 사용하는 것 같다. Network interface 설정이 완료되면 아래 그림처럼 설정한 eht1이 DHCP로 MAAS에 의해 관리되는 상태로 변경된다.

5. MAAS node lifecycle​

단순히 VM (node)이 등록되면 자동으로 프로비저닝이 되어서 여러가지 제어가 가능할 것으로 생각했는데 MAAS에서는 단계별로 node의 상태를 분류하고 있고 상태마다 제어 가능한 기능들이 다르기 때문에 lifecycle을 알고 넘어갈 필요가 있다.

<그림 : http://maas.io/how-it-works>

(1) New

MAAS가 관리하는 네트웍에 VM을 생성하고 부팅을 하면 PXE로 부팅이 되면서 MAAS에 등록이 되면 VM은 자동으로 종료된다. MAAS에 등록되면 MAAS node list에 VM이 표시되고 상태는 New가 된다. 이 상태에서 VM의 리소스 (CPU, RAM, ...) 정보는 제대로 표시되지 않는다.

(2) Commission => Ready

등록된 node를 commission 하게 되면 VM의 정보들을 수집해서 제어할 준비를 마치게 된다. Commission이 완료되면 node 상태는 Ready로 변경되며 가지고 있는 리소스 정보도 제대로 표시된다.

(3) Acquire => Allocated

Acquire는 사용자에게 node의 권한을 넘기는 과정으로 이 과정을 거치면 특정 사용자에게 allocated된 상태로 변경이 되며 사용자가 제어할 수 있는 권한을 갖게 된다.

(4) Deployed

권한을 가진 사용자가 deploy를 하면 deploy할 OS를 선택하게 되는데 OS 선택까지 마치게 되면 선택한 OS가 node에 자동으로 배포된다. 배포가 완료되면 Deployed 상태로 변경된다.

(5) Released

Release는 사용자가 node에 대한 사용권한을 반납하는 과정으로 release 이후에는 다시 처음의 ready 상태로 변경된다.

6. Add hardware​

MAAS에서의 lifecycle을 살펴봤으니 실제 node를 추가해야 한다. Node를 추가하는 방법은 크게 세가지로 볼 수 있다.

(1) Add chassis

VM이나 베어메탈 장비들이 배치되어 있는 chassis를 통째로 등록하는 방법으로 같은 유형의 장비들을 일괄 등록하는게 가능하다. 이 경우 이미 VM들은 생성된 상태여야 node list에 표시된다. 나의 경우엔 VMware 가상화 환경을 이용하고 있어서 아래의 그림처럼 적당한 정보를 입력했는데 prefix filter는 VM이나 장비의 이름을 거르기 위한 filter이므로 MAAS로 관리할 VM들의 이름을 보고 입력해둔다. 아예 공란으로 두면 모든 VM이 등록되므로 그 이후에 필요없는 것들을 node list에서 제거하는 것도 가능하다.

(2) Add machine

Add machine은 chassis 등록 과정과 거의 유사한데 machine 하나를 개별적으로 등록할 때 사용한다고 보면 될 것 같다.

(3) PXE boot / Power 설정

(1), (2) 과정을 거치지 않고 MAAS가 설치된 이후 MAAS cluster network에 VM을 생성해서 부팅을 하면 자동으로 PXE boot이 되며 MAAS에 등록이 된다. 이 경우에는 VM의 이름이 node list에 표시되지 않고 MAAS가 임의로 붙인 이름으로 표시되는데 (아래 그림에서 alarming-waste.mass), node 이름을 클릭해서 상세 정보를 보면 power 정보가 비어있는 것을 볼 수 있다. Power on / off를 제어해야 하기 때문에 power 정보를 입력해줘야 사용이 가능하다. 여기에서 power 정보라는 것은 어차피 API로 제어하는 것이기 때문에 chassis 추가할 때와 같은 정보를 입력해주면 된다.

7. Take actions​

위의 과정까지 다 마치면 node가 등록만 되었기 때문에 new 상태로 표시된다. Lifecycle 부분에 기술한대로 node의 리소스 정보는 제대로 표시되지 않는 상태. Node를 선택하면 수행할 수 있는 작업들이 Take action이라는 메뉴에 표시되고 대표적인 기능에 대한 내용은 아래와 같다.

(1) Commission

Commission은 등록된 node를 사용할 준비를 하는 것이므로 new 상태인 node가 필수적으로 수행해야 하는 과정이다. Commission 과정에서 node를 자동으로 부팅하게 되고 commission 실행시 옵션 선택에 따라 작업 완료 후 node의 전원을 끄거나 그대로 유지한다. Commission 과정을 거치고 나면 node의 power on / off도 가능한 것처럼 메뉴에 표시되지만 실제로 power on은 불가능했다. VMware와의 연동 문제일 수도 있을 것 같은데 commission 수행시에 VM 부팅로그를 보면 아래 그림처럼 IMPI 관련 기능에 오류가 발생함을 알 수 있다. (IMPI는 power on / off를 위해 필요한 인터페이스. IMPI 참조)

(2) Acquire

Commission 과정까지 거친 node는 ready가 되고 이 상태에서 다른 사용자에게 권한을 넘길 수 있다. 원하는 사용자가 로그인해서 원하는 node를 선택하고 acquire를 하면 권한이 넘어가고 node의 상태는 allocated로 변경된다.

(3) Deploy

Allocated 상태에서 node의 권한을 가진 사용자가 deploy를 클릭하면 배포 가능한 OS를 선택할 수 있게 되어있고 OS까지 선택하면 선택된 OS를 node에 자동으로 배포한다. 이 과정을 거치면 위에서 network interface 설정에서 사용했던 static ip 대역 중 하나의 ip가 할당되고 사용자가 접속 가능한 상태가 된다. 나의 경우엔 deployed 상태가 되어서야 power on/off가 자유롭게 가능해졌다.

8. 간단하게 node 추가하기​

위의 과정들은 언뜻 보기에 복잡할 수 있는데 여러가지 살펴보면서 기술한 것이라 그렇고 실제 사용시 가장 간단한 방법은 이렇다.

(1) OS 설치 없이 VM만 여러개 추가

(2) Add chassis

(3) Node 일괄 선택 후 commission => acquire => deploy

실제 사용자 선택에 의한 power on은 deployed 상태에서만 가능했지만 commission 과정에서도 알아서 부팅하므로 큰 문제는 아닌 것 같다.

# 참고​

http://maas.io/get-started

http://maas.io/how-it-works

https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface

최근 다시 AWS를 이용하게 되면서 AMI 선택하는데 눈에 띄는 변화를 목격했다.

아래 그림처럼 이미지 대부분이 HVM으로 바뀐 것인데 정확히는 PV가 사라진 것.

그림에는 다 나오지 않았지만 사용중인 region에서 Ubuntu의 경우 HVM 이미지만 제공하고 있다.

먼저 PV(Para Virtualization)와 HVM (Hardware Virtual Machine)의 차이부터 정리할 필요가 있겠는데,

PV는 반가상화로 guest os가 hypervisor를 통해 hardware를 제어하고 가볍기 때문에 퍼포먼스가 좋지만 guest os에 수정이 필요하다. 반면에 HVM은 전가상화로 보면 되는데 다른 guest와 완전히 독립되고 os 수정없이 그대로 사용가능하다는 이점이 있지만 hardware 자체가 전가상화 기능(CPU의 VT)을 지원해야 하기 때문에 이것이 부담이 되어 퍼포먼스가 PV에 비해 떨어진다고 알려져 왔었다.

AWS는 Xen 기반이지만 PV, HVM 모두 제공해왔고 위에서처럼 초기부터 PV 성능이 더 좋다고 알려져왔기 때문에 HVM을 선택할 일은 없었는데 왜 이렇게 바뀐 것인지 찾다가 재미있는 글을 보게 되었다.

AWS in 2015: Why You Need to Switch from PV to HVM

이 글을 보면,

PV가 HVM보다 성능이 좋기는 했지만 그 차이가 크지 않았고 AWS가 발전하면서 퍼포먼스 차이가 더 줄어들었거나 어떤 경우는 HVM이 더 좋은 성능을 내는 경우도 있다고 한다. 또 이렇게 된 이유로 Xen 자체의 기술 향상, 새로운 세대의 CPU 도입, EC2 driver의 향상 등을 들고 있다.

그리고 이번에 직접 목격한대로 AWS는 PV => HVM으로 점차 바꾸고 있는 중인 것 같고 최신 instance type들은 HVM으로만 제공하는 것으로 보인다. AMI matrix를 살펴보니 이제 PV 지원하는 instance type은 거의 없다.

위 링크에서 본 것중에 또 하나 재미있는 것은 T2 instance type에 대한 것이었는데,

CPU의 20~40%를 baseline으로 긋고 CPU 사용량이 그 이하가 되면 token을 적립하고 baseline을 초과하면 적립된 token을 소모하는 방식이라고 한다. PyCON APAC 2016에서도 잠깐 들었던 것 같은데 token이 정확히 어떤 단위인지 모르지만 과금과 관련된 얘기였던 것으로 기억된다. 어느 회사에선가 instance를 잘게 쪼개고 저녁엔 shutdown 해서 token 적립하고 아침엔 다시 올려서 적립된 token 쓰며 거의 공짜로 이용하고 있다던데. T2도 한 번 알아볼 생각.

친구들과의 모임 하나는 매월 회비를 걷는다. 한 녀석이 총무를 하다가 내가 넘겨받게 되었는데 회비 입금과 사용내역을 Google spreadsheet으로 관리하고 있다. 가끔 수정하게 되는 문서이다보니 나도 링크를 별도로 보관하고 있지도 않고 친구들도 마찬가지. 따로 수정하고 링크 보내주는 것도 귀찮고 해서 문서 수정시에 그 친구들과 함께 사용하는 telegram 그룹으로 메세지를 날리는 봇을 만들어보기로 했다. 결국은 내가 총무를 하는 기간 동안 수행하게 될 '링크 복사 + 텔레그램 실행 + 그룹 선택 + 링크 붙여넣기' 시간의 총합보다 더 많은 시간이 든 것 같지만...젠장...귀찮음이 줄었다는 데 만족하기로 했다. 이제 회비 문서를 수정하면 아래 이미지처럼 그룹 채팅에 초대한 bot이 수정된 문서 이름과 링크를 보내준다.

1. 어떻게 만들어볼까?​

Telegram bot은 예전에 구현했던 걸 활용하기로 하고 python으로 가볍게 처리해보기로 했다. 처음엔 Flask 써서 REST API 구현한 후 내가 원하는 걸 컨트롤할까 했었는데 어차피 telegram bot으로 원하는 기능은 가능하니 패스. 문서 변경사항은 push notification이 가능하면 좋겠다고 생각했는데 없으면 없는대로 polling으로 가보자고 생각했다.

2. Google sheets API 검토​

문서 변경사항을 감지하는게 중요하니 어떻게 알 수 있는지 조사를 해봤다. Spreadsheet이니 sheets API부터 검토. Python용 api client가 있어서 설치한 후 아래 링크에 나온 샘플을 약간 변경해서 실행했는데 변경사항을 알 수 있는 부분이 없었다. (API v4)

https://developers.google.com/sheets/quickstart/python

재밌는게 v3 버전에서 v4 버전으로의 migration은 어떻게 하는지에 대한 문서를 보니 아래 그림처럼 sheets API v3에는 updated 항목이 있어서 수정날짜를 알 수 있다.(v4에는 사라진건지)

v3 API를 사용해 updated 시간만 비교해 어떻게 해볼까 생각했는데 언제 deprecated 될지 알 수가 없어서 다른 방법을 더 찾아보기로 했다.

3. Google drive API로 push notification 시도​

Spreadsheet이나 docs 모두 Google drive에 올라가기 때문에 drive API에 쓸만한게 있는지 살펴보니 원하는게 떡하니 문서로 되어있다. (Receive Push Notifications) Google drive 내에 있는 모든 파일 혹은 지정한 파일의 변경사항을 push로 받는 방법이 기술되어 있는데 아래와 같은 과정을 거쳐야 한다.

(1) Domain 등록

Push notification이 날라오면 받을 곳이 필요한데 http로 날라오므로 web server 등의 위에 callback이 구현되어 있어야 한다. 이런건 익숙한 과정이지만 아무데나 막 보내지는 않겠다는 의지인지 사전에 google에 등록된 domain이어야 한단다. Google에서 인지하고 있는 domain인지 판단하는 기준은 몇가지가 있는 것 같은데 인증용 html 문서로 google에서 제공한 파일을 web server에 올려서 처리했다. 그냥 단순히 되는지 여부만 알려고 했을 뿐인데 상당히 귀찮았음. Domain 등록이 되면 Google API Console '사용자 인증 정보' 메뉴에서 확인이 가능하다.

(2) SSL 설정

Domain 등록까지 완료되었으니 문제없을 줄 알고 push notification 받을 web application (python flask로 대충 만들어놓고)을 실행해보니 notification 대신 오류가 날라오는데 내용이 SSL이 아니라서 안된단다. 그래서 self sign한 key와 인증서 만들어서 적용한 후에 해보니 이번엔 무반응. 문서를 여러번 수정해도 push가 없었다. 내가 찾지 못한 것인지 제공되지 않는 건지 모르겠지만 Google API Console에서는 API 호출 횟수와 성공 실패 여부, 반응 속도 등은 표시되는데 실패한 경우 왜 실패했는지에 대한 로그나 내용을 확인할 수 없었다. 대신 stackoverflow에서 찾은게 self sign 인증서로는 받을 수 없다는 내용. (http://stackoverflow.com/questions/17831828/not-getting-google-drive-push-notifications) 내가 직접 파악한 내용이 아니기 때문에 저 내용이 맞는지는 검증을 해봐야 아는 문제이지만 이미 충분히 귀찮아진 상태여서 push는 포기.

Push notification 문서를 보면서 인증과 관련된 내용을 함께 살펴보게 되었는데 유용했다. Google api client 사용하면서 OAuth 2.0 인증시 사용자가 요청된 권한을 확인한 후 허가하는 부분이 거의 필수로 들어가 있었는데, (서버 측에서 활용할 경우를 위해) service account를 만들어서 전체 service에 대해 권한을 위임하는 방식을 사용하면 저 과정이 필요없었음.

https://developers.google.com/drive/v3/web/about-auth

https://developers.google.com/identity/protocols/OAuth2ServiceAccount

4. 다시 Polling​

Push 받는 건 귀찮아서 포기했고 sheets API를 사용하면 변경 여부를 확인하기 어려우니 drive API를 더 살펴보기로 했다. 다행스럽게도 push는 아니지만 변경사항을 알 수 있는 API가 있어서 사용하기로 결정.(https://developers.google.com/drive/v3/web/manage-changes) 아래와 같은 방식으로 API를 사용해야 한다.

(1) 최초에 startPageToken 가져오기 (changes.getStartPageToken)

(2) (1)의 token을 pageToken으로 해서 변경사항 가져오기 (changes.list)

(3) (2)에서 변경사항이 생기면 response에 newStartPageToken이 있으므로 그 값을 새로운 pageToken으로 update

(4) (2)~(3) 과정 반복

아래처럼 넘어오는 response를 parsing해서 처리하면 된다.

5. telepot 변경사항​

오랜만에 telegram bot python library인 telepot 사용해보니 그 사이 변경사항이 있어서 과거에 구현했던 telegram bot을 그대로 사용할 수 없었다. 내가 사용하던 기능과 관련된 변경사항은 아래 두 가지.

(1) notifyOnMessage 함수 변경 => message_loop

(2) glance2 제거됨 => 대신 glance 사용

상세 변경사항은 change log 참조.

6. 결론​

모든 파일의 변경사항을 알 필요는 없었기 때문에 telegram bot에 문서 id 등록 기능을 추가해서 변경사항이 발생하면 등록 여부를 간단히 판단해서 등록된 문서일 경우에만 메세지를 보내도록 처리했다.

Google drive API의 변경사항 가져오는 API를 반복적으로 테스트 해봤는데 모든 변경사항을 잡는 것은 아닌 것 같다. 뭔가 규칙이 있는 것 같기도 했는데 몇 분 이내에 반복적으로 발생하는 모든 변경사항을 수정이라 인지하지는 않는다. Google drive에서 직접 파일 속성 같은 걸 확인해봐도 마찬가지여서 정책이 아닌가 싶다. (셀 하나하나 수정한다고 모두 각각의 변경사항이라고 판단해도 문제일 듯) 혹시 이런 것 때문에 push가 날라오지 않은건가 싶어서 나중에 다시 시도해볼 생각.

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. Ceph은 무엇인가?​

분산 object store이자 file system으로 분산 클러스터 위에서 object storage를 구현해 object, block, file level의 storage 인터페이스를 제공한다. 하나로 object / block storage, file system 모두를 제공한다는게 장점. SPOF 없는 완전한 분산처리와 exabyte 단위까지 확장 가능하다고 한다.

2. Ceph architecture​

<출처 : http://docs.ceph.com/docs/master/architecture/>

실제 data 저장을 담당하는 것은 RADOS이고, CephFS (File System)는 FUSE 지원으로 RADOS에 직접 access가 가능하다. RBD는 일반적인 block device로 붙일 수 있도록 구성된 것으로 LIBRADOS를 통해 RADOS에 access 하도록 되어있고 RADOSGW 역시 LIBRADOS를 통해 object store에 접근할 수 있다. Application이 data를 block device로 ceph에 저장할 경우 ceph은 data를 잘라서 cluster에 replicate 한다.

3. 구성요소​

(1) ceph-mon

Cluster monitor로 active / failed node 확인하는 역할을 수행하며 ceph storage cluster map의 master copy를 유지하고 각 cluster client들은 ceph monitor로부터 cluster map 정보를 가져가도록 되어있다.

(2) ceph-mds

Metadata server로 inode와 디렉토리들의 메타데이터(filesystem의 디렉토리 및 파일이름, RADOS cluster에 저장된 object로의 매핑정보) 를 저장하며 역시 cluster 구성이 가능하기 때문에 확장 및 cluster host 사이에서의 동적인 data 분산이 가능하다.

(3) ceph-osd

Object storage devices. 실제 파일 내용을 저장하고 OSD의 상태를 확인해서 monitor에 알려주는 역할도 수행한다. 일반적인 cluster system들은 중앙에서 lookup 테이블을 관리하거나 특정 component를 두고 각 client 들이 그 component에 접근하도록 되어있지만 이런 방식이 갖는 performance, scalability, SPOF 관점에서의 제한사항들 때문에 각 client 끼리 상호작용할 수 있도록 CRUSH 알고리즘이란 것을 사용해 OSD daemon에 직접 접근하도록 되어있다.

(4) ceph-rgw : RESTful gateways. Object storage layer를 외부에 노출시키기 위한 인터페이스

4. 참고​

(1) http://ceph.com/

(2) https://en.wikipedia.org/wiki/Ceph_(software)

(3) http://docs.ceph.com/docs/master/architecture/

Ceph cluster 구성을 할 때 가장 중요한 요소는 ceph monitor와 osd 이다. "Ceph 가볍게 살펴보기"에서 기술한 것처럼 osd는 실제 object 저장을 담당하고 monitor는 node의 상태 확인이나 cluster map 정보를 담고 있기 때문. 공식 문서에 있는 설치 방법은 manual과 ceph-deploy라는 자동화 스크립트를 이용하는 방법으로 나뉘어 있는데 ceph-deploy를 사용해 보기로 했다. 공식 문서에 누락된 내용도 있고 ceph-deploy 스크립트 자체에 문제도 있는 것 같아서 함께 기술할 생각이다.

참고 : ceph-deploy를 사용한 Ceph 설치 공식문서

1. 준비​

(1) VM

실제 꼭 필요한 것은 아니지만 ceph-deploy로 각 node를 관리하기 위한 ceph-admin과 cluster를 구성할 ceph-node01, ceph-node02 총 3대의 VM (Ubuntu 14.04)을 준비했다.

(2) SSH / hosts 설정

편의를 위해 ~/.ssh/config에 각 node의 Hostname, User 등록.

ceph-deploy가 일부 설정에서 각 node의 실제 hostname을 가지고 파일을 생성하거나 처리하는 경우가 있고 host 인식을 위해 /etc/hosts에 실제 cluster node의 hostname과 IP를 등록해둔다. 아래는 ceph-admin에서 지정한 hostname이 실제 node의 hostname과 달라서 생기는 오류 (admin node에서 하위 node의 hostname을 node1이라고 지정했을 때 ceph-deploy가 ceph-mon.node1.asok 파일을 찾으려고 하지만 실제 그 경로에 가보면 ceph-mon-ceph-node01.asok 파일이 생성되어 있었다)

2. ceph-deploy 설치​

ceph-admin에서 아래의 command로 설치하면 되는데 hammer (ceph release name)라고 지정해도 이후 ceph 설치과정에서 ceph-deploy가 repository를 자동으로 최신인 jewel로 변경해버린다.

[bash]

wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -

echo deb http://download.ceph.com/debian-hammer/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list

sudo apt-get update && sudo apt-get install ceph-deploy

[/bash]

3. ntp / openssh-server 설치​

Ubuntu 14.04 설치했을 때 이미 ntp와 openssh-server가 설치된 상태였지만 혹시 설치되지 않은 상태라면 설치해둔다. (NTP는 각 node간 시간 동기를 위해 필요하다고 가이드 하고있음)

4. Ceph user 추가​

공식문서에는 ceph 설치와 관리를 위한 별도 user를 생성하라고 되어 있고 보안 및 기타 이유로 ceph이라는 이름은 사용하지 말라고 명시되어 있어서 cephuser라는 이름으로 사용자를 생성하고 sudoer로 등록했으나 실제 파일 생성 등의 작업은 ceph이라는 사용자로 진행이 되는 것으로 보인다.  아래의 command를 이용하거나 별도의 방법으로 모든 node에서 user 추가 (home 디렉토리는 추가되어야 함)

[bash]

sudo useradd -d /home/cephuser -m cephuser

sudo passwd cephuser

# set password

echo "cephuser ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/cephuser

sudo chmod 440 /etc/sudoers.d/cephuser

[/bash]

5. SSH keygen / 공개키 복사​

ceph-deploy가 사용할 때가 있으므로 ceph-admin의 ssh keypair를 생성하고 각 node에 복사해준다.

[bash]

ssh-keygen

ssh-copy-id cephuser@ceph-node01

ssh-copy-id cephuser@ceph-node02

[/bash]

6. Network / firewall 설정 (Optional)​

Public network, cluster (internal) network으로 분리해서 설정하는 내용이 문서에 있으나 내부 IP로만 연결할 생각이어서 별도 조치없이 넘어감

7. ceph-deploy가 사용할 디렉토리 생성​

현재의 working directory에서 ceph-deploy가 필요한 파일들을 생성하고 가져오므로 별도 디렉토리를 만들고 그 안에서 ceph-deploy를 실행하는게 좋다.

[bash]

mkdir cluster && cd cluster

[/bash]

8. Monitor node 생성 / pool size 설정​

Monitor가 돌아갈 node를 지정하는 내용으로 편의상 ceph-node01만 지정 (나중에 추가도 가능)

[bash]

ceph-deploy new ceph-node01

[/bash]

이 과정을 거치면 working directory에 ceph.conf 파일이 생성되는데 osd pool 크기를 지정해줘야 한다. osd 하나에 파일을 저장하고 하나는 replicate 용도로 사용할거라 2로 지정

[bash]

# add this in global section of ceph.conf

osd pool default size = 2

[/bash]

9. Ceph 설치​

이제 ceph과 관련된 것들을 설치하는 과정을 수행하면 된다. Admin node에서 설치할 node를 지정할 수 있는데 아래처럼 admin node 포함 전체 node에 설치하도록 했다. (이 과정인지 다른 과정에서 자동으로 ceph repository가 최신인 jewel로 변경되는데 release 등의 option이 있어서 다른 버전 설치가 가능한 것처럼 보이지만 실제 option을 줘서 hammer로 강제 설정한 결과 오류 발생)

[bash]

ceph-deploy install ceph-admin ceph-node01 ceph-node02

[/bash]

10. Monitor 초기화​

Ceph까지 설치했으면 monitor 초기화를 해야 한다.

[bash]

ceph-deploy mon create-initial

[/bash]

11. OSD 설정​

(1) OSD가 사용할 경로 추가

OSD가 돌아갈 각 node에서  osd가 사용할 경로를 추가해준다. 여기서 중요한게 뒤에 있는 숫자를 임의의 숫자로 변경하면 나중에 activate 과정에서 오류가 발생한다. Manual 설치 과정을 잠깐 봤을 때 osd node 각각에 순서대로 숫자를 부여해서 그 숫자를 이용해 내부적으로 뭔가 작업을 하는 것 같은데 잘 이해가 안되는 부분이다.

[bash]

# in ceph-node01

sudo mkdir /var/local/osd0

# in ceph-node02

sudo mkdir /var/local/osd1

[/bash]

(2) Prepare osd

이제 osd를 준비하는 초기화 과정인데 ceph-admin에서 아래의 command를 실행한 후 메세지를 유심히 보면 생성하는 몇 개 파일의 owner를 변경하는 과정을 확인할 수 있다.

[bash]

ceph-deploy osd prepare ceph-node01:/var/local/osd0 ceph-node02:/var/local/osd1

[/bash]

(3) Activate osd

(Activate 하기 전에 각 osd path의 owner, group을 ceph으로 변경해주어야 함)

[bash]

# in nodes

sudo chown -R ceph:ceph /var/local/osdX

[/bash]

위 그림처럼 일부 파일의 owner 설정과정을 언급한 이유는 activate 과정에서 오류가 발생하기 때문인데

재미있는게 아래 그림에서처럼 ceph-deploy가 몇 개 파일만 owner 지정을 자동으로 하고 디렉토리 자체는 생성했을 때의 사용자 소유로 그대로 두고 있어서 권한 문제가 발생할 수 밖에 없다. (공식 문서에서 누락된 내용이기도 하고 스크립트 자체가 문제가 있다고 보여짐)

그렇기 때문에 사전에 osd가 사용할 경로의 owner를 변경해주는게 꼭 필요하다. Activate은 아래의 command 실행

[bash]

ceph-deploy osd activate ceph-node01:/var/local/osd0 ceph-node02:/var/local/osd1

[/bash]

12. Node 설정 및 keyring 파일 복사​

ceph-admin에서 아래의 command를 실행하면 각 설정 및 keyring 등 필요한 파일이 /etc/ceph 경로에 복사되는데 그 후에 keyring 파일의 읽기 권한을 추가해줘야 한다.

[bash]

ceph-deploy admin ceph-admin ceph-node01 ceph-node02

sudo chmod +r /etc/ceph/ceph.client.admin.keyring

[/bash]

13. Health check​

기본 설정은 다 완료된 것이므로 각 node와 osd가 정상인지 ceph-admin에서 확인해본다. HEALTH_OK가 나오면 정상.

[bash]

ceph health

[/bash]

14. 결론​

ceph-deploy를 사용한 설치는 몇가지 문제가 있는 것으로 보이기 때문에 이후에 manual로 설치를 다시 해서 과정이나 기타 내용들을 좀 더 깊게 살펴본 후에 가능한 자동화까지 진행해보는게 좋을 것 같다. 또 확장이 용이한지 문제가 발생했을 때 복구 같은 것들은 어떻게 할 수 있는지 performance 측면에서 쓸만한지 등의 내용도 검토해볼 필요가 있겠다.

Java로 간단한 console application을 만들다가 이상한 문제들을 마주하게 되었다.  그 중 하나는 DB 연결이 계속 끊어지는 현상. 현재 시점에서도 DB에 가해지는 부하는 정말 작은 수준이었기 때문에 특별히 tuning할 이유는 없었고 퍼포먼스와 관련해서는 기본 설정값으로 사용하고 있었는데 끊어지는 이유를 알 수가 없었다. (MySQL 5.5의 default wait_timeout은 8시간)

1. 환경​

Application 동작의 흐름은 DB select, 특정 행위, DB update 순서였는데 특정한 기능을 수행하는게 길게는 20분 정도 혹은 그 이상 소요되는 경우가 있었고 편의를 위해 MyBatis를 사용했으며 pool을 사용하도록 설정해 두었다. 연결이 끊어지는 현상을 보고 poolPingQuery, poolPingEnabled를 설정해 봤는데 마찬가지.

2. Azure에 idle timeout이 있다​

우선은 MyBatis 설정과 별개로 왜 DB연결이 끊어지는지 궁금해졌다. DB와의 연결은 어차피 socket을 사용하기 때문에 DB와 application 사이의 통신에 영향을 줄 수 있는 것들은 많다. MyBatis 아래의 JDBC, Kernel의 socket timeout, 공유기 설정 등을 살펴봤는데 특이한 내용은 발견할 수 없었다.

다음으로 Azure에 어떤 특성이 있지 않을까 싶어서 알아보니 따로 idle timeout이 있다고 한다. 기본값이 4분이라고 하는데 테스트한 내용과 정확히 맞는다. (강제로 sleep 시간을 늘려가며 테스트해보니 3분까지는 문제가 없었고 4분부터 연결이 끊김을 확인) 이런 내용은 Azure 문서에 잘 보이지 않고 설정 또한 UI로는 불가능하다. PowerShell로만 가능한데 현재 열려있는 endpoint를 확인해보면 공백으로 표시되고 있고 powershell로 IdleTimeoutInMinutes 값을 30분까지 늘릴 수 있다고 한다.

3. Pool ping에 대한 잘못된 소문​

Azure의 idle timeout과 별개로 MyBatis의 poolPing에 대해서 살펴보기로 했다. Pool ping 설정 중에 poolPingConnectionsNotUsedFor 가 있는데 문서 상으로는 마치 설정된 시간에 한번씩 DB에 ping으로 설정된 쿼리를 날려서 연결을 유지해줄 것처럼 보인다. 국내의 대부분 블로그 등에서도 비슷하게 설명하고 있다. 하지만 이 내용은 공식 문서가 잘못된 것인지 예상한대로 동작하지 않는다. 거의 동일한 의문을 가진 해외 사용자의 글을 보기도 했는데 소스를 보면 connection pool에서 실제 connection을 꺼내오거나 넣을 때만 connection이 유효한지 확인을 하는데 이 때 pool ping과 관련된 작업을 수행한다. poolPingConnectionsNotUsedFor에 설정된 값은 connection 유효성을 확인할 때만 영향을 주기 때문에 pool에서 connection을 꺼내오고 집어넣는 시점 이외에는 전혀 영향을 주지 않는다.

4. 결론​

Azure나 기타 환경에 대한 timeout 값을 늘리는 것은 좋은 방법은 아니라고 본다. DB connection을 오래도록 유지해야만 하는 상황이라면 별도의 장치를 두어서 connection을 유지하도록 조치하거나 아니면 아예 비용이 소모되더라도 필요한 상황에서만 connection을 맺고 끊는 게 나을 것 같다..

5. 참고​

(1) MyBatis 공식문서

http://www.mybatis.org/mybatis-3/configuration.html

(2) MyBatis 참고 소스

https://github.com/mybatis/mybatis-3/blob/mybatis-3.3.1/src/main/java/org/apache/ibatis/datasource/pooled/PooledDataSource.java

https://github.com/mybatis/mybatis-3/blob/mybatis-3.3.1/src/main/java/org/apache/ibatis/datasource/pooled/PooledConnection.java

지난번에 만들어놓은게 고작 IP를 얻기 위해서 package를 별도로 설치해야 한다는게 마음에 걸렸다. 어차피 그 package도 IP 정보를 얻기위해 네이티브 API를 사용하지 않을까 싶어서 방법을 찾아보기로 했다. 사실 가장 좋은 방법은 그 package 소스를 보고 분석하는 것이겠지만 시간이 꽤 걸릴 것 같기도 해서 우선은 간단히.

1. socket.gethostbyname()​

원래 처음에 사용했던 방법은 socket의 gethostbyname 함수를 사용하는 것이었다. 이 함수는 hostname을 ip address로 변환해주는데 hostname을 얻기 위해서 gethostname() 이나 getfqdn()을 사용해봤다. OS X에서는 특별한 문제가 없어서 그냥 사용하려고 했는데 raspberry pi로 넘어가니 IP가 자꾸 '127.0.0.1'로 나온다. /etc/hosts와 관련이 있는데 예전에 Java로 했을 때도 비슷한 현상이 있었던 것 같다.

아무튼 hostname과 관련된 다른 작업을 해주지 않으면 gethostbyname은 사용하기 어려울 것 같다는게 결론.

2. netifaces​

이름처럼 network interface와 관련된 기능을 구현해놓은 package로 설치만하면 정말 간단하게 interface 별로 원하는 정보를 얻을 수 있다. 예를 들어 interfaces 함수를 호출하면 존재하는 모든 interface가 다 튀어나오고 ifaddresses 함수를 사용하면 해당 interface가 가지고 있는 address 정보를 던져준다.

하지만 설치가 귀찮아서...

3. socket.connect() / socket.getsockname()​

그래서 최종적으로 사용한 방법은 socket으로 어딘가에 연결한 후에 연결된 socket 정보로부터 IP를 얻어오는 방법이다.

그림처럼 socket을 생성한 후에 아무곳이나 연결한다. 아무곳이라는게 그래도 연결이 가능한 곳이어야 하니 google이 망하지 않는한 유지될 것 같은 걔네 DNS에 연결해본다. socket.connect() 함수는 address를 받게 되어있는데 AF_INET family로 socket을 생성했으니 (host, port)로 이루어진 tuple을 넣는다. port는 아무거나 해도 관계없겠지만 사용되지 않을 것 같은 1을 넣어줬다. (0을 넣을 경우 OS X에서는 오류가 발생함)

연결된 이후에는 socket의 주소를 받아본다. ip와 port가 넘어오니 그 중에 ip 정보만 받으면 끝. (port는 실제 8.8.8.8의 1번 포트와 연결을 맺은 임의의 port 번호가 날라옴)

Raspberry pi로 뭘 해볼까 하다가 요즘 진행중인 프로젝트도 있고 해서 CCTV로 활용해보기로 했다.

어차피 카메라 모듈은 있고 기본 제공되는 툴로 스틸사진은 찍어본 적이 있으니 가볍게 접근할 수 있을거라 생각했다.

1. Motion 사용​

검색을 해보니 motion이라는 툴을 CCTV로 활용할 때 많이 사용하는 것 같았다.

MJPEG으로 스트리밍 비슷하게 해주고 별도의 클라이언트 없이 브라우저로 가볍게 영상확인도 가능한 것 같아서 선택.

OS로 데비안 계열의 Raspbian을 사용하고 있으므로 apt-get으로 간단하게 설치할 수 있고 /etc/motion/motion.conf 파일에서 각종 설정을 변경할 수 있다.

원격으로 영상 확인과 설정을 제어하기 위해 webcam_localhost와 control_localhost를 변경하고 restart를 했는데 (default로 localhost에서만 접근 가능하도록 설정되어 있음) 영상이 나오질 않았다.

이상해서 시스템 로그를 확인해보니

device를 열 수 없다고 한다.

예전에 카메라 모듈 장착하고 raspi-config에서 enable 설정도 해줬는데 실제 /dev에 보니 video0이 없었고 motion의 설정 파일은 video capture를 위해 default로 /dev/video0를 읽도록 되어있었다.

2. modprobe​

로딩되어 있는 모듈들을 살펴보기로 했다.

그림처럼 이런저런 모듈들은 보이지만 video 관련된건 없다.

그래서 문서를 좀 찾아보니 camera는 v4l2 driver를 사용하도록 되어있고 (https://www.raspberrypi.org/documentation/hardware/camera.md) 사용중인 raspberry pi가 broadcom의 bcm2835 chip이 박혀 있어서 bcm2835-v4l2라는 모듈을 raspbian에 넣어둔 것으로 보인다.

modprobe 명령으로 bcm2835-v4l2를 로딩하고 나서 확인해보면 아래 그림처럼 video 관련 모듈이 뜬다.

모듈을 로드한 후 motion을 restart 하니 문제없이 영상을 확인할 수 있었는데 modprobe는 일시적으로 모듈을 올려주는 것이기 때문에 boot 이후에 항상 사용하기 원한다면 /etc/modules 파일에 모듈 이름을 추가해야 한다.

3. LED off​

Video가 정상으로 나오는건 확인했는데 카메라 모듈에 달려있는 적색 LED가 항상 켜져있는게 마음에 걸렸다.

상당히 밝아서 눈에 거슬리고 작지만 쓸데없이 파워를 소모하긴 싫으니 꺼보기로 했다.

관련 문서가 있을 것 같아서 찾아보니 역시...

https://www.raspberrypi.org/documentation/configuration/config-txt.md

문서에 의하면 Raspberry PI는 BIOS 대신 /boot/config.txt 파일에서 각종 설정을 변경할 수 있도록 해뒀다고 한다.

/boot/config.txt에 disable_camera_led = 1 을 추가해주고 reboot 하면 카메라는 동작중이지만 LED는 켜지지 않는 걸 확인할 수 있다.

4. 결론​

결국 해놓고 보니 뚝뚝 끊어지긴 하지만 훌륭한 퀄리티를 원했던 것은 아니니까 그냥 넘기기로 했음

(framerate 조절해도 별 차이 없었음)

Raspberry pi를 가지고 놀다보니 불편한 점이 하나 있었다. 작아서 휴대성이 좋기는 한데 새로운 환경에서 전원을 켰을 때 접속 정보를 알기 위해서 번거로운 작업을 해야 한다는 것이다. HDMI 케이블, USB 혹은 무선 키보드/마우스를 들고 가서 다 연결한 후에야 사용 가능한데 주변기기들이 훨씬 크기 때문에 여간 불편한게 아니다. 특히 나의 경우엔 ssh로 붙어서 작업하는 빈도가 높고 연결된 모니터를 직접 보며 작업하는 일은 거의 없기 때문에 위의 과정이 좀 무의미했다.

그래서 인터넷 연결이 되면 IP 정보만 telegram으로 전달하는 모듈을 만들어보기로 했다.

1. Github​

https://github.com/blurblah/tell_me_your_ip

위 저장소에 올려두고 대략적인 설명을 써넣었으니 참조.

2. Telegram bot의 제약사항​

예전에 telegram bot을 만들어봤을 때 한가지 제약 혹은 유의할 점을 하나 알았는데 하나의 token을 가진 bot은 한 곳에서만 동작해야 한다는 점이다. 두 군데 이상 동작하려고 하면 하나는 오류를 뱉고 실행되지 않는다. 위 저장소에 있는 소스는 device에서 직접 동작하게 되어있기 때문에 telegram bot을 직접 생성해서 token을 넣게 되어있다. 여러개의 device를 대상으로 활용하기 위해서는 방식을 변경해야 할 것 같다. 특정 서버 한 곳에서 bot이 동작하게 하고 device를 등록한 후에 관리되게 만들어야 할 것 같은데 나중에 필요성이 생기면 작업해봐야겠다.

3. 동작 결과​

Raspberry pi를 새로운 곳에서 LAN 케이블을 연결하고 전원을 올리면 곧 아래와 같은 메세지가 telegram으로 전달된다. 모든 network interface의 정보를 다 뿌리게 되어있는데 필요한 정보만 선별해서 다듬은 후에 전송할 필요가 있어보인다.