Sentio, ergo sum

   웹(클라우드) IDE은 웹 환경, 즉 브라우저를 통해 인터페이스를 제공하는 통합 개발 환경입니다. 

로컬 PC에 IDE를 다운로드 받아 실행하지 않고 웹 브라우저를 통해 접속하여 해당 서비스에서 제공하는 환경을 통해 개발할 수 있습니다.

   지원하는 언어, 미들웨어, 데이터베이스 등의 종류와 기능은 각 서비스 별로 상이하지만 파일 브라우징, 버전 관리 연동, 편집기, 콘솔, 터미널 등의 기본적인 기능은 대동소이합니다.

   이 글에서는 상용 서비스와 오픈 소스로 공개된 웹 IDE에 대해 비교해보도록 하겠습니다. 이전에 웹 IDE를 분석했던 자료를 PT로 정리해뒀었는데, 묻어두긴 아까워 PT자료를 토대로 글로 옮겼습니다. 슬라이드 그대로 짜깁기한 부분도 있으니 너그러이 양해를 :D

※ PT 자료는 http://www.slideshare.net/ssusercef361/ide-60399120 에서 보시거나 다운로드 받으실 수 있습니다.

I. 주요 상용 웹 IDE

   이 중 NITROUS는 회원 가입 시 전화번호 인증이 필요한데 한국 번호(+82)로는 인증 문자가 발송되지 않는 건지 인증을 하지 못해서 테스트해보지 못했습니다 ;;

  상용 웹 IDE의 공통 기능

대부분의 서비스가 아래와 같은 기능을 제공합니다.

1. 프로젝트(파일) 관리/브라우징

   - 워크스페이스 제공

   - 언어/프레임워크별 프로젝트 템플릿 제공

   - 파일 업로드/다운로드

   - 프로젝트 내보내기/가져오기 (파일 또는 링크 형태의 공유)

2. 편집기(문법 검사, 코드 하이라이팅, 자동 완성 등)

3. 자동 저장 및 리비전(SCM과는 별도로 파일 자체의 리비전 관리)

4. 개발, 빌드 및 실행을 위한 VM이나 Container 제공

5. 협업 기능

   - 프로젝트 공유/프로젝트 멤버(팀) 관리

   - IDE 내 메신저 채널 제공

   - 동시 협업 코딩(구글 문서와 같은 동시 편집 기능)

6. 웹 기반 SSH 터미널 제공(대부분 sudo 명령어 지원)

7. 형상관리 시스템 연동(Git.Mercurial/SVN 또는 외부 서비스 e.g. Github)

8. UI 사용자화(Custumizing)

   - 창/탭 형태의 UX 제공

   - 창/탭 분할

   - 테마 사용자화

   개발/빌드/실행 환경에 있어서는 VM이나 Container 기반의 워크스페이스(또는 프로젝트)를 제공하며, 서비스에 따라서 실행 및 빌드 시에만 VM(Container)를 생성하는 경우도 있습니다. 또한 자체적으로 웹 애플리케이션 테스트를 할 수 있는 경우 Public URL을 제공하여 해당 URL을 통해 실행된 웹 애플리케이션을 확인할 수 있습니다.

   대부분의 경우 웹 IDE에서는 테스트 환경까지는 제공하지만 배포환경은 제공하지 않습니다. 즉 웹 IDE를 통해서 안정된 서비스를 운영하기는 아직까지 어려워보입니다.

웹 IDE에 따라서는 Cloud 서비스(IaaS/PaaS)와 연동하여 개발된 결과를 해당 서비스에 배포할 수 있도록 하는 기능도 제공합니다.

  Codenvy - https://codenvy.com/

Codenvy의 주요 특징

   - Docker 기반 컨테이너 제공

   - 프로젝트 실행 시에만 컨테이너(Runner) 동작

      - Runner가 동작중일 때 웹 SSH Terminal을 통해 접속가능

   - 웹 UI를 통한 데이터베이스 연동

   - 언어 지원 : C/C++, Javascript, Java, PHP, Python, Ruby

   - 템플릿 프로젝트 제공

   - 언어별 빌드툴에 대한 빌더 인터페이스 제공

   - 형상관리 제공(Git, Subversion)

   Codenvy를 통해 개발 시 소스코드 등의 프로젝트 파일은 서버의 파일 시스템으로만 관리되고, 테스트 시에는 Runner라는 실행환경을 제공합니다. Runner는 Docker를 통해 생성된 Container이며, 빌드 결과를 Runner에 업로드하여 Runner 환경 내에서 실행됩니다.

    Runner는 언어/프레임워크/웹서버/WAS 등에 따라 다양하게 제공되고 있으며 2015년 11월 기준으로 제공되는 Runner는 아래와 같습니다.

   또한 기본적으로 제공되는 Runner이외에도 현재의 Runner를 통해 Custom Runner를 구성하여 생성할 수 있습니다.

