'개발'에 해당되는 글 285건

https://www.rabbitmq.com/download.html 

위 링크의 공식홈에서 rabbitMQ tar ball을 받아서 압축만 풀면 설치는 끝난다.

RabbitMQ가 Erlang이라는 language기반으로 동작하기 때문에, 사전에 Erlang을 설치해주어야 한다.

소스설치가 베스트하긴 하지만, 뭔가 설치해야 될게 엄청나게 많아보여서 yum으로 설치를 진행하였다.

아래 명령어로 yum repository에 erlang repository를 등록을 해준다.

$ wget -O /etc/yum.repos.d/epel-erlang.repo http://repos.fedorapeople.org/repos/peter/erlang/epel-erlang.repo

$ yum install erlang

vagrant로 설치한 기본 vm기준으로 위 install명령으로 106개의 어플리케이션이 설치가 된다...

그렇기 때문에, RabbitMQ만을 위해 erlang을 설치하는 경우는 yum으로 패키지 설치를 추천한다.

압축을 풀어둔 RabbitMQ 폴더 기준으로 sbin 경로에 실행파일들이 몰려있다.

실행 방법은 ./rabbitmq-server를 실행하면 기본 포트 5672로 데몬이 실행이 된다. (25672는 클러스터용 포트인데 같이 뜬다.)

AMQP를 지원하는 솔루션들은 WebAdmin 페이지를 별도로 제공을 해준다.

ActiveMQ같은 경우는 기본으로 제공을 해주고, RabbitMQ는 기본 제공은 아니고

플러그인 형태로 설치를 하면 접근이 가능하다.

아래와 같이 rabbitmq_management 플러그인을 활성화 시킨 후, 데몬을 재시작해준다.

$ /sbin/rabbitmq-plugins enable rabbitmq_management

그러면 15672포트로 admin 페이지 접근이 가능해진다.

http://localhost:15672

기본 ID/ Password는 guest / guest로 지정이 되어 있는데,

특정 버전부터 localhost에서만 접근이 가능하기 때문에, 

서버가 원격지나 VM에 있다면, 별도로 계정을 생성해서 admin권한을 넣어주어야 한다.

유저 ID가 jss, 패스워드가 1234인 유저를 추가해주고,

$ /sbin/rabbitmqctl add_user jss 1234

administrator권한을 지급한다.

$ /sbin/rabbitmqctl set_user_tags jss administrator

이후에 접근을 하면 로그인이 되면서, 모니터링 및 관리를 할 수 있는 페이지를 볼 수 있다.

RabbitMQ 기본 포트 (5672)에 커넥션을 맺을때도, admin 페이지 로그인과 마찬가지로 localhost가 아니면 접근이 되질 않기 때문에,

커넥션 정보에 username, password를 포함해주어야 한다.

추가로, virtual hosts에 대한 access권한을 필요로 하는데, 아래 화면을 참고한다.

admin 페이지 상단의 admin탭을 눌러서 user를 클릭하면 아래와 같은 화면이 나오는데,

여기서 access권한을 줄 수가 있다.

드디어, 원격지 서버에서 RabbitMQ로의 접근이 가능하게 되었다.

접근은 잘 되는데, 임의의 QueueName을 지정하여, 데이터를 Send하니 Queue가 존재하지 않는다는 메시지가 발생해서..

Admin페이지의 Queues로 들어가서 지정했던 QueueName에 해당하는 Queue를 만들어주니 Send, Recv가 정상적으로 이루어진다.

클러스터 구성이 전부 rabbitmqctl 명령어 만으로 가능하다.

1, 2, 3번 vm에다가 rabbitMQ instance를 하나씩 띄워서 테스트를 진행하였다.

선행작업으로 erlang의 cookie를 각 노드에 동일하게 맞춰주어야 한다.

vagrant로 똑같은 이미지를 사용해서 vm구성을 해서 그런지 모르겠지만, 본인 같은 경우 모두 같아서 작업을 진행하지 않았지만,

다른 경우 ~/.erlang.cookie 나 /var/lib/rabbitmq/.erlang.cookie 둘중에 하나는 있을 것이므로,

하나를 열어서 다른 머신에도 동일하게 맞춰준다.

선행작업이 완료되었으면, 클러스터 구성을 위한 모든 준비가 끝났다.

cluster join시 ip따위 지원하지 않기 때문에, 각 노드의 hostname을 /etc/hosts에 명시해두도록 한다.

hosts파일에 지정될 hostname은 cli에서 hostname이라고 나오는 hostname이 기준이 되어야 하고, 

cluster_join시에 지정될 hostname은 아래 명령어를 통해 확인을 한다.

node-1$ ./rabbitmqctl cluster_status

기본적으로 rabbit@node-1과 같이 앞에 rabbit@이 추가로 붙게 된다.

