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!

Sunday, October 5, 2014

[잡담] 실리콘밸리에서의 생활 - 장점과 단점





아래는 지난 5년간의 실리콘 밸리 삶의 경험에 근거해 작성한 글, 잡담입니다.

장점:

  1. Software Engineer로서...
    1. 구직 또는 이직이 편하다. 특히 미국 경제 상태가 좋은 요즘 같은 경우에는...
    2. 소프트웨어 엔지니어에 대한 대우도 좋고 작업 환경도 너무 좋습니다. 보통 10시 반 또는 11시 출근해서 바쁜 정도에 따라 5시에서 6시 쯤 퇴근. (상사가 퇴근을 했든 안 했든)
    3. 미국 내의 다른 지역에 비해 외국인(인도인, 중국인 등)이 많다 보니 아무래도 다른 지역에 비해 영어에 대한 스트레스가 좀 덜 합니다. 
    4. 비슷한 일을 하는 사람들이 많기 때문에 인맥 쌓기도 좋고 자기 개발 및 성장에도 도움이 많이 됩니다. 
    5. 한국과 달리 엔지니어로서의 정년이 길기 때문에 오랜 기간 일을 할 수 있습니다.
  2. 생활 관련해서...
    1. 겨울에 잠시 비오는 걸 제외하고 일년 내내 맑은 날씨와 따뜻한 온도가 유지 됩니다. 특히 필자를 포함한 운동을 좋아하는 사람들한테는 이 점이 큰 장점중 하나입니다.
    2. 한국에 비해 싸고 신선한 과일들 (코스트코에서 바나나 한 다발에 2천원, 큰 수박 한 통에 6천원 - 7천원 정도) - 물론 품목마다 다를 수는 있지만 보편적으로...
    3. 산, 바다, 호수 등과 가까운 접근성 및 관련 레포츠 가능 - 이 부분은 정말 미국의 다른 지역 특히 중부나 동부 쪽에서는 이런 조건을 모두 갖춘 지역을 찾기 힘듭니다.
    4. 미국 내 다른 지역에 비해 높은 학구열과 좋은 평점의 학교가 많아서 자녀 교육에 좋습니다. (너무 경쟁이 심해 단점이 될 수도 있지만...)
    5. 도시 내에 나무가 많고 공원도 많은 편입니다. 
단점:
  1. Software Engineer로서...
    1. 아무래도 영어가 미국 사람이나 인도 사람들보다는 유창하지 못한 외국인이다보니 승진에 한계가 있거나 어려움이 있습니다. (물론 본인의 노력 여하에 따라 바뀔 수 있는 부분이기는 하지만 여기서 이야기하는 것은 보편적인 어려움을 이야기 하는 것입니다.)
    2. 항상 경쟁해야 하고 항상 공부해야 합니다. 실리콘 밸리는 인력을 구하는 회사도 많지만 그만큼 엔지니어들도 많기 때문에 엔지니어로 살아남기 위해서는 치열한 경쟁을 해야하며 특히 IT관련 기술들은 너무나도 빠르게 변하고 있기 때문에 계속 해서 공부를 하지 않으면 결국 뒤쳐지고 도태되게 됩니다. 특히 실리콘밸리는 미국의 다른 지역에 비해 변화가 더 빠른 편이기 때문에 더 많은 노력을 해야 하는 것 같습니다. 
  2. 생활 관련해서...
    1. 살인적인 물가 (특히 집값). 사실 일반 생활용품의 물가나 기름값 같은 경우에는 다른 지역에 비해 큰 차이가 없거나 조금 더 비싸지만 다른 지역에 비해 많이 받는 연봉으로 충분히 커버가 가능합니다. 그렇지만 집값은 월등히 비싸기 때문에 이 지역 사는 사람들 대부분의 걱정거리가 아닐까 생각합니다. 물론 기형적으로 비싼 서울 (특히 강남)에 비하면 싸거나 비슷하기 때문에 뭐가 그렇게 비싼가 할수도 있겠지만 미국에 있는 다른 지역의 집값에 비하면 월등히 비싸고 집 자체도 많이 낡은 편입니다. 
    2. 대중 교통의 부재: 버스가 있지만 노선이 지극히 제한적이고 택시는 상당히 비싼 편이기 때문에 기본적으로 차를 가지고 다녀야 하고 이 때문에 밖에서 음주를 하고 집에 오기가 부담스러운 편입니다. (대리도 있다고 들었는데 가격이 상당히 비싸다고 합니다.)
    3. 한국 음식: 미국의 다른 규모가 작은 도시에 비해서는 그래도 한국 식당이나 상점들이 많은 편이지만 그래도 맛있는 한국 음식점들이 많이 부족합니다. 
