Friday, March 27, 2015

AngularJS: $digest vs $apply vs $timeout vs $evalAsync 차이점 및 설명


 AngularJS (이하 Angular)Two-way binding이라는 편리한 기능을 제공하지만 이 기능을 사용할 때 몇 가지 어려운 점이 있습니다. 그 중에 하나가 Angular Context 외에서 들어오는 데이터를 모델에 업데이트를 할 때 (여기서 모델이란 $scope로 정의된 variable들을 이야기합니다. : $scope.data) 개발자가 인위적으로 업데이트를 해야하며 이 때 사용하는 것이 $digest, $apply, $timeout 또는 $evalAsync 입니다. 참고로 Angular Context (또는 Angular  Scope )Angular를 사용하지 않고 제작하는 모듈을 가리키며 가장 간단한 예로 서버를 들 수 있습니다. 서버에서 어떤 이벤트가 발생해서 Angular로 제작된 클라이언트 모듈 쪽으로 데이터가 들어오고 그 들어온 데이터를 UI에 반영하기 위해서 $scope.data에 업데이트를 해야 하는데 위에 언급한 함수들을 사용하지 않으면 클라이언트 모듈 쪽에는 데이터가 업데이트 되었지만 UI쪽인 HTML 쪽에는 (보통 {{data}} 형식으로 포함된) 업데이트가 되지 않아서 UI에 반영이 되지 않은채로 남아있습니다.

Two-way binding의 동작 원리
Two-way binding의 동작원리는 개발자가 $scope를 이용해서 variable을 생성하면 생성된 variable watcher가 생성되고 $apply()$digest()가 실행되었을 때 현재까지 생성된 모든 watcher들이 실행되어서 변화된 값을 업데이트합니다. 여기서 watcher란 할당된 variableold valuenew value를 비교하여 두 값이 다를 경우 old valuenew value로 업데이트해주는 모듈로 $scope.$watch 함수를 이용하여 이 작업을 합니다. UI쪽에서 발생하는 데이터값의 변화에 Two-way binding이 아무런 추가 작업 없이 정상 동작하는 이유는 AngularUI에서 발생하는 이벤트에 대해 $apply()를 자동으로 실행하기 때문입니다. 예를 들어 ng-click 같은 이벤트가 생성이 된다면 $apply()도 자동으로 실행이 됩니다.

$digest()
$digest()는 위의 동작원리에서 설명한 대로 현재까지 생성된 모든 $scope variable 들의 watcher를 실행하여 값이 변화된 variable의 값을 최신값으로 업데이트해주는 일을 합니다.
사용 예: $scope.digest();

$apply()
간단하게 설명하면 $apply() $rootScope.$digest()랑 같습니다. 하는 일은 $digest()와 같지만 다른 점은 커버하는 scope가 다르다는 점입니다. 다시 말해서 $digest()는 해당 scopevariable의 값들만 업데이트하지만 $apply()는 무조건 rootScoperootScope 밑에 있는 모든 child scope들의 variable들 값을 모두 업데이트하기 때문에 자주 사용하면 제품 전체의 성능/효율성을 저하 시킬 수 있습니다. 기본적으로 Angular$apply()의 사용을 추천하고 있지만 제 개인적인 의견으로는 만약 어떤 scopevariable이 업데이트 되어야 하는지 안다면 $digest()의 사용을 추천합니다.
사용 예: $scope.$apply(); 또는 $scope.$apply(function() { ….. } );

$timeout()
$timeout()은 일반적인 자바스크립의 APIsetTimeout()Angular 버전으로 $timeout()함수 안에서 바뀐 variable 값을 업데이트하기 위해 $apply()를 기본적으로 포함하고 있습니다. $timeout()은 보통 setTimeout()과 마찬가지로 얼마동안의 Delay 이후에 해당 코드를 실행하기 위해 사용되어지고 있는데 이 용도 이외에 ‘$digest already in progress’ 에러 발생에 대한 임시 해결책으로도 사용되어지고 있습니다. (DirectiveController 안에서 여러 번의 $apply()를 포함한 개발을 해본 개발자라면 최소한 한 번 이상은 저 에러 메세지를 본 경험이 있을겁니다.) ‘$digest already in progress’에러의 발생원인은 Angular는 기본적으로 한 번에 두 개의 $digest() 동시 실행을 금지하고 있어서 이미 $digest()가 실행 중일 때 또 다른 $digest()가 실행이 된다면 이 에러 메세지가 출력되고 나중에 실행된 $digest()는 실행이 되지 않습니다. 그럼 어떻게 $timeout()의 사용이 이 문제의 해결책이 될 수 있는건가요? 그 이유는 $timeout()$apply() 실행 타이밍 때문인데 $timeout()은 이미 기존에 실행되고 있는 $digest()가 있다면 그 실행이 끝날 때까지 기다렸다가 $timeout() 내부에 포함된 $scope.$apply()을 실행하는 특징이 있고 이 때문에 위의 에러에 대한 임시 해결책으로 사용되어 지고 있습니다.
사용 예: $timeout(function() {…….}, 0);