2번 노드를 1번 노드와 묶어보도록 한다.

일단 stop_app으로 source node를 죽이고 시작을 하는게 안전하다.

node-2$ ./rabbitmqctl stop_app

2번 노드를 1번 노드와 join하여 클러스터 구성을 한다. (옵션으로 --ram, --disc을 지원하는데, 해당 노드에 들어가는 데이터가 메모리만으로 동작을 할지, 디스크에서 동작을 할지를 결정한다.)

node-2$ ./rabbitmqctl join_cluster --ram rabbit@node-1

성공했으면, 2번 노드를 다시 시작하고, cluster_status를 해보면, 1번 노드와 클러스터 구성이 된 것을 확인할 수 있다.

node-2$ ./rabbitmqctl start_app

node-2$ ./rabbitmqctl cluster_status

3번 노드도 마찬가지로, 같이 묶어준다. 

클러스터 구성 시 주의할 점이 하나 있는데, 3개 노드가 전부 ram으로 동작을 하면,

미러링 구성을 한 경우, 한 대가 내려가면 모든 데이터가 날아가버리는 현상이 발생을 하기 때문에, 

disc로 동작하는 노드가 하나 존재 하도록 구성하는걸 권장한다고 한다.

위에 작성한 내용처럼 진행을 하면, 보통 1번 노드는 disc형태로 동작을 하기 때문에, 별로 신경쓰지 않아도 될 것 같다.

하지만, cluster_status로 확인 시에 모두 ram으로 돌아가고 있다면, 아래 명령어로 노드 하나는 type을 disc로 변경을 해주어야 한다.

모든 변경 작업은 stop_app 이후에 하는 게 안전하다.

node-1$ ./rabbitmqctl stop_app

node-1$ ./rabbitmqctl change_cluster_node_type disc

node-1$ ./rabbitmqctl start_app

클러스터 구성을 3대를 해두었는데, 부하량이 생각보다 적어서 하나를 제거할 경우에는, 해당 노드에 들어가서, reset을 해버리면 된다.

node-3$ ./rabbitmqctl stop_app

node-3$ ./rabbitmqctl reset

클러스터 구성이 완료되고, 이제 서로 다른 노드에 저장된 데이터들도 공유가 되게 되었다.

하지만, 노드 하나가 죽어버리면 해당 노드에 있던 데이터가 그냥 날라가버리므로 장애가 발생을 한다.

이럴 경우를 대비하여 미러링 정책 설정을 하여, 모든 노드에 데이터를 중복 저장할 수 있도록 해주는 것을 권장한다. 

test- 로 시작하는 모든 queue, exchange에 대하여 미러링 구성을 한다.

어떤 이유에서인지는 잘 모르겠지만, test-*부분을 *로 그냥 바꿔버리면, syntax가 잘못되었다고 경고메시지를 발생시킨다.

한 번에 너무 많은 처리가 이루어지는 것을 막은 것 같기도 하다.

node-1$ ./rabbitmqctl set_policy ha-all "test-*" '{"ha-mode":"all"}'

이 구성은 web admin페이지에서 admin - policy에 들어가서 더 쉽게 설정을 할 수 있다.

이제 RabbitMQ는 서비스할 수 있는 환경이 만들어지긴 했는데,

클러스터 구성이 되었다고 해서, failover같은 장애복구를 해주진 않는다.

HAProxy같은 LoadBalancer를 앞단에 두어, failover처리를 할 것을 권장한다.

다음 포스트에서는 HAProxy를 이용해 각 노드간의 load balancing을 구성해보도록 할 예정이다.

Go가 대세라길래 튜토리얼이나 해보자하고, 시작하던 찰나에

IDE는 뭐가 좋을까!? 검색해보니 Sublime Text가 가장 낫다고 하여, 개발환경 세팅부터해서 제대로 해보기로 하고 

시작했는데, 하루종일 삽질을 하다가, 퇴근 시간 1시간 전에 극적으로 해결해서 글로 남겨놓음.

Windows는 64비트 환경이고, Go Lang은 최신버전을 사용해도 상관없음.

