OddPoet's βetalog

Unix 환경이라면 카피스트라노(Caspistrano)를 이용하여 Rails 애플리케이션을 배포할 수 있지만, Windows 환경인 경우는 대부분의 작업을 직접 해줘야 한다. 이 포스트에서는 Windows 서버에 Apache2 + mySql + Mongrel 구성으로 Rails 애플리케이션을 배포하는 방법에 대해 설명한다.

1. Apache2 / mySql

Apache와 MySQL을 각각 설치해주는 방법도 있지만, 윈도우즈 환경에서 손쉽게 APM(Apache+PHP+MySQL)을 설치할 수 있는 APMSetup을 설치한다. (나의 경우 기존에 다른 application 때문에 APMSetup을 설치해놓은 것이 있다 보니, 선택의 여지가 없었다.)
APMSetup으로 mysql을 설치한 경우, 디폴트 설정때문에 Mongrel 서버가 죽는 경우가 생길 수 있다. 따라서 C:\APMSetup\my.ini 파일을 열어 아래와 같은 설정을 주석처리하자.

#connect_timeout = 60
#wait_timeout = 60

그리고 Http Proxying으로 백엔드의 Mongrel로 rails 요청을 보내기 위해서 C:\APM_Setup\Server\Apache\conf\httpd.conf 파일을 아래와 같이 수정한다.

# mongrel cluster
<Proxy balancer://mongrel_cluster>
    BalancerMember http://127.0.0.1:3000
</Proxy>
# rewrite rule
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]
# web root가 아니라 web서버의 /rails_app 경로에서 서비스 하려면
# 위 라인 대신 아래 라인을 추가한다. (이 경우 mongrel에 prefix 옵션을 줄것)
# RewriteRule ^/rails_app/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

# web root로 rails_app의 public 디렉토리를 잡는다.
DocumentRoot "C:/rails_app/public"
# rails app를 web root가 아닌 /rails_app 경로로 서비스 하려면
# 위 라인 대신 아래 라인으로...
#alias /rails_app "C:/rails_app/public"

<Directory "C:/rails_app/public">
   Options Indexes FollowSymLinks
   AllowOverride none
   Order allow,deny
   Allow from all
</Directory>

2. Ruby 설치

루비 공식홈페이지에서 윈도우용 원클릭인스톨러를 다운로드 받아 설치한다.
설치 후 cmd창에서 gem update 및 rake, rails, mongrel, win32-service, mongrel_service 등을 설치한다.
ruby 1.8.6 버전을 설치했다면 gem update는 해주는 것이 좋겠다. 그리고, rails 최신버전이 아닌 버전을 사용한다면 설치시 --version 옵션으로 원하는 버전을 지정해주자.

C:\> gem update --system
C:\> gem install rake
C:\> gem instal rails
C:\> gem mongrel
C:\> gem win32-service
C:\> gem mongrel_service

3. Rails Application 셋업

개발된 rails application 디렉토리를 서버로 복사하는 것도 방법이지만, 추후 재배포를 생각해서 소스리파지토리에서 checkout하는 것이 좋다. subversion의 경우 나중에 svn update 명령만으로 최신파일로 쉽게 갱신할 수 있다.
위의 예에서와 같이 C:\rails_app 라는 경로로 설치했다고 가정하고 다음 작업을 진행하자.

3.1 DB 설정

우선 rails application에서 사용할 database를 생성한 후, config/database.yml 파일의 production 모드의 DB 설정을 확인한다. 그 후 cmd창에서 해당 DB에 db:migrate 작업을 수행한다.

C:\rails_app> rake db:migrate RAILS_ENV=production

3.2 mongrel을 서비스로 등록

위에서 win32-service와 mongrel_service를 설치했다면, mongrel을 윈도우즈의 서비스로 등록할 수 있다.

C:\rails_app> mongrel_rails service::install -N "Rails APP" -e production -p 3000 -c "C:\rails_app" -r "C:\rails_app\public"

혹시 web서버의 root 경로가 아닌 /rails_app 경로로 서비스하는 경우라면, 아래와 같이 --prefix 옵션을 추가한다.

C:\rails_app> mongrel_rails service::install -N "Rails APP" -e production -p 3000 -c "C:\rails_app" -r "C:\rails_app\public" --prefix /rails_app