Codenvy 아키텍쳐

주요 화면 캡처

(전체 화면 스크린샷이라 잘 보이지 않습니다 ;; 자세한 화면은 슬라이드쉐어에 공유한 PT 자료를 참고해주세요)

기본 편집 화면

새 프로젝트 생성 - 언어별 템플릿 프로젝트 제공

러너 및 러너 속성 

러너 실행 시 콘솔을 통한 로그 확인

러너 접속을 위한 터미널

데이터베이스 연결 - 

데이터베이스(PostgreSQL, MySQL, Oracle, MS SQL, NuoDB) 가 설치된 URL을 직접 입력하거나

Google Cloud SQL, Amazon의 데이터베이스에 연결

  SourceLair

SourceLair의 주요 특징

   - 형상관리 시스템에 밀접하게 연동

      - 프로젝트 생성 시 형상관리 시스템을 먼저 선택하도록 되어있음

   - UI 상에서 Package Management 제공

      - npm, pip, bower 등

   - 개발용 데이터베이스 인스턴스 제공

   - Heroku 개발 특화

      - Heroku 앱 템플릿 제공(Heroku 용 Node, Django)

   - Linux 터미널 제공

   - 웹 서비스의 Public URL 제공

   - Sublime Text의 Command Palette와 유사한 기능 제공

   - HTML 라이브 프리뷰

   편집 기능에 있어서 강력한 기능을 많이 제공합니다. HTML 의 라이브 프리뷰도 그렇고, 자동 완성, 코드 폴딩 등의 기능을 제공합니다. 웹에서 웬만한 IDE의 편집기에 버금가는 기능을 갖췄다니 대단하네요.

   특이한 부분은 웹 UI 내에서 npm, pip와 같은 패키지 관리를 할 수 있단 부분인데요. 물론 다른 웹 IDE 들도 터미널을 통해 할 수 있지만 UI를 통해서 할 수 있는 건 SourceLair 밖에 없어 보입니다.

편집 화면 캡처

편집 화면 - 상단 메뉴 대신 왼쪽에 바 형태로 아이콘을 제공합니다. 편집기에서는 탭으로 파일을 구분하여 작업할 수 있습니다.

  Koding - http://www.koding.io

Koding 의 주요 특징

   - VM 기반 워크스페이스 제공 : VM에 대한 Public IP 제공

   - 편집기 위주의 화면 구성

   - 빌드, 테스트 등은 터미널을 통해 명령어/스크립트로 수행

   - 그림판(Drawing Board) 편집기 제공

   - 메신저(개인 Direct Message / 채널)

      - 채널의 경우 공개되어 있으며, 다른 사용자들과 의견 공유 가능

   - VM 관리

      - VM Spec, Disk Usage, Domain, VM Share, Snapshot 등 IaaS 주요 VM 관리 기능 제공

      - 외부 서비스의 VM 사용 가능 - 해당 VM에서 셋업 스크립트 실행을 통해 초기화

Koding의 경우 다른 서비스들과 달리 Koding을 위한 개발환경이 세팅된 VM을 통째로 제공해 줍니다. VM안의 파일 시스템을 사용하고 언어, 프레임워크, 데이터베이스 등을 설치하여 사용할 수 있습니다. 가장 자유도가 높은 웹 IDE 입니다.

또한 사용하는 IaaS가 있다면 그곳의 VM에 셋업 스크립트를 실행해서 Koding 에서 사용할 수 있도록 설정할 수 있습니다.

주요화면 스크린샷

편집 화면 - Drawing Board에 Hello World 써보기 (악필...)

VM 설정 화면

채널을 통한 커뮤니케이션

Direct Message

외부 VM을 추가하기

  codeanywhere - http://www..io

