Case #1. FAIL: httpd config references DNS name without associated gear: 'jbossews-nnoco.example.com'


위 테스트는 애플리케이션이 정상적으로 제거되지 않은 경우에 실패한다.

Step 1. cat /etc/httpd/conf.d/openshift/nodes.txt | grep jbossews-nnoco.example.com을 실행하여 해당 도메인과 연결된 기어의 UUID를 복사한다.
# cat /etc/httpd/conf.d/openshift/nodes.txt | grep jbossews-nnoco.example.com
jbossews-nnoco.example.com 127.12.146.130:8080|541fcc9e818cadf578000004|541fcc9e818cadf578000004
jbossews-nnoco.example.com/health HEALTH|541fcc9e818cadf578000004|541fcc9e818cadf578000004
jbossews-nnoco.example.com/haproxy-status 127.12.146.131:8080/|541fcc9e818cadf578000004|541fcc9e818cadf578000004

Step 2. oo-admin-gear destroygear --with-container-uuid 541fcc9e818cadf578000004 를 실행하여 정상적으로 제거되지 않은 기어를 제거한다.

# oo-admin-gear destroygear --with-container-uuid 541fcc9e818cadf578000004

Killing gear processes for name:541fcc9e818cadf578000004...

Deleting cgroup info...

Deleting stale info from /var/lib/openshift/.httpd.d/ files...

  for 541fcc9e818cadf578000004

  for jbossews-nnoco.example.com



참고 문서 : https://bugzilla.redhat.com/show_bug.cgi?id=1057727





AWS 상에 설치한 OpenShift의 브로커를 이중화하고, 잘 돌아가는 것을 확인하고, 대표님께서 보고 싶다고 하셔서 보여드리려고 했더니. 그때부터였다.

멀쩡히 돌아가고 MCollective Ping도 확인했을 때 잘 돌아가던 그놈이 배신을 했다.

OpenStack에 설치했던 Broker의 설정을 변경해서 AWS의 Node에도 연결을 해보고,

새로 Broker를 몇번이나 다시 설치해서 해보고, 설정값도 이리저리 바꾸어보고, 의심가는 것들을 모두 해보고 확인해봤지만 계속 안된다.


3일 째..

여전히 AWS의 문제는 해결이 되지 않아서 새로 클러스터를 구성하려다가 귀찮았던 바람에 Broker와 Node만 새로 설치하고, ActiveMQ와 MongoDB는 이전의 것을 그대로 두고 사용했다. 여전히 안된다. MongoDB 쪽에는 전혀 문제가 없다.

역시 Broker-ActiveMQ-Node 간의 통신 문제인데, 잘 되던 게 갑자기 안되니 도무지 이유를 모르겠고, 웬만한 트러블 슈팅을 다 할 수 있다고 자만하던 내게 벌을 내린게 아닌가 싶을 정도다.


그러다가 다시 오픈시프트 관련 메일링 리스트를 뒤져보다가

같은 문제의 제목을 찾았고, 전에 MCollective와 관련해서 한번 읽었던 글이지만 혹시나 하는 지푸라기라도 잡는 심정에 다시 천천히 읽어봤다.

그러다가 이 스레드에서 Brenton찡이 clock skew가 아니냐고 물어보길래 응? 설마 이것 때문에 그러려고.. 하다가 혹시나 싶어서 VM들의 시간을 확인해보니, Broker와 Node는 일치하지만 ActiveMQ는 2분 정도의 차이가 났다.

ActiveMQ가 설치된 서버에 ntpd를 설치하고 clock.redhat.com과 시간 동기화를 한 후 접속해보니 되는게 아닌가..!?


아.. 인생 무상.. 사람이 이렇게 미칠 수도 있겠구나 싶었다. 아니.. 안될거면 처음부터 안될 것이지 되다가 아니되냔 말이다. 하하.

이 문제 때문에 사흘을 버리긴 했지만.. 다시 돌아가니 다행이다. ㅠㅠ

'마음이 뛰다' 카테고리의 다른 글

연락처  (0) 2015.01.23
나름 다듬어 가기  (2) 2015.01.08
OpenShift Node 설정 중...  (0) 2014.09.18
새로운 영역의 공부  (0) 2014.07.25
Do you want to stay here?  (0) 2013.11.22