$evalAsync()
$evalAsync()‘$digest already in progress’에러에 대한 Angular팀의 근본적인 해결책으로 이해하시면 편합니다. (위에도 언급했듯이 $timeout()의 기본용도는 이 문제의 해결이 아닌 얼마간의 Delay이후에 실행이기 때문에 근본적인 해결책이 될 수는 없습니다. 또한 약간의 화면 깜빡이는 문제를 발생시킬 수도 있습니다.) $evalAsync()도 기본적으로 $apply() 함수를 포함하고 있으며 현재 진행중인 $digest()가 있을 경우에 이 $digest()의 실행이 끝나기 전에 $evalAsync()에 포함된 variable의 바뀐 데이터도 같이 업데이트할 수 있는 기능을 제공합니다. $evalAsync()AngularJS 1.2 버전부터 제공되어지고 있습니다.
사용 예: $scope.$evalAsync(function() {…….});

추가사항:
AngularJS 1.3 버전부터 $applyAsync() 함수가 추가 되었다고 합니다.  기본적인 기능은 $evalAsync()와 비슷하지만 효율성 면에서 아주 미세한 차이가 있다고 하는 것 같은데 필자는 사용 경험이 없어서 자세한 사항은 잘 모르겠습니다.

References

Wednesday, February 11, 2015

[NEWS] Node.js Foundation 출범


어제 있었던 Node Summit 2015 (2월 10일)의 마지막 세션이었던 'The future of Node.js'에서 Joyent의 CEO인 Scott Hammond가 Node.js Foundation의 출범을 선언했습니다. 그동안 Node.js 프로젝트는 Joyent가 메인으로 지원했었는데 그래서 폐쇄성과 새 릴리즈의 계속된 지연 등 여러가지 문제가 많이 있었습니다. (그래서 결국 초창기 핵심 개발자들의 주도하에 Node.js의 포크버전인 io.js가 작년에 나오게 되었습니다.)

아무튼 Joyent는 이런 여러가지 문제를 해결하고자 formal open governance 형태인 Node.js Foundation을 출범하기로 결정하였고 이 Foundation 멤버로는 Joyent를 포함해 IBM, Microsoft, PayPay, Fidelity, SAP 그리고 The Linux Foundation로 구성되었습니다. 또한 이 세션에서 앞으로 Node.js는 OpenStack과 비슷하게 두 가지 버전으로 출시할 예정이며 하나는 지금까지의 Node.js처럼 무료로 사용할 수 있는 오픈소스 버전으로 출시되며 이 버전을 Node.js Foundation가 지원할 예정이고 다른 버전은 몇 가지 기업용 기능이 추가된 유료 버전으로 Joyent가 이 버전을 지원/관리할 예정입니다. (즉 Rackspace가 OpenStack을 지원하는 방식처럼 오픈 소스도 지원하고 유료 버전을 따로 제작해서 지원하겠다는 의미입니다. 실질적으로 세션에서 이 내용을 이야기하면서 Rackspace가 오픈스택을 지원하는 모델을 따르겠다고 이야기하였습니다.)

출처: https://www.joyent.com/about/press/joyent-moves-to-establish-nodejs-foundation

Friday, January 9, 2015

앵귤러JS (AngularJS) 란?


