첨부파일 : 

invalid-file


동일한 개발환경을 지닌 가상머신(인스턴스) 의 배포를 손쉽게할 수 있다면, 얼마나 좋을까! 라는 생각을 구현한 멋진 서비스가 아닐까? 서버 리소스를 스케일업하는 클라우드 컴퓨팅 환경에서 인스턴스 관리를 위한 도구로 사용할 수 있지 않을까라는 상상을 잠시 해본다. 사용하려는 서버환경을 구축한 후에 이것을 box로 만들어 확장하는 서버 이미지를 대신하도록 만들어두고, 처음 가동할 때 chef에 의해서 기본적인 추가작업(내가 우분투를 설치하고 로그인하여 처음 실행하는 sudo apt-get update; sudo apt-get upgrade; 도 자동화할 수 있겠지.)이 실행되도록 할 수 있으니, 증설한 서버에 대한 반복적인 작업이 확실히 줄어들 것이다. 스터디가 진행될수록, 개발PC 가상머신을 배포하기 위한 용도보다는 클라우드 컴퓨팅에서 사용할 인스턴스 배포용으로 적합할 것 같다는 생각을 가지게 되었다.


Vagrant

  • 사이트 : http://www.vagrantup.com/
  • 동일한 서버 개발환경 꾸미기
    • 개발과 실서버의 일치를 위해 로컬 가상머신을 손쉽게 관리하자.
    • 로컬 개발서버를 가상머신으로 관리하나? ㅡ_-)? 그러고보니, 전에 몇번 그랬던 적은 있다.
  • 관련 정보
    • 작성자 : @mitchellh
    • 오픈소스 MIT 라이센스
    • Ruby로 작성됨
    • 현재 1.0.5
    • 사용OS : ubuntu 12.04까지 나왔심.
  • Vagrant Command Line Interface
    • package : 지금까지 구성된 인스턴스를 vox로 만들어서 배포
    • halt : shutdown
    • provision :
    • up : start!
  • 실행방법
    1. vagrant box add <config.vm.box name> http://files.vagrantup.com/<box-image>.box
    2. vagrant init <config.vm.box name>
      • 선택적으로 config.vm.box 에 지정되는 value를 지정할 수 있다.
      • <config.vm.box name>을 지정하지 않으면 base로 기본등록된다.
      • 이 명령이 실행된 위치에 Vagrantfile 라는 설정파일이 생성된다.
    3. vagrant up : 실행!!

      Bringing machine ‘default’ up with ‘virtualbox’ provider…
        [default] Setting the name of the VM…
        [default] Clearing any previously set forwarded ports…
        [default] Creating shared folders metadata…
        [default] Clearing any previously set network interfaces…
        [default] Preparing network interfaces based on configuration…
        [default] Forwarding ports…
        [default] – 22 => 2222 (adapter 1)
        [default] Booting VM…
        [default] Waiting for VM to boot. This can take a few minutes.
        [default] VM booted and ready for use!
        [default] Configuring and enabling network interfaces…
        [default] Mounting shared folders…
        [default] – /vagrant
        ihoneymon:vagrant ihoneymon$

      • 실행이 완료된 후 vagrant ssh 를 입력하면 실행된 가상머신에 터미널로 접속가능하다.
      • port forwarding : 22 => 2222
    4. vagrant halt : 가상머신 끄기
  • 기타명령
    • package
      • vagrant package –help
        • VirtualBox에 이미 등록되어 있는 가상머신을 vagrant box로 패키징하여 바이너리 파일로 만들어 배포가능하도록 만든다.
      • vagrant package –base vagrant_1368646716 –output ubuntu-lucid32.box
        • ubuntu-lucid32.box
    • vagrant package 로 box 만들기

      • vagrant package –base vagrant_1368621809 –output ubuntu-lucid32.box

      ihoneymon:temp ihoneymon$ vagrant package –base vagrant_1368621809 –output ubuntu-lucid32.box
        [vagrant_1368621809] Clearing any previously set forwarded ports…
        [vagrant_1368621809] Creating temporary directory for export…
        [vagrant_1368621809] Exporting VM…
        [vagrant_1368621809] Compressing package to: /ihoneymon/temp/ubuntu-lucid32.box
        ihoneymon:temp ihoneymon$ ls
        vagrant_lucid32.box

      package로 생성한 ubuntu-lucid32.box를 test라는 이름으로 추가하고 확인

      • vagrant box add test ./ubuntu-lucid32.box

      ihoneymon:temp ihoneymon$ vagrant box add test ./ubuntu-lucid32.box
        Downloading or copying the box…
        Extracting box…te: 200M/s, Estimated time remaining: –:–:–)
        Successfully added box ‘test’ with provider ‘virtualbox’!
        ihoneymon:temp ihoneymon$ vagrant box list
        lucid32 (virtualbox)
        test    (virtualbox)
        ihoneymon:temp ihoneymon$