이상으로 필자가 경험하고 주변 사람에게 들은 내용을 기반으로 작성한 실리콘밸리 생활 관련 허접한 블로그였습니다. 

Friday, October 3, 2014

ESXi, vCenter, vSphere란?


VMware 제품들을 이용한 가상화 관련 작업을 할 때 가장 먼저 부딪치는 문제가 바로 여러 가지 새로운 개념들과 용어들 그리고 다양한 VMware 제품군들일 것입니다. (최소한 필자는 그랬습니다.) 그래서 이번 포스트에는 VMware의 엔터프라이즈 버전에서 가장 많이 사용되고 있는 제품들 (ESXi, vCenter, vSphere)의 개념과 차이점에 대해서 알아보도록 하겠습니다. 참고로 필자는 이 분야의 Expert가 아니기 때문에 아래의 정보는 필자의 경험을 바탕으로한 정보이며 부족한 부분이나 잘못된 정보가 있으면 글을 남겨주세요.

ESXi란?
ESXi는 VMware에서 나온 하이퍼바이저(Hypervisor)입니다. 하이퍼바이저란 쉽게 이야기하면 가상화 환경을 만들 수 있도록 최소한의 기능만을 지원하는 축소버전의 OS (윈도우즈나 리눅스 같은)라고 이해하시면 편할텐데요 (가상화 환경을 만드는데 소프트웨어의 도움없이 하드웨어를 그냥 사용할 수 없으니까요) Configuration과 시스템을 Manage할 수 있는 약간의 기능을 제외하고는 다른 기능들을 지원하고 있지 않습니다. (예를 들어서 GUI라던가…) 하이퍼바이저는 두 종류가 있는데 (Type 1과 Type 2) ESXi는 Type 1 하이퍼바이저입니다. 다른 회사에서 나온 경쟁 제품으로 Microsoft에서 나온 Hyper-V와 Citrix에서 나온 XenServer가 있습니다.

vCenter란?
가상화 환경을 만드는 가장 큰 이유는 여러 컴퓨터를 하나의 큰 성능/용량의 컴퓨터처럼 사용하기 위함인데 그 기능을 지원하는 것이 vCenter입니다. 다시 말해서 vCenter는 가상화 환경 구축을 위한 핵심 소프트웨어로 ESXi가 설치된 다수의 머신을 하나의 가상화 환경으로 만들어주는 기능을 제공합니다. 가상화 시스템 운영자의 입장에서 vCenter를 이용하면 여러 ESXi 호스트들을 쉽게 추가/제거할 수 있으며 그 외에도 아래와 같은 엔터프라이즈 기능들을 제공합니다.
  • vMotion: 현재 사용 중인 VM (Virtual Machine)을 VM의 전원을 끄지 않은 상태에서 다른 호스트로 (서버) 이동할 수 있게 해주는 기능
  • DRS (Distributed Resource Scheduler) & DPM (Distributed Power Management): VM의 컴퓨터 리소스 사용 (CPU나 메모리)을 계속 체크하고 경우에 따라 VM을 다른 호스트로 이동하거나 VM의 할당이 되지 않아서 아무런 일을 하지 않는 호스트의 경우 전원을 잠시 꺼두고 필요 시 다시 전원을 키는 등의 리소스 관리를 도와주는 기능