앵귤러JS란
앵귤러JS (짧게 앵귤러라고도 합니다)는 MIT License로 무료로 배포되고 구글이 지원하고 있는 오픈 소스 웹 어플리케이션 프레임워크입니다. 앵귤러JS는 자바스크립트로 제작되었으며 기본적으로 MVC (Model-View-Controller) 모델 지원과 같은 다른 웹 어플리케이션 프레임워크에서도 지원하는 기능을 제공할 뿐만 아니라 Two-way data binding이나 directive 같은 새로운 개념의 기술도 지원하여 웹 개발자들이 해야할 많은 일들의 단축 및 좀더 파워풀하고 테스트가 용이한 웹 어플리케이션 제작에 도움이 되는 기능을 제공하고 있습니다. 아직 나온지 5년 정도 밖에 안된 프레임워크지만 구글의 전폭적인 지원 속에 다른 경쟁 프레임워크들이 비해 가장 빨리 커뮤니티가 성장하고 있는 프레임워크가 아닐까 생각합니다.

왜 사용하나요?
  • 체계적인 코드작성 지원: 개인적인 경험으로 JavaScript는 다른 프로그래밍 언어에 비해서 체계적으로 프로그래밍하기 어려운 언어인 것 같습니다. 그래서 프로젝트 사이즈가 커지면 금방 이해하기 힘들어지고 Debug가 어려워지는 Spaghetti Code가 되기 쉽습니다. 그렇지만 앵귤러같은 프레임워크를 사용하게 되면 이런 부분을 일정 부분 해소해줍니다. 
  • 앵귤러는 다른 프레임워크에 비교했을 때 아래와 같은 장점들을 가지고 있습니다. 
    • 구글의 지원 속에 개발자 커뮤니티가 가장 빠르게 성장하고 있고 앞으로도 성장 가능성이 큽니다. 
    • Two Way Data-Binding: 앵귤러가 제공하는 여러가지 기능 중 가장 유용한 기능이 이 Two Way Data-Binding 일 것입니다. 이 기능에 대해서 간단하게 이야기하면 Model과 View에서 사용되고 있는 데이터를 연결해줘서 어느 한쪽에서 이 데이터 값이 변화하면 다른 쪽에도 바로 업데이트가 되도록 해주는 기능입니다. 보통 이 기능 구현을 위한 코드가 전체 프로젝트의 80% 정도를 차지한다고 하는데 앵귤러는 기본적으로 이 기능을 제공하기 때문에 많은 코드의 반복을 피할 수 있습니다.
    • Dependency Injection 기능을 기본적으로 지원하기 때문에 컴포넌트들 간의 서비스 사용 및 Dependency 관리가 용이하며 각각의 컴포넌트들이 Decoupling (코드상에서 밀접하게 연관되어 있지 않음)되어 있기 때문에 테스트 하기가 쉽습니다. Dependency Injection에 대한 좀더 자세한 사항은 저의 다른 블로그 글인 'Dependency Injection이란'을 참고하시기 바랍니다. 
    • Directives: 앵귤러는 Directives를 제공함으로써 개발자가 자신의 용도에 맞게 HTML tag를 제작하여 사용할 수 있게 하였으며 DOM attributes도 수정 가능하게 하였습니다.


출처:
위키피디아: http://en.wikipedia.org/wiki/AngularJS
사이트포인트: http://www.sitepoint.com/10-reasons-use-angularjs/

Saturday, November 29, 2014

스프링 프레임워크 (Spring Framework)란?


스프링 프레임워크란?
스프링 프레임워크는 Pivotal Software에서 아파치 라이센스(무료 라이센스) 형태로 제공하는 오픈 소스 프로젝트로 자바 어플리케이션 (Standalone 과 웹 어플리케이션 모두 포함)개발에 필요한 여러 가지 서비스를 제공하는 프레임워크입니다. 현재 미국에서 자바로 어플리케이션을 개발하는 많은 회사들이 스프링 프레임워크를 사용 중이며 대한민국 공공기관의 웹 서비스 개발 시 사용을 권장하고 있는 전자정부 표준프레임워크의 기반 기술로도 쓰이고 있습니다.