Comprehensive Deployment Guide를 따라서 OpenShift를 설치할 때 Node 설치 전 미리 설치해야 하는 패키지들

  • mlocate 설치

  • dbus 설치 - oddjobd가 통신을 하기 위해서 messagebus가 필요한데 dbus messagebus의 구현체이다.

  • nodejs 설치 - Javascript Runtime 프레임워크

  • rubygem-passenger

  • mod-passenger

  ruby193-mcollective 관련 트러블 슈팅

OpenShift Origin을 OpenStack 환경에서 설치하는 중에 각각의 컴포넌트들(Broker, Node, ActiveMQ, MongoDB)을 각각 VM에 설치하고 있는데, 항상 모두 완료한 후 oo-accept-node를 수행하면 아래와 같은 메시지와 함께 실패했다

# oo-accept-node
FAIL: service ruby193-mcollective not running
FAIL: Could not get SELinux context for ruby193-mcollective
2 ERRORS

그래서 facts.yml 파일에서 이상해 보이는 내용을 수정하고
ps aux | grep mcollective를 해보니 프로세스가 3개나 돌고 있길래 모두 종료 시그널을 보내 강제 종료하고, pid파일을 저장하는 run 디렉토리가 없어서 생성해준 후 서비스를 다시 실행했다.
# mkdir /opt/rh/ruby193/root/var/run
# service ruby193-mcollective start
# service ruby193-mcollective status
mcollectived is running (pid 32013)
헐.. 된다. 만세!


그러나 끝나지 않았다. 여전히 브로커에서 District에 추가하면 small profile을 갖는 노드를 찾을 수 없다고 나온다.


MCollective 설정 중에 가장 답답한 것은 서비스가 running이라고 해도, 이게 ActiveMQ와 연결이 되어있는지 안되어있는지, 메시지는 받고는 있는지, RPC 호출은 되는지 하는 부분이다. 이걸 도통 알 수가 없다.


oo-mco ping을 해보면 노드에 핑을 보내고 응답을 받지만, District에서 찾을 수 없는 것은 왜일까?

브로커는 RPC로 노드의 프로시져를 원격으로 수행하는데, 원격 프로시져 실행을 위한 메시지 풀(큐)로 ActiveMQ로 사용하고 Publisher/Subscriber 로 MCollective를 사용한다.

ActiveMQ의 Admin콘솔에서 큐의 내용을 확인해보면 브로커가 보낸 메시지는 있지만, 노드가 응답한 기록은 없다. ActiveMQ의 로그도 마찬가지였다.


그렇다면 노드의 MCollective 서버가 ActiveMQ에 연결되지 않았음을 의미하므로, 열심히 또 구글링을 하고 메일링 리스트를 뒤져보다가 MCollective의 설정 파일(/opt/rh/ruby193/root/etc/mcollective/server.cfg)의 내용을 다시 점검해보았는데, 설치 가이드에서는 찾을 수 없었던 설명을 볼 수 있었다.

direct_addressing 옵션의 값이 0으로 설정되어 있었는데 1로 바꾸어줘야했다.

설정값을 바꿔준 후 서비스를 재시작하고 브로커에서 oo-mco 스크립트를 이용해 확인해보니 정상적으로 메시지를 주고 받는 것을 확인할 수 있었다.


oo-mco rpc openshift echo msg="I_am_here"

Discovering hosts using the mc method for 2 second(s) .... 1


 * [ ============================================================> ] 1 / 1



osnode1.java2game.com                    

   Message: I_am_here

      Time: nil




Finished processing 1 / 1 hosts in 28.48 ms

# oo-mco facts node-profile -v

Discovering hosts using the mc method for 2 second(s) .... 1

Report for fact: node-profile



---- rpc stats ----

           Nodes: 1 / 1

     Pass / Fail: 1 / 0

      Start Time: 2014-09-22 07:20:26 +0100

  Discovery Time: 2034.33ms

      Agent Time: 47.55ms

      Total Time: 2081.88ms


그리고 다시 Small Gear Profile로 설정한 District에 노드를 추가했더니 드디어 됐다.

추가적으로 브로커와 노드의 MCollective 설정 시 유의 사항으로는 securityprovider와 plugin.psk의 값, username과 password가 동일해야 한다.



참고 자료

https://lists.openshift.redhat.com/openshift-archives/dev/2014-July/msg00215.html

