Sentio, ergo sum

현재 진행 중인 프로젝트에서 오픈 소스를 분석해서 설계서를 역으로 만들고 있는데(클래스 설계서),

약 400여개의 클래스를 손수 MS 워드 문서로 옮겨야 하니 노가다의 절정이라고 생각된다..

R&D 사업이니 설계 산출물 자체에 의미가 있다기보다는 예산에 대한 증빙 자료인 셈이다.

각론하고, 다행히 오픈 소스가 Java로 작성되어 있어 리플렉션으로 클래스 정보를 읽은 후 HTML 문서로 출력하고,

워드로 옮기면 되겠다. 라고 생각하고 작업을 했는데, 메서드의 파라미터 이름을 가지고 올 수 없었다.

이 문제를 해결하기 위한 방법을 두 가지 찾았는데, 하나는 Java 8의 리플렉션에 추가된 Method.getParamter()를 통해 얻은 파라미터 정보에서 getName()을 이용해 파라미터의 이름을 알아내는 것이고,

두 번째는 Java Parser를 이용하는 것이었다.

수작업을 줄이려고 시작한 건데 일이 커지기 시작했다.

거기에 더해 오픈소스를 분석한다는 의미는 사라지고 설계서를 만든다는 것만 남았다. (...)

Java Parser로 테스트를 해 보기 전에 잠시 Java 8에서 테스트를 해보았는데, 파라미터 이름이 arg0 과 같이 실제 이름이 아닌 컴파일러에서 치환된 이름으로 변환되어 나와서 더 찾아보지 않고 Java Parser로 테스트를 했다.

Java Parser를 이용할 때는 원하는 대로 파라미터를 출력할 수는 있었지만, 구조화된 타입이 아닌 파라미터 선언부의 문자열로만 값을 가져올 수 있었고, 한 가지 문제점으로는 public void test(/*Param1*/String param) 과 같은 메서드 선언에서 주석을 같이 읽어오게 되어 예외 케이스에 대한 처리가 복잡해질 것 같아서 다시 Java 8 리플렉션을 통해 파라미터 이름을 얻어올 수 있는 방법을 찾아보게 되었다.

검색을 하면서 하나 놓친 것이 있었는데, 자바 컴파일 옵션에서 -parameters 옵션을 주면 메서드 파라미터의 이름이 그대로 컴파일 된 바이트코드에서도 유지된다.

Eclipse에서도 아래와 같이

Store information about method parameters (usable via reflection) 체크박스에 체크하면 파라미터 옵션을 줄 수 있다. (Java 1.8로 컴파일러가 설정된 경우에 활성화된다)

파라미터 이름을 얻는 소스코드는 아래와 같다.

이 외에도 paranamer라는 라이브러리가 있었지만, 매뉴얼을 대강 읽어보니 Java8에 추가되었다고 노트되어있었다.

참고 자료

https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html

https://github.com/javaparser/javaparser

http://stackoverflow.com/questions/2237803/can-i-obtain-method-parameter-name-using-java-reflection

덧붙여,

이 작업을 하고 있는 둘은 한 명은 클래스 명세표 양식을 출력하는 웹 애플리케이션을 만들고 있고, 한 명은 클래스를 리플렉션해서 필요한 메타데이터를 뽑아내는 툴을 만들고 있다. 이쯤 되면 배보다 배꼽의 배꼽 수준인 듯 ㅋㅋ

이니시스의 로그가 깨져 나오길래 PuTTY의 인코딩이 잘못 설정되었나 싶어, 원격 쉘의 인코딩과 설정을 동일하게 하기 위해서 찾아보았다.

터미널은 환경 변수를 통해 문자 인코딩을 설정하기 때문에 해당 환경 변수를 출력해보면 된다.

혹은 locale 명령을 통해 확인할 수 있다.

출처 : http://stackoverflow.com/questions/5306153/how-to-get-terminals-character-encoding

간단하게 배치 파일을 작성할 일이 있어서 작성 중에 echo에서 줄바꿈, 혹은 공백 라인 출력을 하려고

@echo 도 해보고

@echo \n

@echo 공백

@echo ㄱ+한자+9 도 해보았으나 되지 않아 검색해보니

@echo text & echo.next line 이 정답.

도대체 추측할 수조차 없는 줄바꿈 방법이었다.

출처 : http://stackoverflow.com/questions/132799/how-can-you-echo-a-newline-in-batch-files