Chef

  • vagrant up 실행시 최초실행되는 매크로(간단하게 말하면, 스크립트를 조건에 맞춰서 자동실행하는 것이랄까?
  • 운영체제에 종속적인 편이다.
    • 스터디 중에 능력자가 운영체제를 식별하여 실행환경에 맞는 명령을 수행하는 것이 하지 않을까 하는 이야기를 나누었지만, 그런 수고스러운 삽질을 하는 것을 권장하고 싶지는 않다. 운영체제에 맞춰서 작성하면 간결하고 깔끔하겠다는 개인적인 생각을 했다.
  • Chef Solo Provisioning
    • Chef Server 없이 미리 opscode-cookbooks organization 에서 설정하려고 하는 운영체제에 맞춰서 receipe를 내려받은 후 가상머신 실행 후 추가명령 실행을 지원하는 기능이다. 이걸 잘 설정해두면, 여러 개의 인스턴스를 만들어서 실행할 때, 서버의 업데이트 상태를 최신상태로 갱신하고 사용하는데 필요한 패키지를 설치하도록 만들 수 있다.


참고자료



나는 웹 애플리케이션 개발자이기 때문에 운영체제를 몰라도 된다?


  모든 프로그램은 운영체제를 기반으로 하여 동작한다. 운영체제는 플랫폼이다. 최근에는 웹과
  운영체제에 대해서 이해를 함으로 인해서 프로그래밍을 할 때, 운영체제의 오류에 빠져드는 실수를 회피할 수 있는 가능성이 높아진다.


  자바는 운영체제에서 실행시킨 JVM(Java Virtual Machine)에 의해서 바이트 코드를 실행하기 때문에 운영체제의 영향을 받지 않는다고 알려져 있다(운영체제마다 약간의 차이는 있다는 생각이 들지만, 코딩하는 중에는 윈도우, 리눅스, 유닉스 에서 큰 영향은 없었다. 통합된 빌드과정과 웹서버에 코드를 배포하고 웹서버에서 구동시키는 형태였으니 그랬겠지만…).
 
  프로그래머가 직접 운영서버에다가 빌드를 하게 되는 경우가 얼마나 될까? 외부에서 접근이 가능한 서버라면 통합빌드 환경을 구축해두고서 원격배포를 할 수 있으니 크게 신경쓸 것이 그리 많지가 않다(SSH, FTP 접속, 웹서버의 설치 위치 확인, 스크립트 작성… 또 뭘 신경써야 하더라?).
  이전 프로젝트에서는 개발빌드환경을 신경쓸 필요가 없었다. 아키텍트가 개발에 필요한 웹서버 및 빌드환경을 구축해주고 알려줬기 때문에 이런 것들을 신경쓸 필요가 없었다. 로직과 기능을 개발하고 커밋하고 개발서버에서 빌드를 누르고 오류가 발생했는지 지켜보다가 정상빌드되며 개발서버에서 내가 구현한 기능이 정상동작하는지 확인하면 되었다.


  최근 공공기관에서 수주한 작은 SI프로젝트를 하면서 직접 리눅스LINUX(Redhat 6.0 Enterprise) 서버 콘솔Console로 접근해서 톰캣 서버(Tomcat 6.0)를 설치하고 jar파일을 복사하는 등의 일을 하면서 느끼는 거지만 프로그래머는 단순히 코딩만 하는 것이 아니라 운영체제를 충분히 알고 있어야 한다는 것이다. 어디가서 '리눅스 좀 씁니다, 요즘은 유닉스(맥북의 맥OS가 Unix 기반이니까)도 좀 씁니다.' 라고 이야기 했지만, 운영서버에 집접 배포본(.war)을 설치하고 구동시키는 것은 만만치가 않았다. 그나마 운영서버들이 모두 GUI를 제공했기 때문에 내가 운영체제를 쓰던 그대로 사용할 수가 있었다.


  리눅스 운영체제에서 애플리케이션이 설치되는 위치, 로그파일 생성 위치와 배포본의 압축해제 위치 등을 주의깊게 본 적이 없었는데, 이번 프로젝트를 하면서 깨달은 바가 좀 있다.
  물론 나 혼자였다면 훨씬 더 많은 시간을 들여야 했겠지만 곁에서 알려주시는 멘토가 있으셨기에 훨씬 수월하게 일을 처리할 수가 있었다. 우리 회사에서 진행하는 솔루션들도 이런 과정을 직접 프로그래머가 진행해야할 상황이 될 가능성이 높으니 이런 경험은 성장을 위한 좋은 밑거름이 되지 않을까?


  '프로그래머라면 자신이 사용하는 개발환경의 운영체제를 스스로 구축하고 사용하는 것을 피하지 않아야 한다.'고 생각한다. 꽤 많은 시간이 소요되는 작업이지만, JDK가 어떻게 설치되고 JDK_HOME의 위치가 어떻게 설치되는지, 경로를 설정할 때 ';'(윈도우)을 써야하는지 ':'(리눅스, 유닉스)을 써야하는지는 알아야 하지 않을까?

  1. 이 글을 쓰기 '무.섭.게' 개발서버에 임의적으로 설치한 오라클 서버 때문에 개발서버 접근이 안되는 문제가 생겼다.
    ... 그리고 그 문제가 생긴 원인을 찾고 응급조치를 하는데 너무 오랜 시간이 걸렸다.

    어설프게 배우면 안된다.

ubuntu_logo.png

오늘(2011/03/23) 개발자분들과 번개로 만나 이런저런 이야기를 엿들은(?) 뒤, 집으로 돌아오는 길에 문득 떠올라 이렇게 첫 페이지를 시작한다.

우분투(Debian Linux 기반의 배포용 리눅스 운영체제, 무료)를 기반으로 해서 개발환경을 구축하고 사용하기가 편해진 요즘,

여기저기 흩어져 있는 내용들을 정리할 겸해서 정리를 해보려고 한다.

 

  1. Ubuntu 설치
  2. 한글 설정, 폰트 설정
  3. JDK 설정(Path 설정)
  4. eclipse, STS (IDE)설치
  5. Trac, Maven, Subversion 설치
  6. 안드로이드 개발환경 구축
  7. Python 개발환경 구축
  8. Qt 개발환경 구축

이 글은 스프링노트에서 작성되었습니다.

+ Recent posts