codeanywhere 의 주요 특징

   - 컨테이너, FTP/SFTP/SSH, Git, 스토리지 서비스로부터 프로젝트를 생성/파일 관리

      - 자체 제공 컨테이너 : 언어 및 프레임워크별 이미지 제공

      - Github/Bitbucket 연동 또는 Git URL 직접 입력

      - 3rd 파티 스토리지 서비스 : 아마존 S3, Dropbox. Google Drive

   - 프로젝트 템플릿은 제공하지 않음

   - 컨테이너의 언어(프레임워크) 스택에 따라 웹 서버 실행

   - 스택에 필요한 패키지 설치 후 커스텀 스택으로 저장 할 수 있음

   - 다른 사용자에게 프로젝트 공유 기능 지원

   - 프로젝트/컨테이너 등의 설정은 JSON 형식의 설정 파일을 직접 수정

   Codeanywhere은 프로젝트 생성 시 '연결'한다는 개념으로 접근합니다. 컨테이너에 연결, GitHub에 연결, SSH 서버에 연결.. 등 파일 시스템을 사용할 수 있는 시스템을 기반으로 하여 개발을 할 수 있도록 해두었습니다. 다만 컨테이너 이 외에는 통합 개발 환경을 제공하기 보다는 웹을 통한 파일 관리의 느낌이 더 드는..?

   컨테이너의 경우에는 '스택'이라는 개념으로 언어나 프레임워크 등을 관리할 수 있도록 되어있고, 개발자가 원하는 패키지를 설치한 후 커스텀 스택으로 저장하여 사용할 수 있습니다.

주요 화면 캡처

프로젝트 생성 (Connection Wizard)

컨테이너 연결 - OS 선택(Ubuntu / CentOS)

편집 화면 - 기본적인 IDE와 비슷한 구성(터미널 제공)

  Cloud9 - https://c9.io

Cloud9 의 주요 특징

   - 컨테이너 기반 개발 환경 제공

   - REPL(Javascript) 제공

   - WAS의 로그 콘솔 제공

   - 로컬 IDE와 유사한 수준의 디버깅 기능 제공

   - 컨테이너 리소스 모니터링 및 프로세스 관리 가능

   - HTML 페이지, 마크다운, 이미지 파일 등의 프리뷰 지원

Cloud9은 개인적으로 이름이 마음에 드는 서비스입니다. 이름이 갖는 의미 만큼의 개발 환경을 제공해 줄 수 있을지는 더 지켜봐야겠지만요..? (오래오래...?)

SourceLair의 경우에는 웹 UI 상에서 패키지 관리를 제공했다면, Cloud9은 컨테이너의 메모리, 디스크와 같은 리소스와 컨테이너에서 실행 중인 프로세스를 관리할 수 있는 기능을 제공합니다.

또 특이하게 REPL(Read Eval Print Loop, 인터프리터 언어의 대화형 쉘)을 제공하는데, 웹 브라우저의 개발자 도구를 활용해도 되긴 하지만 바로 사용할 수 있다는 점에서 편리하긴 하네요. 또한 높은 수준의 디버깅 기능을 제공합니다.

주요 화면 캡처

로그인 후 프로젝트 메인 화면, 사용률 및 README 파일 확인 가능

편집 화면 - 설정 파일 편집(JSON 형식), 오른쪽에는 디버거

프리뷰(Preview) 를 통한 확인

Rails의 출력 로그 확인(터미널과 별도로 제공)

  구름IDE - https://www.goorm.io

구름IDE의 주요 특징

   - 국내에서 개발된 웹 IDE

   - 컨테이너(Amazon EC2 Container) 기반 워크스페이스 제공

      - *.goorm.io / *.compute.amazonaws.com Public URL 제공

   - Java 교육용 컨텐츠(예제 및 템플릿) 제공

   - 로컬 IDE와 유사한 수준의 디버깅 기능 제공

   - Git/Subversion 연동 (다소 불안정)

   - 문서 뷰어 제공(Slideshare.net, PDF 파일)

   - 작업 내역(리비전) 기록 및 해당 리비전에 대한 작업 내역 재생 가능

   구름 IDE 는 국내에서 개발된 웹 IDE입니다. 해외의 주요 웹 IDE에 비해서는 아직 안정성이나 기능적인 면에서 조금 부족한 모습이 보입니다. Git이나 Subversion과 같은 버전 관리 시스템과의 연동은 불안정한 부분이 있구요.(연결이 되기도 했다가 안되었다가..)

   전반적인 기능으로 봤을 때는 실제 개발을 위한 IDE라기 보다는 교육용에 가까운 모습입니다. 프로젝트 생성 시 자바의 문법이나 특정 API와 관련된 샘플 템플릿을 제공한다거나, IDE 편집 화면 내에서 Slideshare.net의 링크나 컨테이너에 업로드한 PDF 파일을 볼 수 있는 뷰어를 제공합니다.

   구름 IDE 역시 Cloud 9과 비슷하게 로컬 IDE와 유사한 수준의 디버깅 기능을 제공합니다.