OpenPaaS 프로젝트에서 형상관리는 GitHub로, CI툴은 Travis-CI를 사용하기로 결정되어 개발환경 구성을 위한 설정을 진행 중입니다. 기존에 회사에서 쓰던 CI툴은 Jenkins였는데, 사용법이나 워크플로우, 화면 구성 등이 다르다보니 새로이 파악해야하는 부분들이 있어 정리하게 되었습니다.

 Travis-CI

Travis-CI는 루비로 작성된 오픈 소스 기반의 CI로, 분산 CI 호스팅 서비스를 제공합니다.무료로 사용할 수 있는 travis-ci.org와 프로 버전인 travis-ci.com으로 서비스하고 있습니다.

GitHub 아이디를 통해 가입하고, 해당 아이디의 프로젝트를 연결하여 테스트, 빌드 및 배포를 수행할 수 있습니다.

GitHub 아이디를 통해 가입한 후에 접근 권한이 있는 저장소를 읽어와서 연결하게 되고, 프로젝트(저장소)별로 빌드 수행 여부를 설정할 수 있습니다.

Travis-CI를 통해 빌드하기 위해서는 저장소의 루트에 .YAML 포맷으로 작성한 travis.yml 파일이 있어야 하며 .travis.xml 파일을 통해 설정을 관리합니다.

저장소를 연결하여 빌드를 활성화하면 해당 저장소의 Web Hook에 자동으로 Travis-CI 웹 훅이 등록됩니다. 로컬에서 작업한 후 원격 저장소인 GitHub로 커밋하면 웹 훅을 호출하여 자동으로 Travis-CI를 통해 빌드를 진행합니다.

현재 지원하는 언어로는

• C
• C++
• Cloujure
• C#
• D
• Dart
• Erlang
• F#
• Go
• Groovy
• Haskell
• Java
• Javascript (Node.js)
• Julia
• Objective-C
• Perl
• PHP
• Python
• R
• Ruby
• Rust
• Scala
• Visual Basic

이렇게 23개 언어를 지원하고 있습니다. 각 언어의 특성에 맞는 빌드 설정을 설정 파일인 .travis.yml 파일 내에 작성하여 프로젝트를 빌드하거나 배포할 수 있습니다. 예를 들어 자바의 경우에는 Maven, Gradle, Ant를 지원하고 프로젝트에 맞게 선택하여 적용할 수 있으며, Oracle JDK 7, Open JDK 6과 같이 JDK의 버전을 선택할 수 있고, 커스텀 스크립트를 통해 JDK8이 필요한 경우 JDK 6이 필요한 경우를 나누어 작업을 진행할 수도 있습니다.

Travis-CI를 사용하기 위한 간단한 순서입니다.

1. 회원 가입

Travis CI를 사용하기 위해서는 GitHub 계정을 통해 가입하게 됩니다. Travis CI 홈페이지에서 가입할 수 있으며

GitHub의 과금 정책과 유사하게 http://www.travis-ci.org 에서는 공개된 저장소(Public repository)만 사용할 수 있고, 비공개 저장소(Private repository)를 사용하기 위해서는 프로버전인 http://www.travis-ci.com에서 유료로 사용할 수 있습니다.

프로 버전에서는 플랜에 따라 병렬로 진행할 수 있는 작업(Job)의 수가 달라지며 플랜은 아래와 같습니다.

(Open Source 라고 표시되어 있는 부분이 travis-ci.org 입니다)

https://travis-ci.com/plans

GitHub 계정을 통해 가입하게 되면 저장소에 대한 접근 권한을 허용할 수 있는 페이지가 나타납니다. 여기서 원하는 저장소에 대해 접근 권한을 설정한 후 가입을 완료하게 되고, 추후에 GitHub의 계정 설정 페이지에서 수정할 수 있습니다.

2. GitHub 웹 훅 확성화

로컬에서 작업 후 GitHub로 푸시하게 되면 웹 훅을 통해서 Travis CI에서 자동으로 해당 커밋에 대한 빌드를 수행할 수 있도록 GitHub에서 저장소에 웹 훅을 추가해주어야 합니다. 저장소 설정에서 웹 훅을 추가하기 위해서는 해당 저장소의 설정을 수정할 수 있는 관리자 권한이 있어야 합니다.