왜 사용하나요?
1. 오픈소스 프로젝트: 다른 블로그에서도 여러 번 강조했지만 많은 회사들이 오픈 소스를 자사의 개발에 포함하는 이유는 라이센스 비용이 따로 들지 않기 때문입니다.
2. 다양한 기능 지원: 프로그램을 개발할 때 프레임워크를 사용하는 가장 큰 이유 중에 하나는 불필요한 반복을 없애고 업무의 양을 최소화하기 때문이 아닐까 싶습니다. 스프링 프레임워크는 엔터프라이즈용 프로그램을 개발하는데 관련해서 대부분의 기능을 제공하고 있으며 이 프레임워크를 사용하면 개발자들은 자사의 제품에 특화된 비지니스 로직만 추가하면 되기 때문에 많은 시간 및 개발비의 절약을 할 수 있습니다. 또한 많은 부분을 간단한 XML 설정이나 어노테이션으로 대신 할 수 있기 때문에 실제 코딩하는 소스코드의 양을 획기적으로 줄일 수 있습니다. 
3. 다양한 방식 지원: 스프링 프레임워크는 한 가지 컴포넌트에 대한 지원도 다양한 방식으로 하고 있습니다. 예를 들어서 DB 연결 같은 경우에도 Hibernate과 같은 모듈과 연동해서 여러 종류의 JDBC를 약간의 설정만 하면 사용할 수 있게 지원하고 있습니다. 이 점은 하나의 소스코드로 다양한 DB를 사용할 수 있게 해주기 때문에 큰 장점이 됩니다.
4. Dependency Injection: 스프링은 기본적으로 Dependency Injection을 지원하기 때문에 모듈들이 타이트하게 연결되어 있지 않으며 그래서 테스트가 용이한 프로그램을 만들 수 있습니다. (특히 유닛 테스트)

5. ETC: 그 외에도 스프링은 메세징, MVC, 테스팅, AOP 등 다양한 서비스를 기본적으로 제공합니다.

사용시 어려운 점 또는 단점
1. 스프링은 지원하는 기술의 양이 방대하고 같은 기술도 여러 가지 다른 방식으로 지원하기 때문에 처음 접하는 엔지니어들에게는 사용하기 힘든 프레임워크입니다.
2. 스프링은 비교적 무거운 프레임워크이기 때문에 이 프레임워크의 추가 만으로 어플리케이션을 상당히 무겁게 만들 수 있습니다. 

참고로 구글이나 애플 같은 큰 소프트웨어팀을 보유하고 있는 회사 같은 경우에는 자사에서 자체 개발한 프레임워크를 사용하고 있으며 보통 스프링 프레임워크와 비슷하거나 더 많은 기능을 제공하고 있다고 합니다. 그렇지만 사용 방식이나 개념에는 큰 차이는 없다고 합니다. 

출처
1. 위키피디아: http://en.wikipedia.org/wiki/Spring_Framework
2. 스프링 프레임워크 메인 페이지: http://projects.spring.io/spring-framework/

Tuesday, November 11, 2014

Dependency Injection (의존성 주입)이란?

Dependency Injection이란?
Dependency Injection이란 객체 또는 구성 요소간의 종속관계를 소스코드로 설정하지 않고 외부의 설정파일을 통해서 주입하도록 하는 디자인 패턴으로 주로 알려져 있는데요 쉽게 이야기하면 한 객체 안에 다른 객체가 사용되면 두 객체 간에 종속관계가 생기는 것이고 다른 객체를 포함한 객체를 생성하려면 포함된 객체가 미리 생성이 되어 있거나 그렇지 않을 경우 자동으로 생성을 해줘야 하는데 이 부분을 따로 코딩하지 않고 외부의 설정 파일을 통해서 설정해둬서 Dependency Injection 기능을 제공하는 프레임워크 (예를 들어 Spring 같은)에서 자동으로 생성하게 하는 기술입니다.

왜 사용하나요?
Dependency Injection을 사용하는 가장 큰 이유는 아래와 같습니다.
1. Loosely coupled: Dependency Injection는 보통 서비스 또는 인터페이스 개념과 같이 사용이 되는데요 한 객체를 다른 객체에 포함할 때 클래스 형태로 포함시키는게 아니라 인터페이스 형식으로 포함을 시키기 때문에 외부 설정파일이나 스프링 프레임워크 같은 경우에는 어노테이션 값의 변화를 통해 다양한 서비스를 사용할 수 있습니다. 위의 설명한 내용에 대해서 아래에 예를 참조하세요.

예1 - 클래스 형태로 포함시키는 경우 (Java)
public class Foo {
    .....
}

public class Poo {
   private Foo foo  = new Foo();
}

예2 - 인터페이스 형태로 포함시키는 경우 (Java)
public Interface FooService {
   .....
}