https://docs.puppetlabs.com/mcollective/configure/server.html#directaddressing

https://lists.openshift.redhat.com/openshift-archives/users/2013-December/msg00077.html




  카트리지 설치 관련 트러블 슈팅

OpenShift 설치 후 실제로 애플리케이션을 생성하기 위해서는 카트리지가 필요하다. (애플리케이션을 생성할 때 기본 카트리지를 하나 이상 지정해야 하므로)

글을 쓰는 현재 OpenShift Origin의 릴리즈는 4이다. 그래서 Comprehensive Deployment Guide에서 처음에 설정하는 yum repos 파일의 baseurl도 release4이다.

카트리지 설치 시에 다른 것들은 문제없이 의존성 패키지들도 함께 잘 설치가 되지만 속을 썩이는 놈이 있다면 JBoss 카트리지 군이다. (Jekins 카트리지에서도 의존성 패키지 문제가 있긴 하지만 yum install jekins로 버전을 빼고 설치하면 된다)

  • openshift-origin-cartridge-jbosseap

  • openshift-origin-cartridge-jbossews

  • openshift-origin-cartridge-jbossas


위 카트리지들을 꼭 설치하지 않아도 상관은 없지만, 내가 자바 유저이기도 하거니와, 이 프로젝트에서 다른 회사가 테스트하기 위한 애플리케이션이 자바 웹 애플리케이션이라 JBoss 카트리지를 설치해야한다. 그런데 의존성 패키지들을 찾을 수 없어서 설치하지 못하는 게 문제.


또 열심히 구글링... 한 결과로 문제를 얘기하자면, Openshift Origin의 RPM Repository의 Dependencies의 내용이 다르다. 필요가 없어져서 다르다면 모를까 버전 업 된 Repository에서는 필요한 패키지들이 쏙쏙 빠져있다. maven3나 tomcat6, tomcat 7같은.. 조금 불편하지만 일일히 수동으로 해주었다.

Error: Package: ... 로 시작하는 Dependency 관련 에러 메시지가 뜨면, 해당 패키지를 수동으로 설치해주면 된다. 아래는 Maven3, Tomcat, JBoss AS의 RPM 주소이다.

yum install <주소> 를 실행하면 RPM을 다운로드 받아 설치를 진행한다.

  • Maven 3 : yum install https://mirror.openshift.com/pub/origin-server/release/3/rhel-6/dependencies/x86_64/maven3-3.0.3-4.noarch.rpm 
  • Tomcat 6 : yum install https://s3-us-west-2.amazonaws.com/getup-mirror/getup-openshift-origin-release-3/noarch/tomcat6-6.0.39-1.noarch.rpm 
  • Tomcat 7 yum install https://s3-us-west-2.amazonaws.com/getup-mirror/getup-openshift-origin-release-3/noarch/tomcat7-7.0.50-1.noarch.rpm 
  • JBoss AS : yum install https://s3-us-west-2.amazonaws.com/getup-mirror/getup-openshift-origin-release-3/noarch/jboss-as7-7.1.1.Final-1.noarch.rpm

# yum -y install https://mirror.openshift.com/pub/origin-server/release/3/rhel-6/dependencies/x86_64/maven3-3.0.3-4.noarch.rpm https://s3-us-west-2.amazonaws.com/getup-mirror/getup-openshift-origin-release-3/noarch/tomcat6-6.0.39-1.noarch.rpm https://s3-us-west-2.amazonaws.com/getup-mirror/getup-openshift-origin-release-3/noarch/tomcat7-7.0.50-1.noarch.rpm https://s3-us-west-2.amazonaws.com/getup-mirror/getup-openshift-origin-release-3/noarch/jboss-as7-7.1.1.Final-1.noarch.rpm https://mirror.openshift.com/pub/origin-server/release/3/rhel-6/dependencies/x86_64/jboss-as7-modules-7.1.1.Final-1.noarch.rpm


JBoss AS와 EWS는 이렇게 설치 할 수 있지만, EAP는 라이선스를 구매해서 사용해야 하는 듯 하다. AS와 EAP의 비교는 아래 글에 잘 나와있다.

http://opennaru.tistory.com/44


아래는 Openshift Origin Release 3의 Dependencies

https://mirror.openshift.com/pub/origin-server/release/3/rhel-6/dependencies/x86_64/



참고 자료