웹 훅 설정은 GitHub에서 저장소로 이동한 후 저장소 세팅 페이지에서 "Webhooks & Services" 메뉴를 선택하여 설정할 수 있으며 혹시 Travis CI 서비스가 자동으로 추가되지 않았다면 추가해주면 됩니다.

(저는 웹 훅 활성화가 자동으로 설정이 되어있어서 따로 손 댈 부분은 없었네요.)

3. 저장소에 .travis.yml 파일 추가

Travis CI에서 프로젝트를 빌드하기 위해서는 저장소의 루트에 .travis.yml 파일을 추가해주어야 합니다. 

만약 .travis.yml 파일이 없거나 유효하지 않은 경우에는 Travis CI는 해당 프로젝트를 Ruby언어로 작성되었다고 간주하고 기본값으로 빌드를 수행하게 됩니다. Travis CI의 문서 페이지를 통해 언어별로 상세한 옵션을 확인할 수 있습니다.

제가 테스트를 위해 작성한 .travis.yml 파일은 아래와 같습니다.

언어는 Java로 되어있고, JDK는 oraclejdk7을 사용하며, 빌드가 성공적으로 완료된 후에(after_success) ls -la ./target 명령을 수행하고, 배포는 Openshift로 하도록 설정한 모습입니다.

참고로 Travis CI에서는 환경변수 설정을 지원합니다. 테스트로 사용하는 GitHub의 저장소는 Public인지라 .travis.yml 파일도 노출이 되는데 처음에는 아무 생각없이 오픈시프트의 password를 적으려고 하다가 공개된다는 걸 깨닫고는 Travis CI에서 지원하는 저장소 자체의 환경 변수를 이용해 패스워드를 설정했습니다. (오픈시프트로 배포하는 경우에 인증을 위해 Token을 사용할 수도 있지만 아직은 지원이 되지 않는다고 하네요)

위와 같이 .travis.yml 파일을 저장소 루트에 저장하고, 커밋하면 제가 테스트로 수행한 경우에는 Maven으로 빌드 관리를 하고 있으므로 Travis CI에서 루트에 있는 pom.xml 파일을 자동으로 탐지하여 Maven을 이용해 빌드를 수행하게 됩니다.

4. GitHub 저장소로 푸시하여 빌드 수행

.travis.yml 파일을 추가해준 후 처음으로 로컬에서 GitHub로 푸시하면 Travis CI의 빌드 큐에 작업이 추가되고, 언어에 따라 사용가능한 워커가 선택되어 빌드를 수행하게 됩니다.

Travis CI의 문서에서는 Travis CI에서의 프로젝트 첫 빌드 수행시에는 GitHub의 테스트 훅 버튼을 사용하지 말라고 되어있네요.

5. 빌드 설정 수정

프로젝트의 성격에 따라 빌드 설정을 수정해 줍니다. 예를 들어 테스트를 수행하기 전에 데이터베이스를 생성하거나 기본 설정과 다르게 빌드를 구성하여 수행할 수 있습니다.

빌드 설정 커스터마이징에 대한 내용은 Travis CI 문서의 customize your build나 how to install dependencies for your project 에서 확인하실 수 있습니다.

빌드 설정을 수정한 후에는 travis-lint 명령을 통해 올바른 YAML 포맷으로 작성되었는지 확인해 주시면 됩니다.

이 후에 필요한 추가적인 정보는 Travis CI의 문서 페이지에서 확인하실 수 있습니다.

프로젝트의 언어나 빌드 툴에 따라 문서 페이지에서 설정을 확인하여 적용하여 사용하시면 되겠네요.

(추가적으로 Travis CI를 사용하면서 테스트한 Deploy에 관한 설정이나 Travis CI의 Build Lifecyle 등에 대한 내용을 추가적으로 포스팅할 예정입니다.)

※ 참고 자료

• Wikipedia Travis-CI http://en.wikipedia.org/wiki/Travis_CI
• Travis-CI Getting Started http://docs.travis-ci.com/user/getting-started/
• Travis-CI Build Environment : http://docs.travis-ci.com/user/ci-environment

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

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

OpenShift 안정성 테스트를 위해 Broker Host를 이중화하는 작업을 진행했다. 실제로 서비스되는 서버를 구성해 본 적이 없는 까닭에 이것 저것 찾아보고 관련된 책을 읽어보면서 진행했다. 역시 최대의 장벽은 영어... 여담으로 이 프로젝트를 하면서 새로이 배우는 것들이 참 많다. 학교에서 이론 수업으로 배웠던 것들도 되새기는 것들도 많고, 다만 그때 열심히 하지 않았던 게 후회되긴 한다.