public class FooServiceImpl implements FooService {
   .....
}

public class Poo {
  private FooService fooServ;
}

2. Testability: Dependency Injection을 사용하게 되면 위에 설명한 것처럼 객체 간의 관계가 느슨해지기 때문에 유닛 테스트와 같은 테스트를 작성하기가 수월해집니다. 위의 두번 째 예처럼 다른 객체에 포함된 인터페이스 형태의 서비스 같은 경우에 Mock를 하여 유닛테스트를 작성하게 되면 그 서비스와 상관없이 작동가능한 테스트를 만들 수 있습니다.

마지막으로...
Dependency Injection은 단순히 그 의미나 사용 방법을 이해하려고 하기 보다는 왜 사용이 되는지를 파악해야 이해하기가 쉽습니다. 또한 같이 사용되고 있는 서비스의 개념과 왜 서비스의 형태로 사용되어야 하는지 등을 이해해야 좀더 이해하기가 쉬운 기술입니다.

출처:
http://ko.wikipedia.org/wiki/%EC%9D%98%EC%A1%B4%EC%84%B1_%EC%A3%BC%EC%9E%85

Friday, October 10, 2014

오픈스택(OpenStack)이란?


오픈스택이란?

오픈스택은 오픈소스 클라우드 컴퓨팅 소프트웨어로 2010년 나사와 랙스페이스 (Rackspace)의 공동프로젝트로 시작되었고 현재는 오픈스택 재단에서 운영되고 있습니다. 오픈스택은 현재 HP, AT&T, Intel과 우리 나라 기업 중 삼성과 KT등 많은 대기업들의 지원을 받고 있으며 2014년 10월 현재 408개의 회사 그리고 18,813명의 개발자가 개발에 참여하고 있는 전 세계에서 가장 큰 오픈 소스 커뮤니티를 보유하고 있는 클라우드 프로젝트입니다. 오픈스택 소프트웨어는 하나의 소프트웨어가 아닌 여러 개의 소프트웨어(또는 컴포넌트)로 구성이 되어 있는데 다음 파트에서 각각의 소프트웨어에 대해 좀더 상세히 다루도록 하겠습니다. 오픈스택은 현재 6개월 단위로 새 버전을 출시하고 있으며 매 버전마다 프로젝트 이름 (또는 릴리즈명)이 있는데 현재 가장 최근 버전의 프로젝트 이름은 지난 4월에 나온 아이스하우스(IceHouse)이며 이달 중순에 새 버전인 주노(Juno)가 출시 예정입니다.

오픈스택의 구성 및 구성원 각각의 정보
위에 언급한 것처럼 오픈스택은 여러 개의 컴포넌트로 구성이 되어있는데 2014년 10월 현재 총 10개의 컴포넌트가 정식으로 오픈되어 있으며 각각의 컴포넌트에 대한 간략한 설명은 아래와 같습니다. (*괄호 안의 이름은 해당 컴포넌트에 대한 프로젝트 이름입니다.)
  • Compute (Nova): 컴퓨트는 오픈스택 시스템에 연결된 하이퍼바이저에 행하는 모든 행위 (예를 들어 VM의 생성 또는 삭제)를 시행/ 관리하는 역할을 하는 사실 상 오픈스택에서 가장 중요한 역할을 하는 컴포넌트입니다. 
  • Dashboard (Horizon): 대쉬보드는 오픈스택 시스템 관리자를 위한 Web UI이며 관리자는 이 UI를 통해 오픈스택을 관리할 수 있습니다.
  • Object Storage (Swift): 오픈스택은 두가지 타입의 스토리지 서비스를 제공하는 그 중에 하나인 Object Storage 스위프트입니다. 오브젝트 스토리지에 대해 간략하게 설명하면 데이터를 오브젝트 단위로 저장하는 방식입니다.
  • Block Storage (Cinder): Swift와 함께 오픈스택이 제공하는 또 다른 스토리지 서비스는 Block Storage - Cinder 입니다. 이 스토리지 서비스는 우리가 일반적으로 사용하는 컴퓨터의 하드디스크에서 사용되고 있는 방식으로 데이터를 블록 단위로 저장하는 방식입니다.
  • Networking (Neutron): 네트워킹 서비스인 Neutron은 오픈스택 내의 IP address들과 네트워킹을 관리하는 기능을 제공하는 컴포넌트입니다.
  • Identity Service (Keystone): 아이덴티티 서비스는 오픈스택 내의 Authentication과 Authorization 기능을 제공하는 컴포넌트입니다.
  • Image Service (Glance): 이미지 서비스는 VM으로 생성될 이미지 파일들을 관리하는 기능을 제공하는 컴포넌트입니다. 이미지 서비스를 이용하게 되면 자주 생성하는 VM 같은 경우에 매번 이미지 파일을 업로드하지 않고 업로드한 이미지 파일을 템블릿처럼 사용할 수 있습니다.
  • Telemetry (Ceilometer): 텔레메트리는 사용자의 사용량을 측정해서 알려주는 기능을 제공하는 컴포넌트로 서비스 프로바이더 회사들에게 유용한 기능을 제공하는 컴포넌트입니다.
  • Orchestration (Heat): 오케스트레이션은 미리 작성된 스크립트와 준비된 템플릿을 이용해서 자동으로 개발 인프라를 구축할 수 있는 기능을 제공하는 컴포넌트입니다.
  • Database Service (Trove): 데이터 베이스 서비스는 이름 그대로 오픈스택 시스템 상에서 데이터 베이스 서비스를 구축할 수 있게 도와주는 기능을 제공하는 컴포턴트입니다.