윈도우즈의 [제어판]-[관리도구]-[서비스]에 가면 "Rails APP"라는 이름으로 서비스가 등록되어 있는 걸 확인할 수 있을것이다. 그 서비스를 시작시키면 된다.

최근 Ruby와 Rails를 공부하고 있는데, Ruby의 Symbol이라는 게 잘 이해가 되지 않았다.
기존에 내가 배웠던 언어들 중에는 그와 비슷한게 없었던 터라 도무지 감이 안 잡혔다.
구글링 결과 대략 감을 잡았으니, Ruby Symbol의 정체에 대해 간단히 정리해본다.

String vs. Symbol

puts :hello　 #symbol
puts "hello" 　 #string

위의 두 문장 모두 'hello'라는 문자열을 출력한다. 이런 이유로 Symbol을 String의 오리타입(duck type) 클래스로 오해하기도 한다. 하지만, 아래 코드를 보면 알겠지만, Symbol은 절대로 String이 아니다.
puts :hello.size　 # NoMethodError
puts :hello[0,2]　 # NoMethodError
puts "hello".size　 #5
puts "hello"[0,2]　 # "he"

Symbol이 String의 사촌 쯤으로 오해받는 것은 Symbol을 immutable string 용도로 많이 사용하기 때문이다. 나처럼 Lisp 언어에 대한 경험이 없는 사람이라면, 대충 예제코드들을 보면서 그렇게 생각할 가능성이 매우 높다.

Java등의 언어에서는 String이 immutable Class이므로 Hash의 키로 사용했을 경우 그다지 문제될 것이 없지만, Ruby에서는 String이 mutable class이므로 Hash의 키로 쓰일 때, 키로 쓰인 객체의 값이 변경될 경우 rehash 메소드를 호출해줘야 하는 경우가 생긴다. 따라서 Ruby에서는 가능하면 Hash의 키로 String대신 Symbol을 쓰는 것을 선호한다. 그러니 나 같은 놈은 처음부터 Symbol = Immutable String 으로 이해하고는 그 뒤부터는 미궁으로 빠져버린다.

Symbol을 그 정의대로 '이름을 가진, 그리고 그 이름에 대해서 유니크(unique)한 객체'이다. String이 따옴표로 둘러쌓인 문자열로 표기되듯이, Symbol은 :name의 형태로 표기되며, name이 문자열로 표기될 수 있지만 그 자체는 String이 아닌 Symbol객체이다. 그리고 아래 코드에서 보여지듯이, 특정 이름을 갖는 Symbol 객체는 유일하다.
puts :hello.class 　 # Symbol
puts "hello".class 　 # String
puts :hello.object_id == :hello.object_id 　 # true
puts "hello".object_id == "hello".object_id 　 #false


Symbol의 용도

그렇다면 Symbol은 언제 사용하는 것이 좋을까?
Ruby의 String이 mutable 객체이므로, 성능상의 이유로 Symbol이 immutable string의 대체물로 사용되곤 하지만, Symbol은 garbage collect가 되지 않으므로 자칫하면 메모리 누수가 발생할 수 있음을 유의해야 한다. 대충 아래와 같은 용도로 사용하는 것이 추천된다.

1. 메소드의 argument list에 옵션 키워드의 이름
   link_to 'Show', :action=>'show', :id= product
2. C의 enum와 같은 값을 표현할 때
   /* C code*/
enum BugStatus { OPEN, CLOSED };
BugStatus original_status = OPEN;
BugStatus current_status = CLOSED;

# Ruby
original_status = :open
current_status = :closed
3. Hash의 키 이름
   foo = {
:host => 'localhost',
:port => 80 }
   

특히 위 3번의 예는 String을 사용하는 아래의 예보다, Symbol이 사용자 정의 식별자(user defined identifier)로 사용됨으로써 코드의 의도가 명확히 드러난다 점에서도 더 낫다.
foo = {　 # String을 사용한 경우, 속성-값의 관계가 덜 명확해 보인다.
'host' => 'localhost',
'port' => 80}

Reference

• 13 Wasy of Looking at a Ruby Symbol
• Symbols are not immutable strings
• Using Symbols for wrong reason
• Understanding Ruby Symbols