vSphere란?
vSphere란 위에 언급한 소프트웨어들을 전부 포함하고 있는 소프트웨어 Suite 또는 패키지를 일컬으며 위의 소프트웨어 외에도 다른 많은 소프트웨어를 포함하고 있습니다. (예를 들어 vSphere Client 또는 vSphere SDKs) 마이크로소프트 제품인 Office랑 비교하면 vSphere는 Office와 같은 개념이고 ESXi나 vCenter는 Word나 Excel이라고 이해하면 됩니다.

설치 및 라이센스에 대한 간략한 정보
대부분의 VMware 제품은 VMware 웹사이트(https://my.vmware.com/web/vmware/downloads)에서 무료로 다운로드 받아서 설치할 수 있으며 ESXi 같은 경우에는 무료 버전도 있기 때문에 무료로 다운 받아서 사용 가능합니다. 그렇지만 vCenter 라이센스는 유료이며 가격도 비싼 편입니다. (상당 부분의 VMware 영업이익이 vCenter 라이센스에서 발생된다고 들었습니다.) 사실 ESXi는 단순한 하이퍼바이저이기 때문에 무료로 배포를 한다고 해도 vCenter가 없으면 가상화 환경을 만들 수 없기 때문에 이런 사업 모델을 사용하는게 어떻게 보면 당연하다고 생각하며 이런 점 때문에 OpenStack 같은 오픈 소스 클라우드 플랫폼에 상당히 많은 사람들이 관심을 갖는게 아닌가 생각합니다. (OpenStack은 vCenter를 대체할 수 있는 오픈소스 프로젝트로 만약 OpenStack을 사용할 경우 vCenter 라이센스 없이 ESXi 호스트를 이용해서 가상화 환경 구축이 가능합니다. OpenStack 또한 하나의 큰 주제이기 때문에 나중에 시간이 된다면 따로 블로그를 작성해서 올리도록 하겠습니다.)  VMware 제품을 이용한 가상화 환경 구축을 위한 간단한 절차는 아래와 같습니다.
  1. 가상화 환경에 사용될 컴퓨터들에 ESXi 설치
  2. vCenter를 지원하는 OS (위에 언급한 컴퓨터와 다른 컴퓨터)에 vCenter를 설치. 각 버전마다 지원하는 OS가 다르기 때문에 VMware 웹사이트(http://www.vmware.com/resources/compatibility/search.php)를 참고해야 합니다.
  3. vSphere Client (또는 vSphere Web Client)를 통해서 vCenter에 접속해서 ESXi 호스트들을 추가/관리
사실 위의 과정들을 간략하게 소개했지만 각각의 과정들은 많은 세부 과정들을 포함하고 있습니다. 특히 vCenter 설치 같은 경우에는 다양한 방법들이 있고 약간 복잡한 면도 있기 때문에 나중에 시간이 된다면 따로 블로그를 작성해서 올리도록 하겠습니다.

Source (출처)
  • http://www.mustbegeek.com/difference-between-vsphere-esxi-and-vcenter/
  • http://www.vmware.com/products/vcenter-server/features
Hope this helps!

Friday, September 26, 2014

TURN 서버 설치

TURN 서버란?
TURN 서버는 Traversal Using Relays around NAT의 줄임말로 간단히 이야기 하자면 미디어 스트림을 Relay하는 Relay Server입니다. TURN 서버는 STUN 서버와 같이 WebRTC 어플리케이션에서 Firewall/NAT 문제를 해결할 때 사용되며 TURN 서버의 프로토콜에 대한 자세한 사항은 RFC 5766에 기술되어 있으니 참조바랍니다. (http://tools.ietf.org/html/rfc5766)

  • TURN 서버 설치 전에 필요한 것
    • CentOS 6.5 (64-bit)가 설치된 시스템 (또는 VM)
    • 최신 버전의 'libevent' 라이브러리 다운로드, 빌드, 인스톨
      • Download libevent from its github: https://github.com/libevent/libevent
      • tar xvfz libevent-[latest-version].tar.gz
      • cd libevent-[latest-verstion]
      • ./configure
      • make
      • make install 
  • TURN 서버 다운로드
    • 웹사이트: https://code.google.com/p/rfc5766-turn-server/wiki/newDownloadsSite?tm=2
    • 예: turnserver-3.2.3.94-CentOS6.5-x86_64.tar.gz (이 블로그에서는 이 패키지를 사용해서 설명하겠습니다.)

  • TURN 서버 빌드와 인스톨
    • 다운로드 받은 패키지를 '/opt' 폴더로 이동 후 압축해제
      •  mv turnserver-3.2.3.94-CentOS6.5-x86-64.tar.gz /opt
      • tar xvfz turnserver-3.2.3.94-CentOS6.5-x86-64.tar.gz
    • 압축을 푼 패키지의 폴더로 이동한 후 TURN 서버를 인스톨
      • cd turnserver-3.2.3.94-CentOS6.5-x86-64
      • ./install.sh
  • Long term credential 정보 추가
    • '/etc/turnserver/' 폴더에 생성된 'turnuserdb.conf' 파일에 'long term credential' (긴 기간 인증) 정보를 추가 (아래의 turnuserdb.conf 예 참조)
  • TURN 서버 시작
    • TURN 서버를 아래와 같은 옵션과 함께 시작
      • turnserver -v -a -r -n --userdb=/etc/turnserver/turnuserdb.conf
  • Sources
  • turnuserdb.conf의 예

#This file can be used as user accounts storage for long-term credentials 
#mechanism.
#
#username1:key1
#username2:key2
# OR:
Isley:abcd1234
#username1:password1
#username2:password2
#
# Keys must be generated by turnadmin utility. The key value depends
# on user name, realm, and password:
#
# Example:
# $ turnadmin -k -u ninefingers -r north.gov -p youhavetoberealistic
# Output: 0xbc807ee29df3c9ffa736523fb2c4e8ee
# ('0x' in the beginning of the key is what differentiates the key from
# password. If it has 0x then it is a key, otherwise it is a password).
#
# The corresponding user account entry in the userdb file will be:
#
#ninefingers:0xbc807ee29df3c9ffa736523fb2c4e8ee
# Or, equivalently (less secure):
#ninefingers:youhavetoberealistic
#



Friday, September 19, 2014

SonarQube 설치 (CentOS 6.5 64-bit)

  1. SonarQube 설치 전에 필요한 것
    1. CentOS 6.5 (64-bit)가 설치된 시스템 (또는 VM)
    2. Java 설치 (최소 1.6 버전 이상)
  2. SonarQube 설치
    1. http://www.sonarqube.org/downloads 에서 최신 버전 다운로드 (이 포스트에서는 4.3.2 버전이 사용되었습니다.)
    2. 압축을 푼 후 '/opt' 폴더로 이동
  3. PostgreSQL 설치 
    1. SonarQube를 사용하기 위해서는 기본적으로 DB가 설치 되어 있어야 하며 이 포스트에서는 PostgreSQL을 사용하도록 하겠습니다. 
    2. Dependency 관련 문제 발생을 막기 위해 '/etc/yum.repos.d/CentOS-Base.repo' 파일에 있는 '[base]' 부분과 '[update]' 부분에 아래의 라인을 추가.
      1. exclude=postgresql*
    3. CentOS 6 64-bit 버전용 PostgreSQL 9.3의 PGDG RPM 파일 인스톨
      1. yum localinstall http://yum.postgresql.org/9.3/redhat/
        rhel-6-x86_64/pgdg-centos93-9.3-1.noarch.rpm
      2. 추가설명: 이 버전은 2014년 9월 현재 가장 최신 버전이며 만약 더 나중 버전이
        나왔다면 그 버전의 RPM 파일을 인스톨 하시기 바랍니다. 
    4. PostgreSQL 인스톨
      1. 아래의 명령어를 이용해서 인스톨 가능한 poastgreSQL 패키지들을 출력한 후
        1. yum list postgres*
      2. 가장 최근의 stable한 버전의 PostgreSQL 패키지를 찾아서 인스톨하면 됩니다.
        예를 들어 가장 기본적인 PostgreSQL 9.3 Server 패키지를 인스톨하려고 한다면
        아래의 명령어를 실행하세요. 
        1. yum install postgresql93-server
  4. PostgreSQL JDBC 드라이버 다운로드
    1. 웹사이트 (https://wiki.postgresql.org/wiki/YUM_Installation)에서 JDBC4
      Postgresql 드라이버를 다운로드하세요.
    2. 다운로드 받은 드라이버를 '/opt/sonarqube-4.3.2/extensions/jdbc-driver/postgresql' 폴더로 옮기고 기존에 있던 'postgresql-[version].jebc4.jar' 파일은 삭제를 하세요. (참고로 sonarqubu-4.3.2는 postgresql-9.1-901-1.jdbc4.jar를 기본으로 포함하고 있습니다.)
  5. 'root' 아이디로 'sonar' 아이디 생성
    1. adduser sonar
      passwd sonar
      New password: sonar
      Retype new password: sonar
  6. 'sonarqube' 폴더의 owner를 새로 생성한 'sonar'로 변환
    1. chown -R sonar /opt/sonarqube-4.3.2
  7. PostgreSQL 셋팅 설정
    1. PostgreSQL 설정 파일을 다른 네트워크나 웹서버에서 유저 아이디와 패스워드를 이용해서 접속할 수 있도록 변경
      1. vim /var/lib/pgsql/9.3/data/pg_hba.conf
      2. pg_hba.conf 파일의 'local'과 'host'의 method 부분을 아래와 같이 'trust'로 변경
      3. local all all              trust
        host  all all 127.0.0.1/32 trust
    2. PostgreSQL 서비스를 시작하고 유저를 'postgres'로 변경
      1. service postgresql-9.3 start
        su - postgres
    3. PostgreSQL에 접속(실행)한 후 PostgreSQL 안에서 새 유저 sonar를 생성한 후 실행 종료
      1. psql
        postgres=# CREATEUSER -d sonar;
        postgres=# CREATE DATABASE sonar OWNER sonar;
        postgres=# ALTER USER sonar SET search_path to sonar;
        postgres=# \q
    4. 리눅스 시스템에서 유저를 'sonar'로 변경한 후 PostgreSQL을 다시 실행하고 'sonar' 스키마를 생성
      1. su - sonar
        psql
        sonar=# CREATE SCHEMA sonar;
        sonar=# \q
  8. SonarQube 셋팅 설정
    1. '/opt/sonarqube-4.3.2/conf/sonar.properties' 에 있는 파일에 있는 데이터베이스 관련 설정을 아래와 같이 변경
      1. sonar.jdbc.username=sonar
        sonar.jdbc.password=sonar
        sonar.jdbc.url=jdbc:postgresql://localhost/sonar
  9.  SonarQube 서비스 시작
    1. /opt/sonarqube-4.3.2/bin/sonar.sh start
  10. SonarQube의 웹 UI 화면 Access
    1. 웹브라우저에서 http://localhost:9000 을 입력하면 아래와 같은 화면이 나옵니다. 

  11. Troubleshooting
    1. Firewall 문제
      1. 만약 웹 UI에 접속이 안된다면 리눅스 시스템의 Firewall을 아래의 리눅스 커맨드를 이용해서 disable한 후에 다시 시도하세요
        1. service iptables stop
  12. Sources
    1. http://docs.codehaus.org/display/SONAR/Requirements
    2. https://wiki.postgresql.org/wiki/YUM_Installation
    3. http://www.cyberciti.biz/faq/psql-fatal-ident-authentication-failed-for-user/ 
    4. http://docs.codehaus.org/display/SONAR/Installing