왜 사용하나요?
많은 기업들이 오픈스택 사용을 결정하는 가장 큰 이유는 아래와 같습니다.
  • Open Source: 아무래도 가장 큰 장점 중에 하나가 바로 라이센스 비용없이 무료로 사용할 수 있는 오픈소스라는 점일 것입니다.
  • 거대한 커뮤니티: 위에 언급한 대로 오픈스택은 현재 많은 회사와 개인 개발자들이 참여/기여하고 있는 프로젝트이기 때문에 지속적으로 업데이트가 되고 있고 앞으로도 발전 가능성이 큰 프로젝트입니다. (반대로 커뮤니티가 작은 경우에는 중간에 프로젝트 자체가 중단이 되거나 버그가 발생했을 때 해결책이 빠르게 업데이트가 되지 않아서 직접 문제를 해결해야하는 일들이 발생할 수 있기 때문에 실제 제품화 할 때는 큰 문제가 될 수 있습니다.)
  • 다양한 하이퍼바이저 지원: 오픈스택은 다양한 하이퍼바이저(ESXi, Hyper-V, KVM, Xen 등)들을 지원하기 때문에 오픈스택을 사용해서 여러 다른 종류의 하아퍼바이저가 설치된 호스트들을 연결/관리할 수 있는 시스템을 제작할 수 있는 이점이 있습니다. 
그렇지만 위와 같은 장점에도 불구하고 아직까지 오픈스택은 많은 회사들이 사용에 어려움을 표현하고 있으며 아래는 오픈스택 사용시 어려운 점 또는 개선해야 할 점입니다.
  • 아직 완성되지 않은 서비스: 이제 출범한지 4년 정도 밖에 안된 프로젝트이고 오픈 소스 프로젝트이기 때문에 아직 부족한 기능이 많고 프로젝트가 컴포넌트 단위로 진행이 되기 때문에 이미 구축된 시스템도 하나의 컴포넌트에 문제가 발생했을 때 시스템 전체에 문제가 생기는 등 아직 전반적으로 불안정한 상태입니다. 
  • 시스템 구축의 어려움: 제대로된 오픈스택 시스템의 구축을 위해서는 클라우드 관련 다양한 지식 뿐만 아니라 네트워크나 시스템 관련 많은 경험/지식이 필요합니다. 또한 문제 발생 시 진단할 수 있는 API의 제공도 아직 부족하기 때문에 문제 해결에 많은 어려움이 있습니다.  
  • 협력업체와의 애매한 포지션으로 인해 생기는 문제점 (예:VMware, Citrix) 오픈스택 프로젝트를 지원하는 가장 큰 업체 중에 하나인 VMware는 협력업체이자 경쟁사이고 이런 애매한 포지션 때문에 전폭적인 지원을 받지 못하는 편입니다.
  • 체계적이지 못한 문서: 오픈스택 웹사이트에서 많은 문서들을 지원하고 있지 못하나 겹치는 부분도 많고 체계적이지 못 한 것이 사실입니다. 