구름 IDE 아키텍처

주요 화면 캡처

로그인 후에 가상 머신(컨테이너)의 상태를 확인할 수 있습니다.

- 컨테이너를 실행 시켜야 편집 모드를 사용할 수 있습니다.

새 프로젝트 생성 - Java 프로젝트, 예제 프로젝트의 모습이 보입니다.

편집 화면 구성 - 브라우징, 편집기, 채팅, 쉘 등의 기능을 제공

문서 뷰어 - Slideshare.net의 링크를 입력하거나, PDF 파일을 열어서 내용을 볼 수 있음

문서 뷰어 - PDF 파일을 연 모습

II. 오픈소스 웹 IDE

  주요 오픈소스 웹 IDE

- Eclipse Che

- Eclipse Orion

- Eclipse Dirigible

- Eclipse Flux

- Codebox

- Codiad

위 목록에서 보다시피 Eclipse가 붙은 프로젝트가 네 가지가 있습니다. 이름대로 이클립스 재단에서 클라우드 환경에 맞는 IDE 개발을 위해 진행중인 ECD(Eclipse Cloud Development)에  포함된 네 개의 프로젝트입니다. 

http://www.eclipse.org/ecd 에 접속해 보시면 위 네 개의 프로젝트에 대한 소개와 링크를 제공합니다.

  Eclipse Che - http://www.eclipse/che

Eclipse Che 프로젝트는 상용 서비스인 Codenvy에서 이클립스 재단에 기여한 프로젝트입니다.

Codenvy의 UI를 포함하여 대부분의 기능을 제공하고 있습니다.

그러므로 Eclipse Che에 대한 설명은 생략하겠습니다. (...?)

  Eclipse Orion - https://orionhub.org/

오리온의 주요 특징은 아래와 같습니다. 

   - CloudFoundry와 연동 제공

   - 기본적인 수준의 편집 기능 제공

   - 외부 Git 서비스 연동

   - Shell 제공 (지정된 명령어만 사용 가능, 일반적인 터미널과 다름)

   - Public URL 제공

   - manifest.yml 편집 및 유효성 검사 기능 제공

manifest.yml 파일은 CloudFoundry에서 사용하는 애플리케이션의 설정 파일이며, 애플리케이션의 자원(메모리, 디스크), 서비스, 애플리케이션 속성 등을 관리하는 파일입니다.

Eclipse Orion 에서는 manifest.yml 파일을 직접 이용하여 애플리케이션에 대한 설정을 할 수 있도록 되어있으며, 편집기 자체에서 매니페스트 파일의 유효성을 검사합니다. 즉 CloudFoundry에 최적화된 모습을 보입니다. 컬러 테마 역시 CF와 같아 보이는군요. Pivotal 쪽과 관계가 있지 않을까 추측해 봅니다.

주요 화면 캡처

(작아서 잘 안보이지만..) manifest.yml 파일 편집

Git Repository 연동

Git Repository 연동 후 - 커밋 내역이나 파일을 탐색할 수 있습니다.

쉘 - help 명령어를 쳐서 나오는 명령어만 사용가능합니다.

라우팅 설정

라우팅 목록

Cloud Foundry 연동 - API/Manage URL을 입력하여 연동할 수 있습니다.

플러그인 목록 - CF이 외에도 이미지 뷰어 자바스크립트 툴 등의 다양한 플러그인을 제공합니다.

  Eclipse Dirigible - http://www.dirigible.io

Eclipse Dirigible의 주요 특징은 아래와 같습니다.

   - SAP에서 이클립스 재단에 기여

   - Perspective를 통한 화면 구성

      - Database, Debug, Generic, Registry, Repository, Workspace, Help

   - Sandbox를 통한 호스팅 제공

   - 데이터베이스 스키마 편집 모드(Perspective) 제공

   - Plugin Lazy Load

   - UI 구성이 일반적인 IDE와 차이가 있어서 러닝 커브가 있음

