Cloud Foundry Version 2, Bosh 설치 중 드는 생각……..

cf2 오픈 소식을 듣고, 원래 하기로 했던 Tomcat 7 작업이 영 손에 잡히지 않아 cf2 설치를 하고 있다.

한참 cf2 bosh 설치하는 와중에 드는 생각은, BOSH 같은 툴체인도 좋지만 기본적으로 Component별 수동으로 설치할 수 있는 가이드도 넣어주면 안되는걸까?

내 괴랄한 취향 때문인지는 몰라도 뭘 하든지 기본적으로 직접 설치하고 관리하는 법부터 알고 난 뒤 자동화 툴을 쓰는 것을 좋아하는데(수작업 방법은 나중에 까먹더라도, 그 과정에서 배우는 것들이 더 중요하다고 본다.), 이렇게 자동화 툴만 턱 나와있는 복잡한 시스템을 보면 가치관의 충돌로 혼돈에 빠져버린다. 당장에 쓰기는 편리하지만, 세세한 내부의 작동모습은 알기 어려워지기 때문일까? 아님, 툴에 의존되기 싫은 반감 때문인가?

결국 이래나 저래나 각 컴포넌트별 설치 요소들을 정확히 알려면, 자동화 툴을 다 설치하고 내부 스크립트들을 까봐야하는데, 이게 은근 진입장벽이 높은것 같다. 스크립트 몇줄을 보기위해 자동화 툴을 연구해야하는 배보다 배꼽이 커지는 뭔가 거인거인 열매를 먹은 야크 털 깍는 상황이랄까…..

게다가 클파는 너무 많은 컴포넌트들이 엮어져 있다. 툴 체인으로 설치하면 쉽고 편리하고 좋다 이렇게 생각하겠지만, 이런 시스템일수록 툴체인이 꼬이면 답이 안나오기 마련, 처음부터 잘 알고 들어가는게 운영측면에서는 이득이라고 본다.

무엇보다도 이런 거대한 시스템을 내부 구조와 library 관계도 모른체 자동화 툴에 의존해서 돌리는건 뭔가 불안하다.

무엇보다 VCAP에 한번 데였던 기억 때문에 BOSH에 신뢰가 잘 가지 않는 부분도 작용하는것 같다.

Cloud Foundry Version 2 오픈 3일전, 찾아오는 번뇌…

http://www.cloudfoundry.com/

지난 5월에 오픈한다고 해놓고 안하고 있어서 나를 애태우던 Cloud Foundry Version 2가 드디어 6월 10일날 오픈한다는 소식을 들었다. 공식 사이트는 이미 연초부터 cf2용으로 바꾸어놓은지 오래고, cf1은 deprecated가 선언되어 cf1에 많은 Risk를 느끼고 있떤 나에게는 희소식이다. 그리고 이미 나 스스로 cf1의 구조적 한계(?)를 느끼고 이런저런 문제점들로 골치가 아픈 와중에 cf2에서는 이 문제점들이 구조적으로 자연스레 해결될 것으로 보여 더욱더 기쁜 소식이 아닌가 한다.

문제는, 지금 진행하고 있는 일이 cf1 기준으로 일정을 잡아놨다는 거…
cf2로 빨리 갈아타고 싶은데, 그럼 일정 계획을 다시 잡아야 할거 같다.

핡! cf2로 다 바꿔버리고 싶어!

SCP – 리눅스 원격 파일 전송

리눅스에는 문외한이라 서버작업중 파일 전송할 일이 생기면 매번 ftp 서버 여느라 삽질했었는데

오늘  scp라는 좋은 유틸리티가 있다는 것을 배웠다.

그간 ftp로 삽질했던 세월이 원망스럽기만 하다…….

 

아래 내용은 박난하 매니저님이 출연하신 사용법 설명……..@_@

 

15:05 박난하 [root@cf03 ~]# scp /vz/private/21/var/cache/dev_setup/ruby-1.9.3-p194.tar.gz root@target_ip:/root/sources/

15:05 박난하 scp file위치 root@원격주소:파일위치

 