이상 오픈스택에 대해 간략하게 정리해봤습니다. 혹시 잘못된 정보가 있거나 부족한 점이 있다면 글 남겨주세요. 나중에 시간이 된다면 간단한 오픈스택 시스템을 구축하는 과정에 대한 블로그를 작성해서 올리도록 하겠습니다.

Hope this helps!

Thursday, October 9, 2014

Jenkins에 SonarQube 연동

이번 블로그에서는 지난 번에 설치한 Jenkins에 SonarQube 설정을 해서 두 시스템을 연동해서 사용하는 방법에 대해서 설명하도록 하겠습니다.

연동하기 전에 필요한 것
  • Jenkins 서버
  • SonarQube
Jenkins에 SonarQube를 설정하기 위한 과정
  • Jenkins의 메인 웹 UI 접속
    • 웹브라우저를 통해 Jenkins의 메인 웹 UI 페이지로 갑니다. (예: http://[ipaddress]:8080)
  • Sonar 플로그인을 Jenkins에 설치
    • 메인 UI 페이지의 왼쪽에 있는 'Manage Jenkins' 링크를 클릭해서 'Manage' 페이지로 이동한 후 아래 그림과 같이 오른쪽에 있는 'Manage Plugins'을 클릭해서 플러그인들을 관리할 수 있는 페이지로 이동합니다. 
    • 'Manage Plugins' 페이지에서 우선 'Installed' 탭에 나열되어 있는 이미 설치된 플러그인들 리스트에서 'Sonar Plugin'이란 항목이 있는지 확인하시고 (만약 Jenkins가 최근 버전이 아닐 경우에는 'Jenkins Sonar Plugin'이란 이름으로 되어 있을 수도 있습니다.) 만약 없다면 'Available' 탭으로 이동해서 'Sonar Plugin'을 찾으신 후 설치하시면 됩니다.
  • JDK 설정 (이 부분은 Jenkins에 JDK설정이 안 되어 있을 경우에만 해당됩니다.)
    • 'Sonar Plugin' 설치가 끝나면 다시 위의 스크린샷에 있는 'Manage Jenkins' 페이지로 이동한 후 가장 위에 있는 항목인 'Configure System'을 클릭하여 Jenkins의 설정 페이지로 이동합니다. 
    • 설정 페이지에서 'JDK' 항목을 찾은 후에 'Add JDK' 버튼을 클릭해서 JDK 정보를 추가합니다. 
    • 버튼 클릭 후에 생기는 'Name'과 'JAVA_HOME' 부분을 현재 Jenkins가 설치된 리눅스 시스템의 환경 정보를 참조해서 기입하신 후에 'Install automatically' 항목을 클릭하시어 자동으로 설치되지 않도록 합니다. 
    • 위의 사항을 마치셨으면 'Apply' 버튼을 클릭해서 변경사항을 적용합니다. 아래는 위의 사항에 대한 스크린샷이며 기입된 정보는 저의 Jenkins가 설치된 리눅스 시스템의 환경정보이므로 하나의 예로 참고만 하세요. 

  • Sonar 설정
    • Sonar 설정을 위해 다시 위와 같이 'Manage Jenkins -> Configure System'을 통해 설정 페이지로 이동합니다. 
    • 이번에는 'Sonar' 부분을 찾아서 'Add Sonar' 버튼을 클릭합니다. 
    • 자신의 SonarQube 설정 정보를 이용해서 해당 사항을 입력한 후 'Apply' 버튼을 클릭하여 Sonar와의 연동에 필요한 정보를 업데이트합니다. 아래의 스크린샷을 참고하세요. (Server URL 부분과 Database URL 부분에 삭제된 부분은 현재 로컬에 설치된 SonarQube IP 주소를 대신 기입하시면 됩니다. 예: http://10.10.10.10:9000)

  •   Maven 설정 (이 부분 역시 추가적인 사항이며 만약 필요시에만 설정하시면 됩니다.)
    • 위의 설정 화면에서 Maven 부분을 찾은 후 'Add Maven' 버튼을 클릭합니다. 
    • Maven Name 부분을 본인이 원하는 이름으로 기입한후 'Apply' 버튼을 클릭합니다. 'Install Automatically' 부분은 클릭이 된 채로 두셔도 됩니다. 
 Hope this help!