http://stackoverflow.com/questions/25729796/missing-jboss-tomcat-cartridge

http://stackoverflow.com/questions/25582773/how-can-i-install-jboss-eap-and-jboss-ews-support-in-openshift-origin

https://access.redhat.com/solutions/223043

https://lists.openshift.redhat.com/openshift-archives/dev/2014-July/msg00224.html



  10.6.1. Configuring SSH to Pass Through the GIT_SSH Environment Variable

Comprehensive Deployment Guide의 10.6.1. 항을 보면 아래와 같이 되어있다.

# cat <<EOF >> /etc/ssh/sshd_config

AcceptEnv GIT_SSH

EOF

그런데 이렇게 했을 때 설정 파일의 끝에 AcceptEnv GIT_SSH가 추가가 되긴 하지만 줄바꿈이 되지 않고 마지막 줄의 끝에 붙게 된다. 따라서 sshd_config 파일을 따로 수정하거나, 처음 추가할 때 줄바꿈을 추가해서 위의 명령을 수행해준다.

OpenShift Origin 프로젝트 목록을 살펴보려고 GitHub에 들어갔는데, origin이라는 못보던 저장소가 생성되어 있었다.

이건 뭔가 싶어 들어갔더니 README에  OpenShift Origin 3.0 이라고 떡하니 적혀있다.


!?


공식적으로 3.0 발표에 대한 내용을 다루고 있는 글은 OpenShift 블로그의 Announcing OpenShift Origin V3을 통해 공개되었는데, 이 기사는 2013년 12월 19일에 올라왔고, 저장소는 7월 30일에 생성된 것으로 보아 그 사이 적용 기술 검토와 설계를 하고, 이제 개발에 착수한 것 같다.


README.md 파일의 첫 부분을 보면 


This is the source repository for the next version of OpenShift - the third architectural revision. It is based around Docker containers and images and the Kubernetes container management solution.


OpenShift Origin은 Docker 컨테이너와 Kubernetes 컨테이너 관리 솔루션에 기반한다고 되어있다.

그동안 분석을 해오면서, Docker가 적용되어 있나? 없나?에 대한 고민이 많았는데, 다른 분들은 적용되어 있다고 하시고, 난 아무리 코드를 뒤져봐도 Gear 생성을 위한 Docker 코드를 확인할 수 없었기 때문이다.


GEARD 프로젝트야 Gear-Docker에 관한 프로젝트가 맞지만, 이 GEARD를 origin-server에서 사용하는 것을 본적이 없다. cgroups를 통해서 시스템 자원을 관리하는 거라면 모를까.


이 OpenShift Origin 3.0 저장소가 생성되기 전에 OpenShift 3 PEP가 있었는데, 여기에 나온 설계와 실제 코드가 너무 상이해서 뭔가 싶었는데, OpenShift Origin 3.0은 PEP를 토대로 개발이 진행된다고 한다.

OpenShift Origin의 버전이 명확히 공개된 문서가 없어서 이런 혼란스런 상황이 되지 않았나 싶다. 이제야 조각이 맞춰지는 느낌이다. 실제로 우리는 기존 OpenShift Origin Server의 브랜치 중에서 release 3, release 4 등의 릴리즈 번호를 보고 이게 버전이라고 추정했는데, 단지 릴리즈 번호로써의 숫자이지, 버전은 아니었던거다.


새로 3.0 버전의 개발이 시작되었지만, 우리가 분석하는 건 당연히 기존의 버전으로 진행한다.

다만 문제는 OpenShift의 강점으로 내세웠던 Docker를 이용한 컨테이너 기술인데, 이렇게 되면 헛분석한게 된다. 기존의 Gear컨테이너의 격리는 CGroups와 SELinux를 통해서 이루어지고 lib-virt를 통해서 관리된다.

OpenShift의 개발은 그쪽대로 진행이 되고 우리의 분석은 우리대로 진행이 될 것이지만, 그간의 분석이 소스코드를 중심으로 하지 않고, 노출된 문서들을 바탕으로 하다보니, 실제로 적용된 기술과 분석의 결과는 차이가 있을 수 밖에 없는 것 같다.

앞으로의 일정대로라면 분석을 위한 시간이 충분하진 않겠지만, 개인적으로라도 소스코드를 중심으로 좀 더 깊게 살펴봐야겠다.


+ Recent posts