OpenShift 설치를 위해서는 매뉴얼 설치, oo-installer, VM 이미지, Puppet으로 배포하는 방법이 있고, 여기에서는 매뉴얼 설치(OpenShift Comprehensive Deployment Guide)를 참고하여 설치했다.

기존에 하나의 OpenShift 클러스터가 있으므로, 여기에서는 하나의 Broker를 추가적으로 구성하고, 로드 밸런서로는 HAProxy를 사용한다.

 VM 구성

  VM 환경 정보

OpenShift 구성은 OpenStack 환경에서 진행되었다. 작업 내용에 포함된 HAProxy 서버와 Broker 서버의 구성을 적어두었다.

HAProxy

  Ubuntu 14.04 LTS, HAProxy 1.5.5

Broker

  CentOS 5.4, BIND9.8

  Broker 1(기존 브로커, DNS Server(BIND) 설치) / Private IP : 30.30.0.1

  Broker 2(새로 설치할 브로커) / Private IP : 30.30.0.2

DNS 설정

  Key 파일 복사

rsync 키 복사

편의를 위해서 Broker 1에서 생성한 rsync용 대칭키를 Broker 2로 복사한다. 파일 복사를 위해 따로 툴은 사용하지 않고 cat 명령을 통해 출력되는 파일의 내용을 Copy & Paste 했다.

Broker 1에서 아래와 같이 실행하면 Private Key 파일인 rsync_id_rsa와 Public Key 파일인 rsync_id_rsa.pub 를 출력한다.

Broker 2에서 아래와 같이 Broker 1의 키 파일 내용을 복사하여 붙여넣은 후 파일을 생성한다.

authorized_keys 파일에 Public Key를 추가한 이유는 Broker 1에서 Broker 2로 추가적으로 복사할 파일이 있기 때문에 scp를 사용하기 위해서다.

DNS 키 복사

Broker 1의 DNS 서버를 설정할 때 사용한 키파일을 Broker 2로 복사한다. OpenShift는 애플리케이션을 생성하면 애플리케이션에 접근하기 위한 도메인을 추가하며, app_name-domain.example.com과 같은 형식이다. Broker 1의 DNS 업데이트를 위해서 동일한 키가 필요하므로 키를 복사해야한다.

Broker 2에는 BIND를 설치하지 않았으므로 /var/named 디렉토리를 먼저 생성한 후 파일을 복사한다.

Broker 1에서 scp로 키 파일을 복사한다. example.com은 도메인으로 설정한 주소이므로 자신의 설정에 맞는 알맞은 주소를 넣어준다. 가이드를 따라 변경없이 진행했다면 example.com 일 것이다.

추가적으로 Broker 2 /etc/resolv.conf 의 nameserver 값은 Broker 1의 IP로 수정하고, DHCP 설정 과정에서의 DNS 값 역시 Broker 1의 IP로 값을 설정한다.

  ruby193-mcollective-client 설정 파일 복사

Node와의 통신을 위해 사용하는 Mcollective Client를 설치한 후에 이어 진행할 Comprehensive Deployment Guide의 5.2.절 Configuration에서 Mcollective client 설정 파일은 Broker 1의 설정 파일을 그대로 복사한다.

Broker 1에서 아래의 명령을 수행한다.

  Access Keys, 브로커 설정파일 복사

설치 가이드의 6.3.절 Generate Access Keys는 수행하지 않고 Broker 1의 파일을 복사하면 된다. Broker 1에서 아래의 명령을 수행

  DNS 플러그인 설정

7.2.절 Configure the DNS plugin의 과정이다. 브로커 내부에서 nsupdate 명령을 사용하여 DNS를 업데이트할 때 /etc/openshift/plugins.d/openshift-origin-dns-nsupdate.conf 파일의 설정을 읽어와서 사용하게 된다. Broker 1과 설정 값을 동일하게 설정하고, BIND_SERVER의 값을 Broker 1의 IP로 설정한다.

OpenShift Console 설치 후 SSL 설정 없애기

HAProxy 설치 후 HAProxy에서 SSL 설정 시 Broker의 SSL 설정과 충돌하여 접속할 수 없으므로 HAProxy에만 SSL을 적용하고, Broker에서는 80포트로 서비스를 제공하도록 한다. 