좋쿤!

 

1. 기본적으로 처음 접속하면 상대편 서버의 root 암호를 물어본다고 한다.

2. rsa 키로 어떻게 하면 암호 안물어보고 쓸수 있다고 하는데, 현재 거기까지는 필요하지 않으므로 과감히 스킵!

Cloud Foundry Version1 VMC 0.5.0 버그

Cloud Foundry version 1을 사용하는 중에 이상한 현상이 발생했다.

vmc로 java_web Application을 push하면 아래와 같은 메세지가 뜨면서 앱이 아얘 업로드가 안된다.

========
Upload failed. Try again with ‘vmc push’.
TypeError: can’t convert nil into String
For more information, see ~/.vmc/crash
========

crash 내용따라 소스를 트래킹 해보니 vmc 0.5.0의 버그로 밝혀졌다.

정확히는 vmc 0.5.0의 버그라기보단 cfoundry 0.5.2의 버그다.
(혹시나 해서 google cloudfoundry developers groups에 물어보니 거기서도 버그 같다고 한다. 근데요즘 NG 만드느라 바빠서 신경 안쓰는거 같다.)

어쨋든 java_web 상관없이 Ruby든 Python이든 버그를 만나면 다 푸시가 안된다.

cfoundry 0.5.2 gem의 upload_helpers.rb를 열어보면 내부에 determine_resources()라는 메소드가 있는데, 이녀석이 원인이다.

앱을 푸쉬하는 과정에서 Application의 크기가 upload_helpers.rb에 정의된 RESOURCE_CHECK_LIMIT 보다 크면 determine_resources() 메소드가 Application의 모든 파일을 삭제해 버린다.

왜 이렇게 만들었는지 이유는 모르겠다. @_@

급한대로 RESOURCE_CHECK_LIMIT의 값을 늘려서 해결할 수 있다.

default로 64*1024잡혀있는데 64*4*1024*1024로 넉넉히 잡아주면 해결된다.

 

추가로, TypeError: can’t convert nil into String   에러는 cfoundry 에서 압축을 하는 과정에서 나는 에러인데, 앞선 과정에서 파일이 모두 삭제되었기 떄문에 발생한 문제였다.

Random tmp 디렉토리 만들기

프로그램을 만들면서 임시로 쓰고 지울 파일들은 별도로 temp 디렉토리 만들어서 사용하고 주기적으로 삭제해주곤 했는데,

최근 리눅스에서 제공하는 tmp를 활용하는게 더 좋다는걸 느끼고 활용하기 시작했다.

(역시 무식하면 용감하다고, OS에서 제공해주는 기능을 만드느라 뻘짓 하고 있었…..)

만드는 방법은 쉽다!

 

$$ mktemp -d  #리턴 값이 랜덤 디렉토리 path

 

Bash에서 에서는

 

TMP_DIR=”$(mktemp -d)”

 

로 쉽게 활용할 수 있다.

 

좀더 응용해서 자바나 루비 같은데서 시스템콜로 쓰면 될거 같다. 다만 돌아가는 OS에 따라 케이스를 나누어 주어야 하겠지만…

 

앞으로 temp 처리하느라 뻘짓하던거 안해도 될듯……

맥에서 유용한 Postgresql.app 과 pgadmin

가끔 테스트용 DB가 아쉬운 상황에서 요긴하게 쓰이고 있는

무설치(?)형 Postgresql과 pgadmin 툴

무설치형은 .app형태로 되어있어 그냥 application에만 드랍 해놓으면 된다.

DB를 써야할때 그냥 앱 켜듯이 실행하면 트레이어 뜨면서 DB가 작동한다.

pgadmin은 DBA가 아닌이상 create, select, insert, update, delete이상 알아야 할 필요가 있을까?

라는 생각을 가진 나같은 사람들에게 너무나도 고마운 Postgresql GUI Client다.

여튼 둘다 사용하기 쉽고! 편리하고!완전 좋다.

http://postgresapp.com/

http://www.pgadmin.org/