블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 


피닉스 패턴의 VM 이미지 타입


조대협 (http://bcho.tistory.com)


피닉스 서버 패턴을 이용해서 이미지를 만들때, 그러면 이미지에 어디까지 패키징이 되어야할지 결정할 필요가 있다. 정답은 없지만 몇가지 정형화된 패턴을 찾을 수 는 있다


OS Image

가상화 환경이나 클라우드를 사용하면 디폴트로 사용하는 패턴으로 이미지가 OS 단위로 되어 있는 패턴이다. 우분투 이미지, 윈도우 이미지와 같이 OS 단위로 이미지가 되어 있다.




피닉스 패턴을 사용할 경우 애플리케이션 배포시, 이미지를 이용해서 VM 을 생성하고 VM 이 기동될때, Configuration management 도구를 이용하여 소프트웨어 스택 (미들웨어, 라이브러리등)과 애플리케이션 코드를 배포하는 방식이다.

Foundation Image

Foundation Image는 이미지를 OS단위가 아니라 서비스 플랫폼, 예를 들어 Ruby on rails 환경, PHP환경과 같은 환경 별로 관리하는 방법이다.



일종의 PaaS와 같은 개념의 이미지로 생각되는데, 가장 적절한 절충안이 아닌가 싶다.


Immutable Image

마지막으로는 Immutable Image (불변) 이미지인데, 이 이미지 타입은 배포마다 매번 새롭게 이미지를 만드는 패턴이다.


항상 OS 부터 애플리케이션 까지 전체 스택이 같이 이미지화 되어 배포되기 때문에, 최신 업데이트를 유지하기가 좋지만, 빌드 시간이 많이 걸리고 관리해야 하는 이미지 양이 많아진다.

이 패턴으로 갈거면 도커를 쓰는게 오히려 정답이 아닐까 싶다.


 OS 이미지 패턴의 경우 VM이 올라오면서 소프트웨어들이 설치되고 애플리케이션이 설치되는 모델인데, 소프트웨어 특히 npm이나 pip들을 이용해서 라이브러리를 설치할때 외부 저장소를 이용하는 경우, 외부 저장소가 장애가 날 경우 소프트웨어 설치가 안되기 때문에 외부 시스템 장애에 대한 의존성을 가지고 있고 설치 시간이 길기 때문에 그다지 좋은 패턴으로는 판단이 안되고, immutable 패턴은 위에서도 언급했듯이 빌드 시간이 길고, 여러 이미지를 관리해야하기 때문에 그다지 권장하고 싶지 않지만, 전체를 매번 묶어서 배포함으로써 일관성 유지가 가능한 장점이 있기 때문에 만약에 해야 한다면 도커를 이용해서 구현하는 것이 어떨까 한다. Foundation Image 패턴이 가장적절한 패턴으로 판단되는데, 다음글에서는 Packer를 이용하여, Foundation Image 타입을 만드는 방법을 알아보도록 하겠다.


피닉스 서버

조대협 (http://bcho.tistory.com)


근래에 들어서 인프라 스트럭쳐를 소프트웨어로 정의하는 Infrastructure As a Code (줄여서 IaC라고 부름)를 관심있게 보고 있는데, CI/CD의 단순 연장선상의 하나의 툴링정도로 생각했는데, 생각보다 상당히 넓은 생태계라서 좀더 깊게 보고 있다.

IaC는 일반적인 툴이나 단순한 프로세스가 아니라 하나의 사상이기 때문에 이를 제대로 이해하기 위해서는 툴링 관점의 접근 보다는 사상과 배경에 대해서 제대로 이해할 필요가 있다.

IaC 개념을 이해하는데 도움이 되는 개념으로 Snowflakes Server (스노우플레이크 서버)와 Phoenix Server(피닉스 서버) 두 가지 개념에 대해서 알아볼 필요가 있다.

Snowflakes Server (스노우 플레이크 서버)

예전에 일반적으로 서버를 운영하는 방법은 서버를 설치한 후 OS를 인스톨한 후에, 필요한 소프트웨어와 애플리케이션을 설치하여 운영하는 형태였다. 여기에 문제가 생긴 경우 패치를 하거나 정기적인 보안 패치 튜닝들을 해당 서버에 지속적으로 적용하고, 애플리케이션은 CI/CD 등의 툴을 이용하여 배포하는 구조를 가지고 있었다.


이렇게 한번 설치한 서버에 계속해서 설정을 변경하고 패치를 적용하는 등의 업데이트를 지속적으로 적용하여 운영하는 서버를 스노우 플레이크 서버 (눈송이 서버)라고 하는데, 이렇게 설정된 서버는 다시 똑같이 설정하기가 매우 어렵다. 모든 설정과정이 문서화가 잘되어 있으면 모르겠지만 대부분 문서화가 꼼꼼한 경우도 드물뿐더러,  담당자가 바뀌거나 관리 조직이 바뀌는 경우에는 그 이력이 제대로 유지되는 경우가 없다. 그래서 장비를 업그레이드 하거나 OS를 새로 인스톨해서 같은 환경을 꾸미고자 할때 예전 환경과 동일한 환경을 구성하기가 어렵고 그래서, 누락된 설정이나 패치등에 의해서 장애가 발생하는 경우가 많다.

이렇게 한번 설정을 하고 다시 설정이 불가능한, “마치 눈처럼 녹아버리는" 서버의 형태를 스노우 플레이크 서버라고 한다.


재 구성의 문제뿐 아니라, 이런 스노우 플레이크 서버는 구성 편차를 유발하기도 하는데, 여러대의 웹서버를 운영하고 있는 조직에서, 문제가 있어서 특정 서버를 패치한 경우, 다른 동일한 웹서버를 모두 패치 하지 않는 이상 구성이 달라진다.  이는 또 운영상의 문제를 일으킬 수 있다.

Phoenix Server (피닉스 서버)

그래서 나온 서버 패턴이 피닉스 서버 패턴인데, 피닉스(불사조)는 불멸로도 알려져있지만 정확히는 불속에서 다시 태어나는 re-born (재탄생)의 개념을 가지고 있다. 이 재탄생의 개념을 서버 설정 방식에 적용한 패턴이 피닉스 서버 패턴이다.

새로운 소프트웨어를 인스톨하거나 설정을 변경할때 기존 서버에 변경 작업을 더 하는 것이 아니라, 처음 OS 설치에서 부터, 소프트웨어 인스톨, 설정 변경까지를 다시 반복하는 것이다.

예를 들어 우분투 16, 톰캣 7.0 버전으로 운영되고 있는 서버가 있을때, 이 서버에 로그 수집 모듈은 fluentd를 설치하는 케이스가 있다고 가정하자.


스노우플레이크 서버 패턴의 경우에는 이미 운영되고 있는 서버에 새롭게 fluentd를 일일이 설치하거나 자동화가 되어 있는 경우에는 ansible 이나 chef등의 configuration management 도구를 이용하여 fluentd를 설치하게 된다.


피닉스 서버 패턴의 경우에는 새 VM을 다시 만들고, 우분투 16 OS를 설치하고, 톰캣 7.0을 설치하고 fluentd를 설치한 다음. 이 VM으로 기존 VM 을 교체한다.


매번 전체 설치를 반복한다면 매우 많은 시간이 들텐데, 어떻하냐? 물론 매번 이렇게 새롭게  모든 스택을 설치하지 않는다. 어느정도 공통 스택은 가상머신의 베이스 이미지 (VM Base Image)로 만들어놓고, 이 이미지를 이용하여 VM을 생성한 후에, 차이가 나는 부분만 설정을 하는 구조를 설정하는 구조를 사용하게 되고 이 과정은 스크립트 코드를 이용해서 자동화하기 때문에, 그렇게 많은 시간이 소요되지 않는다.

피닉스 서버 패턴에서는 매번 전체를 스크립트를 이용해서 설치하기 때문에, 다음과 같은 장점을 가지게 된다.


  • 스크립트에 모든 설정 정보가 유지되게 된다.

  • 이 스크립트 코드를, git와 같은 소스 코드 관리 시스템을 이용해서 관리하게 되면, 어떤 부분을 누가 어떻게 수정을 했는지 추적이 가능하게 된다.

피닉스 서버 패턴을 이용한 배포 구조

그러면 이 피닉스 서버 패턴을 이용한 배포 구조를 보도록 하자

앞의 예제와 같이 Ubuntu 16, Tomcat 7이 설치된 VM서버 2대가 서비스되고 있고, 이 서버들은 앞단에 로드밸런서에 연결되어 있다고 생각하자. 이 VM들은 Ubuntu16, Tomcat 7이 설치되어 있는 Base Image로 생성했다고 가정하자.



Fluentd를 설치하기 위해서는 피닉스 서버 패턴 처럼, Fluentd가 설치된 새로운 base image를 생성하고, 이 이미지를 이용하여 새로운 VM들을 만든다. 이 VM들 그룹은 아직 서비스가 되기 전으로, 이 그룹을 Pre-production 그룹이라고 한다.



Pre-production 그룹이 정상적으로 들어왔으면 로드밸런서를 변경하여 기존의 구 버전 VM으로 들어가던 트래픽을 pre-production 그룹으로 옮겨준다.


그리고 마지막으로, 기존의 운영환경을 지워주면 아래와 같이 새 환경으로 서비스 하는 환경만 남게 된다.


이렇게 서버가 구 버전에서 새버전으로 재탄생(re-born)하는 것이 피닉스 서버 패턴이다.


이 패턴의 문제는 VM 이미지를 빌드하기 때문에, 빌드 및 배포 시간이 상대적으로 오래 걸리고, 또한 배포 당시 기존 Production 환경과 Pre-production 환경이 공존하기 때문에, 다소 추가 비용이 소요될 수 있다.


이 피닉스 서버 패턴에서 중요한것은 기존 이미지를 이용하여 변경을 주고, 이를 다시 이미지로 만들어낼 수 있지만, 이렇게 하면 스노우플레이크 서버이지 피닉스 서버가 아니다. 피닉스 서버는 기존 이미지를 재 사용하는게 아니라 처음부터 모든 스택을 새로 설치해야 하기 때문에, 처음부터 모든 스택을 설치하여 이미지를 만들 수 있는 자동화 툴이 필요하다. 다음 글에서는 이미지 생성을 자동화 해주는 HashiCorp의 Packer라는 오픈소스에 대해서 알아보도록 하겠다.


구글 클라우드 시작하기

계정 생성과 VM 생성하기

조대협 (http://bcho.tistory.com)


구글 클라우드 플랫폼에서 가상머신 VM을 생성해주는 GCE (Google Compute Engine)을 통해서 간단하게 VM을 생성하고 웹서버를 띄우는 방법에 대해서 알아보자.

계정 가입

먼저 GCP 클라우드를 사용하기 위해서는 구글 계정에 가입한다. 기존에 gmail 계정이 있으면 gmail 계정을 사용하면 된다. http://www.google.com/cloud 로 가서, 좌측 상당에 Try it Free 버튼을 눌러서 구글 클라우드에 가입한다.




다음 콘솔에서 상단의 Google Cloud Platform 을 누르면 좌측에 메뉴가 나타나는데, 메뉴 중에서 “결제" 메뉴를 선택한후 결제 계정 추가를 통해서 개인 신용 카드 정보를 등록한다.


개인 신용 카드 정보를 등록해야 모든 서비스를 제한 없이 사용할 수 있다.  단 Trial의 경우 자동으로 한달간 300$의 비용을 사용할 수 있는 크레딧이 자동으로 등록되니, 이 범위를 넘지 않으면 자동으로 결제가 되는 일이 없으니 크게 걱정할 필요는 없다.


프로젝트 생성

계정 생성 및 결제 계정 세팅이 끝났으면 프로젝트를 생성한다.

프로젝트는 VM이나 네트워크 자원, SQL등 클라우드 내의 자원을 묶어서 관리하는 하나의 집합이다. 여러 사람이 하나의 클라우드를 사용할때 이렇게 프로젝트를 별도로 만들어서 별도로 과금을 하거나 각 시스템이나 팀별로 프로젝트를 나눠서 정의하면 관리하기가 용이하다.


화면 우측 상단에서 프로젝트 생성 메뉴를  선택하여 프로젝트를 생성한다.



프로젝트 생성 버튼을 누르면 아래와 같이 프로젝트 명을 입력 받는 창이 나온다. 여기에 프로젝트명을 넣으면 된다.


VM 생성


프로젝트가 생성되었으면, 이제 VM을 만들어 보자

좌측 메뉴에서 Compute Engine을 선택한다.


다음으로 바뀐 메뉴에서 좌측 VM 인스턴스를 선택한 후에, “인스턴스 만들기"를 통해서 인스턴스를 생성한다.

VM 인스턴스는 다음과 같은 조건으로 생성할것이다.


  • 인스턴스 이름은 ubuntu-instance

  • 가장 작은 사이즈의 인스턴스 (초소형 인스턴스 vCPU *1, 0.6G 메모리)

  • 10 GB의 로컬 디스크

  • Ubuntu 14.04LTS

  • 유동 외부 IP

  • HTTP 트래픽 허용


VM 생성창에서 위의 조건에 따라 아래 화면과 같이 설정값을 세팅 한후 VM을 생성한다. 나머지 값들은 디폴트로 놔두면 된다.





몇가지 주의할점은 “ID 및 API 액세스" 부분에서 “액세스 범위"를 “모든 Cloud API에 대한 전체 액세스 허용" 으로 세팅해줘야 한다. 이부분은 구글 클라우드에서 제공하는 API나 CloudSQL,BigQuery,Vision API 등 다른 서비스를 이 VM이 호출 할 수 있는 권한을 주는 것이다. 이 설정은 VM 생성 초기에 하지 않으면 차후에 변경이 불가능하니 반드시 설정 초기에 하기 바란다.


다음으로 “네트워크 부분”에 “외부 IP” 부분을 “임시”로 설정한다.


외부 IP 는

  • 지정하지 않음

  • 임시

  • 고정 주소


3가지를 선택할 수 있는데, 지정하지 않을 경우 이 VM은 외부 IP (Public IP)를 가지지 않기 때문에 인터넷에서 직접적으로 이 VM에 접근할 수 없다. HTTP 요청의 경우 별도의 프록시나 로드밸러서를 앞에 놓고 접근을 하거나 SSH와 같은 쉘 접근도 같은 내부 네트워크 (Private IP) 대역에 있는 다른 VM을 통해서만 접근이 가능하다. ( 이미 잘 알고 있겠지만 ) 외부 IP 주소를 가지지 않는 VM은 외부로 부터 접근을 차단하여 보안성을 높이기 위한 의도이다.


그리고 VM 생성시에 영역 (Zone)을 설정하는데, Zone은 클라우드 VM이 생성되는 장소라고 생각하면 된다.

리젼이 가장 큰 개념으로 대륙을 정의 한다. 미국 중부,서부,아시아,유럽 등이 리전에 해당하고, 각 리전안에는 여러개의 데이타 센타가 있는데, 이 데이타 센타를 영역 (Zone)으로 생각하면 된다. 이 예제에서는 asia-east1-a에 인스턴스를 생성한다.


인스턴스가 생성되면 아래 화면과 같이 생성된 인스턴스가 기동됨을 확인할 수 있다.



브라우져를 통한 SSH 접속

인스턴스가 생성되었으면 이제 생성된 인스턴스로 SSH로 접속해보자 PC의 Putty와 같은 SSH 터미널을 이용해서 접근하는 방법은 http://bcho.tistory.com/1103 링크를 참고하기 바란다.

이러한 방법이 복잡할 경우 화면에서 VM 우측에 SSH 버튼을 누른다.


그러면 별도의 SSH 터미널이 없이도 아래 그림과 같이 웹 브라우져 상에서 SSH 터미널을 오픈해준다.

아파치 웹서버 설치


SSH로 접속을 했으면, 이제 아파치 웹서버를 설치하고 기동해보자 설치는 우분투의 apt-get 유틸리티를 사용할것이다.

먼저 apt-get 저장소를 최신으로 업데이트 하기 위해서 다음 명령어를 실행한다.

%sudo apt-get update

다음으로 apache2 웹 서버를 설치해보자

%sudo apt-get install apache2


설치가 끝나면 자동으로 apache 웹서버가 기동이 된다. 혹시 기동이 되고 있지 않다면 다음 명령어를 이용해서 기동하자

%sudo apachectl start


기동이 되었는지를 확인하려면 이 VM의 외부 IP(public ip)로 브라우져를 통해서 접속해보자.

접속이 성공하면 다음과 같은 페이지가 브라우져에 뜨는 것을 확인할 수 있다.




VM 삭제


만약에 서비스를 계속해서 하지 않을 것이면 VM 을 정지하거나 삭제하면된다.

정지와 삭제의 차이는  정지된 VM은 나중에 재 시작이 가능하다. 단 스토리지 비용은 계속 과금 된다. 삭제는 VM을 없애 버리는 것으로 다시 재시작이 불가능하고 당연히 아무 비용도 과금되지 않는다.


VM의 정지나 삭제는 아래 그림과 같이 인스턴스 목록에서 정지 또는 삭제하고자 하는 VM을 선택한 후, 상단 메뉴에서 [정지] 또는 [삭제] 메뉴를 선택하면 된다.




참고 자료



알아서 깍아주는 구글 클라우드의 가격 정책

조대협 (http://bcho.tistory.com)


구글 클라우드에 대해서 공부를 하다보니, 가격 정책을 살펴보게 되었는데, 흥미로운 가격 정책이 있어서 정리를 해본다.


구글 클라우드의 가격정책은 다른 클라우드에 비해서 크게 다음과 같은 특징을 가지고 있다.

  • 분단위 과금

  • 장기 계약 없이 알아서 깎아 주는 정책

  • VM 사용량을 자동으로 합산해서 깎아 주는 정책

  • 커스텀 인스턴스

분단위 과금

구글 클라우드의 인스턴스에 대한 과금 정책은 분단위 과금이다. 최소 10분은 과금이 되고 그 이후의 사용량에 대해서는 분단위로 과금이 된다. 타 클라우드의 경우에는 시간단위 과금이 많은데, 그렇다 보니 1시간 1분을 사용하더라도 고스란히 2시간이 과금된다. 하둡이나 배치 작업 처럼 일정 시간에만 과금이 되는 연산의 경우, 연산 시간을 시간 단위로 끊을 수 가 없어서 타 클라우드의 경우에는 올림으로 계산이 되서 과금이 되지만, 구글 클라우드는 분단위로 계산이 되기 때문에 단기적으로 사용하는 배치나 분산 연산 작업등에 효율적으로 사용될 수 있다.

장기 계약 없이 알아서 깎아 주는 정책

재미있는 기능중에 하나가 인스턴스를 일정 시간 이상 사용을 하면 자동으로 디스카운트가 된다. 한달 내내 인스턴스를 사용하면 30%가 디스카운트가 되고, 한달에 25% 이상 사용하면 단계적으로 디스카운트가 된다. 자동으로!!


이게 왜 중요한가 하면, 보통 클라우드에서 인스턴스 가격을 할일 받기 위해서는 미리 사용할 인스턴스의 타입과 기간을 명시해야 한다. 이 경우에 문제는

첫번째 장기 계약시 구세대 인스턴스를 계속 사용해야 한다는 것이다. 3년 계약으로 인스턴스에 대한 가격 할인을 받으면 3년동안 계속 구세대 인스턴스를 사용한다는 이야기인데, 클라우드의 인스턴스 성능이 빠르게 나날이 발전하기 때문에, 비용은 계약당시 싸다고 느낄 수 있지만 시간이 지날 수 록 저성능 인스턴스를 사용하기 때문에, 과연 혜택이 있는지 고민해봐야 한다.


두번째로 장기 계약을 하면 무조건 그 인스턴스를 계속해서 사용해야 하기 때문에, 비지니스 상황에 따라서 다른 인스턴스로 바꾸거나 또는 인스턴스 수를 줄일 수 없다.


구글 클라우드의 경우에는 이런 고민을 할필요가 없이 최신이나 구형이나 인스턴스를 그냥 쓰면 사용한 양에 따라서 알아서 할인이 된다.

VM 사용량을 자동으로 합산해서 깍아 주는 정책

요것도 재미있는 할인 정책중에 하나인데, 위의 할인 정책을 쓰려면 월 사용량이 30% 이상이 되어야 한다. 30% 할인을 받으려면 한달을 다 써야 하는데, 만약에 인스턴스 A를 30%, 인스턴스 B를 30% 인스턴스 C를 20%, 인스턴스 D를 20% 쓴다면 어떻게 될까? 위의 할인 정책에 의하면 할인이 안될거 같은데? 답은 된다.


구글 클라우드의 가격 정책은 총 사용량을 모아서 할인을 할 수 있게 해준다. 즉 A,B,C,D의 총 사용량이 월 100%가 되기 때문에, A,B,C,D의 금액중 전체를 30% 할인해준다.




만약에 인스턴스 타입이 달라도 할인이 가능할까?

답은 역시 Yes이다. 원리는 작은 인스턴스 스펙으로 잘라서 이 사용량을 묶은 후에, 할인을 하는 방식인데, 아래 그림 처럼 2CPU 4G 인스턴스 50%, 4 CPU, 8G 인스턴스 50%를 사용하면, 4GB 8G 인스턴스의 사용량을 앞의 2 CPU 4G에 맞춰서 합산해서 100%로 계산하고 남은 2 CPU, 4G로 50% 사용한량은 별도로 과금하는 방식이다.


커스텀 인스턴스

인스턴스 가격 정책과 함께 재미있는 것중의 하나는 미리 정해진 인스턴스 타입뿐 아니라 필요한 인스턴스 타입을 직접 정할 수 있다. 필요한 수의 CPU와 메모리를 지정해서 사용할 수 있기 때문에, 많은 CPU가 필요하고 적은 메모리가 필요할때(혹은 반데로) 불필요하게 큰 인스턴스를 사용할 필요 없이 딱 필요한 싸이즈로 적용하고 그에 해당하는 금액만 지불하면 된다.


정리를 하자면, 구글 클라우드의 과금 정책은 쉽게 이해하면 돈을 뜯어내는게 아니라 되도록이면 할인을 해주는 방식으로 이거저거 생각할 필요 없이 쓰면 알아서 최적화된 과금 방법 찾아서 알아서 할인해준다.


과금에 대한 자세한 내용을 https://cloud.google.com/compute/pricing#sustained_use

를 참고하기 바란다.



구글 클라우드 VM으로 SSH  접속하기


조대협 (http://bcho.tistory.com)


클라우드에서 VM을 생성하면, 이 VM에 접속하기 위해서 리눅스 VM의 경우 일반적으로 SSH 연결을 사용한다.

구글 클라우드에서 SSH를 이용하여 VM에 접속하는 방법을 알아본다.


1. SSH 키페어 생성

ssh-keygen 명령어를 이용하여 다음과 같이 RSA 키페어를 생성한다.

%ssh-keygen -t rsa -C "구글계정명"



2. 키페어가 생성이 되었으면 *.pub으로 끝나는 이름의 퍼블릭키의 내용(텍스트)를 복사한후, 콘솔창에서 "Compute Engine > Metadata > SSH Keys"  부분에 복사한 텍스트를 붙여 넣어서 키를 등록한다.




3. 키 등록이 끝났으면, 이 키를 이용하여 SSH로 접속한다.

% ssh -i [Private 키 파일] 계정@호스트명



Vagrant를 이용한 개발환경 관리(간단한 VM관리)

ALM | 2013.10.24 00:48 | Posted by 조대협

Vagrant

시작하기

Vagrant는 한마디로 이야기 하면, “간소화된, VM 관리 서비스이다”. 이미 Virtual Machine 환경은 보편화 되서 사용되고 있고, VMWare Oracle Virtual Box등을 이용하면 PC에서도 손쉽게 VM 환경을 구축할 수 있다. 그러나 문제점은, Virtual Box와 같은 Hypervisor가 있다고 해도, VM을 생성하는 것 자체가 번거로운 작업이라는 것이다.

 Hypervisor에서 논리적인 가상 하드웨어 머신을 생성하고 가상머신에 OS를 설치하고, 일일이 설정을 해줘야 한다. 이런 반복적인 작업을 조금더 손쉽게 자동화 할 수 없을까? 하는 아이디어에서 시작한 것이 Vagrant이다.

먼저 이해를 돕기 위해서 예제를 실행해보자.

Vagrant VM 관리도구 이기 때문에, 먼저 Hypervisor 부터 인스톨을 해야 한다.

https://www.virtualbox.org/ 에서 Virtual Box를 다운로드 받아서 설치하자.

다음으로 http://www.vagrantup.com/ 에서 vagrant를 받아서 인스톨한다. 이제 준비가 끝났다.

아래와 같이 vagrant init precise32 http://files.vagrantup.com/precise32.box 를 실행하면, Ubuntu Linux VM의 실행하기 위한 설정들을 자동으로 가지고 온다. 그리고 vagrant up 명령어를 실행하면 해당 설정에 따른 VM 을 자동으로 다운받아서 설치하고 Virtual Box를 통해서 해당 VM을 기동 시킨다. Putty를 이용하여 SSH localhost:2222 번으로 접속 (id:vagrant, passwd:vagrant)를 입력하면, 생성된 VM에 로그인할 수 있다. 또는 간단하게 “vagrant ssh”라고 실행하면, 현재 생성된 VM에 자동으로 SSH로 연결된다.



Vagrant 없이 Virtual Box에서 직접 Ubuntu VM을 설치하려면 VM을 만들고, Ubuntu OS를 설치해야 한다. 그러나 Vagrant가 있으면 이렇게 간단하게 두줄의 명령어로 VM을 만들고 실행시킬 수 있다.

Box 개념 이해하기

앞에서 vagrant init 명령을 실행할때, preceise32.box라는 파일을 지정하였다. box 파일은 VM을 만들기 위한 기본 OS 이미지를 포함한 VM 설정(CPU,메모리 사이즈등)에 대한 기본 템플릿이다. (사이즈가 보통 수백 메가가 나간다.)

http://www.vagrantbox.es/ 에 보면 공개된 box 파일들이 있다. Ubuntu, Debian 등 다양한 Linux OS 버전의 VM 들에 대한 box 파일들이 있다.

Vagrant file

Vagrant init을 하면, 해당 디렉토리에 “Vagrantfile” 이라는 이름으로 생성되는 파일인데, Box VM 생성을 위한 기본 템플릿이라면, Vagrant file은 생성될 VM에 대한 세부 설정을 정의한다. VM을 생성할때, 어떤 box 파일을 사용할 것인지, VM에 대한 하드웨어 설정 예를 들어 CPU,메모리 사이즈,네트워크, 네트워크 포트포워딩 설정등을 여기서 재정의 할 수 있다.

아래는 Oracle Virtual Box실행시 preceise32 box 이미지를

http://files.vagrantup.com/precise32.box 에서 읽어와서, CPU 2, 512M를 가진 “Terry_vargrant0”이라는 VM을 생성하는 Vagrantfile이다. 아래와 같이 파일을 생성한후에, vagrant up 명령을 수행시키면 설정한 정보 대로 VM이 생성된다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

  # config.vm.network :forwarded_port, guest: 80, host: 8080

  # config.vm.network :private_network, ip: "192.168.33.10"

  # config.vm.network :public_network

  # config.ssh.forward_agent = true

  config.vm.provider "virtualbox" do |vm|

        vm.customize [

               "modifyvm",:id,

               "--memory","512",

               "--name","Terry_vagrant0",

               "--cpus","2",

                       ]

  end

end

 

Vagrant + Provisioning

Vagrant를 이용하면, VM을 쉽게 만들 수 있다. 그런데 개발환경을 구축하자면, OS가 인스톨된 VM 뿐만 아니라, 그위에 웹서버,DB등 미들웨어들을 설치해야 하고, 그리고 거기에 맞는 Configuration을 해야 한다. 물론 미리 VM 이미지에 웹서버등을 설치해놓고, 필요에 따라서 vagrant를 이용해서 해당 VM들을 설치해서 사용해야 하지만 그 경우에는 설정마다 매번 다른 VM이미지를 만들어놔야 하기 때문에 번거롭다. 만약에 OS 만 설치된 VM에다가, 설정에 따라서 소프트웨어와 설정을 하는 부분을 분리한다면?

이런 접근을 지원하는 기능이 Vagrant provisioning이라는 기능이 있다. VM을 기동한 후에, vagrantfile에 정의된 provisioning script를 수행해준다. 다음 예제를 보자. 다음 예제는 VM이 기동된 후에, apt-get 명령을 이용해서 apache2 (웹서버)를 자동으로 설치하는 설정이다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

config.vm.provision :shell, :inline => "sudo apt-get install -y apache2"

 

end

위의 예제는 VM이 기동될때 마다 shell 명령어를 수행하도록 한것인데, 명령어말고도 shell스크립트를 수행하게 할 수 도 있고, puppet이나 chef와 같은 configuration management 도구를 이용해서, 제품을 설치하게 할 수 도 있다.

한 가지 주의할점은 Vagrantfile provision 부분에 정의된 명령어는 vagrant up, reload, provision 3개의 명령어가 실행될때 마다 매번 실행된다. up에서도 매번 실행되기 때문에, 스크립트내에, 해당 소프트웨어가 미리 설치되었는지 확인한 후에, 설치가 안되어 있을 경우에만 설치하도록 스크립트를 짜는 것이 좋다.

Provisioning에 대한 자세한 방법은 http://docs.vagrantup.com/v2/provisioning/index.html 를 참고하면 된다.

Vagrant를 이용한 개발 환경 구축

그러면 Vagrant를 이용해서 개발환경을 어떻게 구축할 수 있는지 살펴보도록 하자



크게 그림과 같이 2개의 repository가 필요하다. Box image repository에는 기본 이미지가 인스톨된 box image들을 저장해놓는다.

그리고 svn이나 git와 같은 VCS 툴에 vagrantfile을 저장해놓는다. (아니면 간단하게 웹서버에 저장해놔도 된다.) Vagrantfile에는 box 파일들을 저장해놓은 repository pointing 하도록 하고, 필요에 따라서

1.  Ubuntu + Apache

2.  Ubuntu + MySQL

3.  Ubuntu + Tomcat

와 같이 다양한 설정을 만들어 놓고, 필요에 따라서 Vagrantfile이 받은 후에, 간단하게 “vagrant up” 명령어만 수행하면 간단하게 개발환경에 필요한 VM을 만들어낼 수 있다.

지금까지 간략하게 Vagrant에 개념과 사용법에 대해서 알아보았다.Vagrant는 그외에도, Vagrant는 단일 VM 뿐만 아니라 multi vm을 단일 vagrantfile에서 설정이 가능하고, Oracle Virtual Box뿐만 아니라,VMWare Amazon EC2 클라우드 까지 지원한다. 간단하게는 개발환경에서 부터,응용하면, QA,스테이징,운영환경 배포용으로도 활용할 수 있다.

자세한 내용들은 http://docs.vagrantup.com/ 를 참고하기 바란다

'ALM' 카테고리의 다른 글

SOAPUI로 유명한 SmartBear의 ALM 툴들  (0) 2013.12.31
Vagrant를 이용한 개발환경 관리(간단한 VM관리)  (1) 2013.10.24
Docker 소개  (6) 2013.10.22
관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03

Docker 소개

ALM | 2013.10.22 01:23 | Posted by 조대협

Docker란 무엇인가?

개념 잡기

Docker Linux 기반의 Container RunTime 오픈소스이다. 처음 개념을 잡기가 조금 어려운데, Virtual Machine과 상당히 유사한 기능을 가지면서, Virtual Machine보다 훨씬 가벼운 형태로 배포가 가능하다. 정확한 이해를 돕기 위해서, VM Docker Container의 차이를 살펴보자.

아래는 VM 에 대한 컨셉이다. Host OS가 깔리고, 그 위에 Hypervisor (VMWare,KVM,Xen etc)가 깔린 후에, 그위에, Virtual Machine이 만들어진다. Virtual Machine은 일종의 x86 하드웨어를 가상화 한 것이라고 보면된다. 그래서 VM위에 다양한 종류의 Linux, Windows등의 OS를 설치할 수 있다.



DockerContainer 컨셉은 비슷하지만 약간 다르다. Docker VM 처럼 Docker Engine Host위에서 수행된다. 그리고, Container Linux 기반의 OS만 수행이 가능하다.

Docker VM처럼 Hardware를 가상화 해주는 것이 아니라, Guest OS (Container) Isolation해준다.무슨 말인가 하면, Container OS는 기본적으로 Linux OS만 지원하는데, Container 자체에는 Kernel등의 OS 이미지가 들어가 있지 않다. Kernel Host OS를 그대로 사용하되, Host OS Container OS의 다른 부분만 Container 내에 같이 Packing된다. 예를 들어 Host OS Ubuntu version X이고, Container OS CentOS version Y라고 했을때, Container에는 CentOS version Y full image가 들어가 있는 것이 아니라, Ubuntu version X CentOS version Y의 차이가 되는 부분만 패키징이 된다. Container 내에서 명령어를 수행하면 실제로는 Host OS에서 그 명령어가 수행된다. Host OS Process 공간을 공유한다.



실제로 Container에서 App을 수행하고 ps –ef 를 이용하여 process를 보면, “lxc”라는 이름으로 해당 App이 수행됨을 확인할 수 있다. 아래는 docker를 이용해서 container에서 bash 를 수행했을때는 ps 정보이다. lxc 프로세스로 bash 명령어가 수행되었음을 확인할 수 있다.

root      4641   954  0 15:07 pts/1    00:00:00 lxc-start -n 161c56b9284ffbad0477bd04875c4277be976e2032f3ffa35395950ea05f9bd6 -f /var/lib/docker/containers/161c56b9284ffbad0477bd04875c4277be976e2032f3ffa35395950ea05f9bd6/config.lxc -- /.dockerinit -g 172.17.42.1 -e TERM=xterm -e HOME=/ -e PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin -e container=lxc -e HOSTNAME=161c56b9284f -- /bin/bash

LXC (LinuX Container), 자세한 정보는 http://linuxcontainers.org/ 에서 얻을 수 있다.

lxc container를 실행시켜주는 runtime으로, 앞에서 설명한것과 같이 VM과 비슷한 기능을 제공하지만, 실제 수행에 있어서, guest os (container)를 마치 VM처럼 isolate해서 수행해주는 기능을 제공한다.

이와 같이 Docker LXC라는 Linux에 특화된 feature를 사용하기 때문에, 제약 사항을 가지고 있는데, 현재까지 Docker Ubuntu 12.04 이상(Host OS)에서만 사용이 가능하다.

Performance에 대해서는 당연히 Host OS에서 직접 application 을 돌리는 것보다 performance 감소가 있는데, 아래 표와 같이 performance 감소가 매우 적은 것을 볼 수 있다.



출처: http://www.slideshare.net/modestjude/dockerat-deview-2013

Repository 연계

다음으로 Docker의 특징중의 하나는 repository 연계이다.Container Image를 중앙의 Repository에 저장했다가, 다른 환경에서 가져다가 사용할 수 있다. 마치 git와 같은 VCS (Version Control System)과 같은 개념인데, 이를 통해서 Application들을 Container로 패키징해서 다른 환경으로 쉽게 옮길 수 있다는 이야기다.



예를 들어 local pc에서 mysql, apache, tomcat등을 각 컨테이너에 넣어서 개발을 한 후에, 테스트 환경등으로 옮길때, Container repository에 저장했다가 테스트환경에서 pulling(당겨서) 똑같은 테스트환경을 꾸밀 수 있다는 것이다. Container에는 모든 application과 설치 파일, 환경 설정 정보 등이 들어 있기 때문에, 손쉽게 패키징 및 설치가 가능하다는 장점을 가지고 있다.

여기서 고려해야할점은 Docker는 아쉽게도 아직까지 개발중이고, 정식 릴리즈 버전이 아니다. 그래서, 아직까지는 production(운영환경)에 배포를 권장하고 있지 않다. 단 개발환경에서는 모든 개발자가 동일한 개발환경을 사용할 수 있게 할 수 있고, 또한 VM 보다 가볍기 때문에, 개발환경을 세팅하는데 적절하다고 볼 수 있다.

Base Image vs Dockerfile

Docker Container Image packing하기 위해서, Docker Base Image Docker file이라는 두가지 컨셉을 이용한다. 쉽게 설명하면, Base Image는 기본적인 인스톨 이미지, Docker file은 기본적인 인스톨 이미지와 그 위에 추가로 설치되는 스크립트를 정의한다.

예를 들어 Base Image Ubuntu OS 이미지라면, Docker FileUbuntu OS + Apache, MySQL을 인스톨하는 스크립트라고 보면 된다. 일반적으로 Docker Base Image는 기본 OS 인스톨 이미지라고 보면 된다. 만약에 직접 Base Image를 만들고 싶으면  http://docs.docker.io/en/latest/use/baseimages/ 를 참고하면 된다. docker에서는 미리 prebuilt in image들을 제공하는데, https://index.docker.io/ 를 보면 public repository를 통해서 제공되는 이미지들을 확인할 수 있다. 아직까지는 Ubuntu 많이 공식적으로 제공되고, 일반 contributor들이 배포한 centos 등의 이미지들을 검색할 수 있다. (2013.10.22 현재 redhat 등의 이미지는 없다.)

아래는 docker file 샘플이다. (출처 : http://docs.docker.io/en/latest/use/builder/)

# Nginx

#

# VERSION               0.0.1

 

FROM      ubuntu

MAINTAINER Guillaume J. Charmes <guillaume@dotcloud.com>

 

# make sure the package repository is up to date

RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list

RUN apt-get update

 

RUN apt-get install -y inotify-tools nginx apache2 openssh-server

위의 이미지는 Ubuntu OS 베이스 이미지에 apt-get을 이용해서, inotify-tools nginx apache2 openssh-serverf 를 인스톨하는 스크립트이다.

Docker 실행해보기

그럼 간단하게 docker를 테스트해보자, 윈도우즈 환경을 가정한다. 앞서 말한바와 같이 Docker Unbuntu 위에서만 작동한다. (참고 : http://docs.docker.io/en/latest/installation/windows/)

그래서, 윈도우즈 위에서 Ubuntu VM을 설치한후, Ubuntu VM에서 Docker를 실행할 것이다. 이를 위해서 VM을 수행하기 위한 환경을 설치한다.

l  Hypervisor Virtual Box를 설치한다. https://www.virtualbox.org 

l  VM을 실행하기 위한 vagrant를 설치한다. http://www.vagrantup.com 

l  Docker 코드를 다운받기 위해서 git 클라이언트를 설치한다. http://git-scm.com/downloads 

여기까지 설치했으면, docker를 실행하기 위한 준비가 되었다.

다음 명령어를 수행해서, docker 코드를 git hub에서 다운로드 받은 후에, vagrant를 이용해서 Ubuntu host os를 구동한다.

git clone https://github.com/dotcloud/docker.git

cd docker

vagrant up

Virtual Box를 확인해보면, Docker Host OS가 될 Ubuntu OS가 기동되었음을 확인할 수 있다.



그러면, 기동된 Ubuntu OS SSH를 이용해서 log in을 해보자. Putty를 이용해서 127.0.0.1:2222 포트로, SSH를 통해서 로그인한다. (기본 id,passwd vagrant/vagrant 이다.)

이제 Docker를 이용해서, public repository에서 “busybox”라는 Ubuntu OS Container로 설치하고, Container에서 “echo hello world” 명령어를 수행해보자

sudo su

docker run busybox echo hello world

Docker public repository에서 busybox image를 다운로드 받아서 설치하고, 아래와 같이 명령어를 수행했음을 확인할 수 있다.



※ 참고 : 현재 docker에 설치된 이미지 리스트 docker images, 설치된 이미지를 삭제할려면 docker rmi {image id}. {image id} docker images에서 hexa로 나온 id를 사용하면 된다.

'ALM' 카테고리의 다른 글

SOAPUI로 유명한 SmartBear의 ALM 툴들  (0) 2013.12.31
Vagrant를 이용한 개발환경 관리(간단한 VM관리)  (1) 2013.10.24
Docker 소개  (6) 2013.10.22
관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03

Windows Server에서 가상화를 이용해서 Windows 7을 Hosted OS로 구동 시키고 거기서 스타크래프2를 테스트한 화면입니다.

서버는 Windows Server 2008 R2 SP1 베타 빌드를 사용했으며, AMD 쿼드코어 CPU * 4, ATI FirePro 880 그래픽 카드를 이용했습니다.

아래는 구형 HP 노트북에서 윈도우즈 서버의 윈도우7 VM에 접속해서 스타2를 테스트한 시연 화면입니다.


아래는 ThinLinx사의 Remote Fx를 지원하는 Thin Client 시제품으로 테스트한 결과입니다.



PC에서 했을때는 그럭저럭 만족할만한 성능을 보여줬습니다만, 고사용 데스크탑에서 직접 게임을 하는 것보다는 다소 프레임등이 넘어가는 것이 부드럽지 않습니다. Thin Client는 아직 시제품 단계라서 화면 해상도도 깨지고 성능도 PC보다 다소 떨어지더군요.

이번 테스트 버전이 6월 베타 빌드인데, Remote Fx 부분이 최적화가 더 된다고 하니, 그때 되면 조금 더 높은 성능을 기대해봅니다.