IDE로써의 다양한 기능을 제공합니다. 특히 데이터베이스 스키마 편집을 위한 Database 퍼스펙티브와 사용자들이 개발한 프로젝트를 등록하여 공유할 수 있는 Registry를 제공합니다. 이 두 가지 관점에서는 다른 IDE보다 우수하네요.

다만 Plugin Lazy Load 때문에 체감 속도는 더 느리게 느껴집니다. (매번 로딩...) 또한 전반적으로 UI 반응성이 떨어져서 사용성이 떨어지는 느낌입니다. 

주요 화면 캡처

메인 화면 - 기능별로 구분되어 있습니다만 써보기 전엔 이게 뭔지 잘 모를..

IDE 퍼스펙티브 - 로컬 IDE와 유사하게 잘 구성되어 있습니다. 구문 강조 등의 기본적인 편집기 기능을 제공합니다.

데이터베이스 퍼스펙티브 - MySQL 워크벤치처럼 스키마/테이블을 편집할 수 있습니다.

Registry - 사용자들이 등록한 프로젝트를 볼 수 있습니다. 공유된 걸 가져와서 테스트 해보려고 했으나 런타임 익셉션이..

List와 Generic - 정확하게 어떤 기능인지는 모르겠지만 프로퍼티 관리 기능으로 보입니다.

도움말

  Codebox - http://www.codebox.io

Codebox는 분석 전에 스크린샷이나 소개 글로 봤을 땐 개인적으로 괜찮아 보였는데... 테스트 서버에 회원가입 제한이 되어있더군요. (분석할 때는 작년 말이었는데, 지금도 보니 회원가입은 비활성화 되어있네요)

간략하게 특징을 살펴보면

   - Node.js 기반의 Apache 라이선스로 개발

   - Java, Python, Ruby, Go 등의 언어 지원

마지막 커밋이 글을 쓰는 현재(`16. 3. 31) 11개월 전인 것으로 보아 개발이 중지된 것으로 보입니다. (왠지 슬픔 ㅠㅠ)

편집 화면 캡처

사실 이 캡처의 모습이 서브라임과 유사해서 좋았었는데, 조금 아쉽네요.

  결론

   웹 IDE를 통해서 개발 시 소스코드나 리소스 등의 파일은 서버에 위치해 있고, 필요 시 로컬로부터 업로드하여 사용합니다. 물론 컴파일(빌드), 테스트, 배포 등의 작업 역시 서버 내에서 이루어집니다.

   화면으로 제공되는 것 이외에는 모든 작업이 서버에서 이루어지지만, 서버나 VM/Container에서 사용할 수 있는 기능이 모두 UI로 제공되지는 않습니다. 그걸 다 제공한다면 UI는 너무 복잡해 지겠지요.

이런 제한점을 해소할 수 있는 것은 웹 기반 SSH 터미널을 통해 필요한 것을 설치하거나 사용할 수 있습니다. 물론 SSH를 제공하지 않으면 UI로 제공하는 기능이 기능이자 제약이 되기도 합니다.

   속도 면에서는 서비스가 지원하는 성능 또는 과금 모델에 따라 속도 차이가 날 수 있으며, 인터페이스 및 편집기 기능을 제공하는 웹 브라우저에서는 일반적인 로컬 IDE보다는  속도가 느립니다.

네이티브 앱과 하이브리드 앱(또는 웹 앱)에서의 속도차이와 같은 개념으로 볼 수 있겠네요. 현재는 웹 IDE를 기반으로 실제 운영을 위한 서비스를 개발하라고 하면 당연히 무리가 있겠지만 속도, 기술, 기능 등의 면은 시간이 흐를 수록 발전되고 더 나은 사용자 경험을 제공할 수 있다고 봅니다.

   또한 웹 IDE는 클라우드 개발환경이 IaaS에서 PaaS로 점차 넘어가는 환경에서 이에 걸맞은 개발환경이 될 수 있다고 생각하기 때문에 PaaS와 웹 IDE는 유사한 수준으로 함께 발전할 것이라고 생각됩니다.

   개발 환경을 완전히 웹 IDE를 통해 구축할 수 있다면, 그야말로 언제든, 어디서든 개발할 수 있는 환경이 마련되겠네요 :)

※ http://www.slideshare.net/ssusercef361/ide-60399120 업로드 자료

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

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