1. Go Lang 설치 (http://golang.org/)

 - 설명이랄 것도 없음. 그냥 다운받아서 더블클릭. 끝

 - 환경변수 정도는 알아서 잡아주어야 함.

2. Sublime Text 3 설치

 - 1번과 마찬가지. (사용자 폴더명에 한글이 포함되어 있는 분은 Portable 사용을 권장.. 띄어쓰기, 한글에 굉장히 민감한 툴임)

3. Sublime Text 3에서의 Package Control 설치

  - Package Control 공식 홈에 Console열어서 설치하라고 가이드 되어 있는데, 잘 안된다.

  - Preference -> Browser Packages로 탐색기를 열고,  Packages 폴더로 이동해서 git으로 바로 clone받는다. 아래 명령어 입력

  - git clone https://github.com/wbond/sublime_package_control.git "Package Control"

  - Sublime Text 3를 재시작 하면, Pakcage Control 설치 완료

4. GoSublime 설치 (https://github.com/DisposaBoy/GoSublime)

 - Ctrl + Shift + P를 누르고, Package Control : Install Package를 선택하여, GoSublime을 선택하면 설치가 완료됨.

 - 위에 명시된 GitHub에서는 여기까지만 하면 제대로 될거다라고 설명을 하고 있는데, 내 컴에서는 Margo가 없다고 빌드를 못하겠다고 해서, Issue를 검색해보니, 수동으로 빌드를 하면 해결이 된다고 한다. (https://github.com/DisposaBoy/GoSublime/issues/445)

난, 이거 읽고도 한참 헤맸으니, 정리해보는걸로..

5. Margo 수동 빌드

 - ST3 ROOT\Data\Packages\GoSublime\src폴더에 보면 gosubli.me 폴더가 있는데, 얘를 GOROOT\src로 옮겨준다.

 - 옮긴 폴더에 들어가보면 margo, something-borrowed 폴더가 있는데, something-borrowed 폴더에서 cmd창을 열고, gocode폴더로 이동 후 go build -> go install 순으로 입력해 준다. (에러가 발생하는 경우, 대부분 환경변수 문제이므로 알아서 해결한다.)

 - something-borrowed\types 폴더에 가서도 go build -> go install 입력.

 - 이제 다시 gosubli.me 폴더에 가서, margo 폴더로 이동 후, go build를 입력하면, Margo.exe 파일이 생성된다.

 - 해당 파일을 이름을 바꾸어 주어야 하는데, ST3 에서 발생했던 로그를 View - Console을 열어서 잘 보면, Margo 어쩌고 하는 exe파일이 없다고 나오는게 원인인데, 지금까지 했던 작업이 그 파일을 수동으로 빌드해서 넣는 과정이었으므로, 파일명을 에러 로그에서 없다고 찍힌 파일명으로 변경해준다.

 - 해당 파일을 ST3 ROOT\Data\Packages\User\GoSublime\windows-x64\bin\ 경로에, 방금 exe파일을 옮겨준다.

 - ST3 재시작

참고로 ST2에서는 뭐가 문젠지 잘 안된다. Beta버전인 ST3보다 못한 것 같다.

https://github.com/Seseong-Jang/simple_go_tcp_chat

Seseong-Jang/simple_go_tcp_chat

simple_go_tcp_chat - simple tcp chat server and client for learning go

github.com

튜토리얼 한 번 쭉 해보고, 이틀정도 걸려서 만들면서 느낀거지만.

고루틴이랑 채널의 연계는 어마어마한것 같다.

이것만으로 멀티쓰레드 형태의 프로그램이 가능하다니;;

단점은, 이건 C에서도 그랬었겠지만 string compare가 불편하고, string concat도 불편하다;

하지만 대안으로 go에서 패키지 형태로 지원하는게 있어서 다행임.

string concat은 bytes.Buffer의 writeString으로 처리하고,

compare는 strings 패키지를 이용하여 처리하였음. (물론 native로 구현하는게 넘사벽으로 빠르다고하긴함)

list같은 경우에도 iteration하면서 안에 값을 변경하면 list안에 들어있는 값도 변경될줄 알았는데

변경이 안되던.. 난 분명히 포인터로 집어넣었는데;; pushBack하는 순간의 객체 상태만 유지한다.

변경이 필요없이 유지해야할 정적인 항목들을 이용할 때만 사용해야 될 것 같다.

메소드에서 nil (go에서 null이라 칭하는) 반환도 안된다!

그래서 리턴 값이 객체라면 생성자 한번 돌려서 이상한 값들 넣은다음에 예외처리할 때 그 값으로 활용해야함.

하지만, strings의 hasPrefix이 함수는 정말 맘에든다.

전체 채팅, 귓속말, 채널 채팅, 닉네임 중복 유저 접속 차단 정도의 기능만 구현되어 있음.

보통 Maven을 설치하면, conf아래에 settings.xml이 있고,  

Nexus의 인증 정보를 settings.xml의 <servers>에다가 넣어주는데,

이게 Jenkins에서 deploy할때는 /home/{user}/.m2/settings.xml을 기본으로 참조하는 것 같다.

따라서, Maven/conf 폴더에 있는 settings.xml을 .m2/아래로 복사만해주면 해결이 된다. 

물론, 기존에 쓰던 pom.xml내에 포함된 설정으로, Goals and options에다가 tomcat7:redeploy라고 입력하면,

배포는 잘 하는데, UnStable빌드인데도 무조건 Goal을 수행하기 때문에, 불안정한 빌드가 올라갈 가능성이 생겨버린다.

(Eclipse에선 불안정한 빌드면 잘 걸러내더만...) 

이런 현상을 방지하기 위해, 빌드 후 조치를 사용한다.

Tomcat에 배포하기 위해서는, Deploy Plugin을 설치해야 하고, 설치 한 후에 Deploy war/ear to a container메뉴를 선택해서

pom.xml에 tomcat7 plugin을 설정했던 것처럼 입력해준다.

다만 다른점이 있다면.. Tomcat 경로 지정 시에 /manager/text는 제외되고, 기본 URL을 입력해주어야 한다.

그래도 잘 안된다면, 톰캣 매니저 xml에서 manager-script권한이 추가되어 있는지 확인해본다. 

기존에는 테스트용도로 매번 Context Path을 pom.xml에서 변경해서 사용했었는데,

이건 아예 Context Path를 다르게 만들어서 Item을 미리 여러개 만들어놓으면,

더 확장이 쉬운 것 같다.

이걸로 pom.xml에 있는 tomcat7 deploy plugin은 지워버리는걸로... 

아무리 바꿔도 안바뀌길래, pom.xml 경로를 따라 들어가보니

Jenkins workspace폴더에 item기준으로 폴더가 나뉘어있고,

그 폴더 root에 존재했다.

maven project상에서 pom.xml을 바꾸어도 기존에 이미 파일이 있으면

간혹가다가 바꾸지 않는것 같다.. (좀 이상하긴하지만;;; 버그인듯)

1. 그럴땐 워크스페이스를 날리고, 다시 실행하면 반영이 된다.

2. Workspace Cleanup Plugin 이걸 설치해서 활용해도 된다.

ssh key 생성하고, user name, email등 다 입력했는데..

아래와 같은 에러가 발생하는 경우가 있다.

User testerJenkins has no capability to connect to Gerrit event stream.

이런 경우 Gerrit 관리자 계정으로 들어가서

Group Event Streaming Users에서 Trigger를 실행하고자 하는 계정을 추가를 해주면 된다.

그래도 안되는 경우.. 프로젝트쪽에서 권한이 막힌 경우인데

Global Capabilities카테고리의 Stream Events를 Allow 시켜주면 해결 된다.

이외의 에러는, ssh Key를 잘못 생성했거나, 비밀번호를 잘못입력한 경우로 보면 된다.

Jenkins를 Linux환경에 설치를 하고, 보통 scm에서 땡겨서 여러대의 Linux 머신에 배포를 할 때는

sshpass와 rsync만으로 충분히 가능하다.

하지만, Target서버가 Linux환경이 아닌 Windows환경의 경우, 일반적인 방법으로는 불가능하다.

그러던 중, SSAG에 글을 남겨서 Jenkins Slave라는 것이 있다는 것을 알게되고,

세팅을 시작하게 되었다.

Jenkins Master (Linux), Jenkins Slave (Windows) * n과 같이 구성을 하여,

1대의 Slave에서 돌아갈 Batch Script만 짜두면, 어디서 돌릴지 Slave를 선택하여 돌아갈 수 있게끔 해주는 유용한 기능이다.

이러한 환경 구성을 위해, 각 Slave에 Agent세팅을 필요로 한다.

Slave에는 사전에 Java가 설치되어 있어야 하며, Jenkins Master에서 Slave를 연결을 시킬 수가 있다.

[Jenkins 관리 - 노드관리] 메뉴로 진입하여 신규 노드버튼을 누르면 아래와 같은 화면이다.

중요한 부분 몇가지만 보고 넘어가면, 

Remote root directory는 Jenkins Slave의 Workspace와 Log 정보등이 저장되게 되는 디렉토리이며,

Launch method는 Launch slave agents via Java Web Start로 Java Web방식으로 슬레이브 에이전트를 띄우는 옵션이므로,

이 옵션으로 바꾸어 주고, 저장을 하고나면, 아래와 같은 화면이 나온다.

(어차피 가상환경 IP라서 그냥 공개했음)

순서대로 따라하면 된다.

Launch버튼을 눌러서 slave-agent.jnlp 파일을 받고,

파일을 받은 경로에 가서, Run from slave command line에 있는것을 cmd창을 열어서 그대로 실행하면,

Master에 연결이 되어, Master에서 컨트롤 가능한 상태가 된다.

Item생성 시에는 Multi-configuration project 타입으로 생성을 하면,

아래와 같이 Configuration Matrix옵션이 있는데, 여기서 어떤 Slave에서 돌아갈지에 대해서 설정이 가능하다.

이걸 몰랐을 때는, Windows에다가 openSSH도 깔아보고 freeSshd도 깔고, 별짓을 다했는데..

가장 간편하고, 깔끔하게 해결이 되었다.