Broker 1과 2모두 /etc/httpd/conf.d/000002_openshift_origin_broker_proxy.conf 파일을 아래와 같이 수정한다.

  HA Proxy 설치 및 설정

HAProxy에 SSL을 적용하려면 패키지로 설치하지 않고 소스를 빌드해야한다. (1.4 버전에서는 그랬다고 하는데, 1.5 버전부터는 어떠한지 모르겠으나, 이 글에서는 동일하게 1.5.5 버전을 사용하여 소스 빌드를 했다.)

-- 작성 중..

참고 도서

1. 카츠마 료 외 웹 서비스 개발 철저공략 (BJ Public)

2. 이토 나오야 외 저 서버/인프라를 지탱하는 기술 (제이펍)

참고 자료

1. OpenShift Comprehensive Deployment Guide

2. HAProxy Configuration Manual

3. HAProxy TCP Port Forwarding

4. HAProxy Subdomain Redirect

5. HAProxy URL Pattern Forwarding

6. How can I make haproxy route requests based on URL substrings?

7. L4/L7 스위치의 대안, 오픈소스 로드밸런서 HAProxy

8. BIND9로 업그레이드 하기: 알아야 할 9가지 특성

9. [BIND] master,slave nameserver 구축

10. DNS Sample BIND Configurations

리눅스에서 curl로 JSON을 받았을 때 Pretty Print가 되어있지 않으면 참 읽기 난감하다.

내용을 복사해서 JSON Viewer로 옮겨서 봐도 되지만 매번 그렇게 하기에는 번거로운 일이기도 해서 "cli json pretty print"을 키워드로 구글링하니 편한 방법을 찾을 수 있었다.

파이썬 2.6 이상이 설치되어 있다면 아래와 같이 커맨드를 실행시키면 된다.

그럼 위의 출력 결과처럼 보기 좋게 나온다.

참고 자료

http://stackoverflow.com/questions/352098/how-can-i-pretty-print-json

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를 수행하면 아래와 같은 메시지와 함께 실패했다

그러나 끝나지 않았다. 여전히 브로커에서 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 스크립트를 이용해 확인해보니 정상적으로 메시지를 주고 받는 것을 확인할 수 있었다.

그리고 다시 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

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. 항을 보면 아래와 같이 되어있다.

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

OpenShift Node 호스트 설치입니다. OpenShift Origin Comprehensive Deployment Guide를 참고하여 설치하였습니다.

OpenShift 설치 전 필요한 것들

OpenShift Origin을 설치하려면 아래 서비스를 네트워크에서 사용할 수 있어야 합니다.

DNS

MongoDB

ActiveMQ

또한 호스트(Broker, Node)에는 아래 클라이언트가 설치되어 있어야 합니다.

NTP

MCollective

1. 필수사항: 호스트 시스템 준비

이 항목은 Broker와 Node 호스트를 위해 필요한 절차입니다.

1.1 OpenShift Origin 저장소 설정

openshift-dependencies RPM 저장소 설정

cat <<EOF> /etc/yum.repos.d/openshift-origin-deps.repo
[openshift-origin-deps]
name=openshift-origin-deps
baseurl=https://mirror.openshift.com/pub/origin-server/release/4/rhel-6/dependencies/x86_64/
gpgcheck=0
enabled=1 

파일 생성 확인

openshift-origin RPM 저장소 설정

파일 생성 확인

1.1.1. EPEL 저장소

최신 버전의 epel-release 패키지를 설치합니다. 최신 버전의 epel-release의 RPM 파일 경로는 http://download.fedoraproject.org/pub/epel/6/i386/repoview/epel-release.html 에서 확인할 수 있습니다.

설치 결과

/etc/yum.repos.d/epel.repo 파일 수정

아래 파란색으로 표시한 부분을 추가해줍니다.

1.1.2. "옵션" 저장소 설정 (RHEL 환경에서만 적용됩니다.)

"Optional" 저장소를 사용가능하도록 설정합니다.

yum-config-manager가 없는 경우 설치해줍니다.

1.2. 업데이트 및 NTP

1.2.1. 방화벽 설치

firewalld를 삭제하고 대신 방화벽 규칙 관리를 위해서 lokkit을 사용합니다.

! Trouble Shooting

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

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

!?

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

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

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

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