SinatraからPadrinoへのお引越し
今回のお話はVOYAGE GROUP エンジニアブログ : Advent Calendar 2012の12/22のエントリーとなります。
Advent Calendarを書くのは初めてですが、大掃除や正月をゆっくり過ごすためのお話は既に出されていたので、年末らしい話!と考えるのはやめました。
じゃあ、なんの話にするかと悩みましたが、ここ最近久しぶりに戯れているRubyのお話にします。
Rubyといっても広いので、今回はSinatraと今年になって知ったPadrinoという2つのフレームワークについてのお話にします。
Sinatraは知っている方も多いかもしれませんが、Rubyの軽量フレームワークです。
PadrinoはSinatraをベースにしつつも、LoggerやORMをとりこんだ、こちらも軽量フレームワークです。
実のところ、SinatraはRubyで一番最初に触ったフレームワークですが、Padrinoを知ったのは今年になってからです。きっかけは、@bash0C7 からの"Padrinoいいですよー"という一言でした。
Shibuya.rbでも何回か話にあがり、VGでは実際にプロダクトの開発でも使用されています。
既存のSinatraアプリをPadrinoアプリに置き換えてみたいけど、できるのかな?という単純な興味が発端となり試してみたらできたので、そのやり方を紹介させていただきます。
まず、Sinatraアプリを作ります。今回はBundlerを利用します。
gem install bundler
mkdir voyage_advent_calendar_2012
cd voyage_advent_calendar_2012
ここからがアプリの作成です。 まずはGemfileを用意します。
# Gemfile
source :rubygems
gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git"
Gemfileに記入されているSinatraを入れます。
bundle install --path gems
次はmy_app.rbの準備です。
# my_app.rb
require 'sinatra/base'
class MyApp < Sinatra::Base
get '/' do
'Hello Sinatra!'
end
run! if app_file == $0
end
これでもう準備は整いました。
後はたった一行のコマンドを打つだけで動きます!
bundle exec ruby my_app.rb
http://localhost:4567/ にアクセスしてHello Sinatra!が見えたら、作成成功です。
さて、ここまでだとSinatraのREADMEの最初の数行とかわりありません。
よくある話ですがアプリは動かし始めると、だんだん要求が増えてきます。
SInatraは最初に書いた通り軽量フレームワークなので、もしかしたら物足りなくなるかもしれません。
自分で不足分だけ補っていくのはそれはそれで楽しいですが、 Sinatraでは物足りない部分をさくっと補いたくなります。
そんな時に便利なのがPadrinoです。
Padrino is a ruby framework built upon the Sinatra web library. Sinatra is a DSL for creating simple web applications in Ruby.
という説明の通り、ベースにはSinatraがあり、ちょっとアプリが複雑になってきて、 Sinatraだと物足りたくなったら、こちらに乗り換えると、物足りない部分がさくっと補われます。
え、フレームワークの乗り換えなんて面倒、と思いきや、そうでもないです。 SinatraのREADMEの最初の数行を読むのと同等の気力でどうにかなります。
まずはPadrinoを入れる準備をします。 先程同じようにGemfileを編集します。この際、Sinatraの部分は削除してしまいます。
# Gemfile
source :rubygems
gem 'padrino', :git => "git://github.com/padrino/padrino-framework.git"
不用となったgemをばさっと削除して、必要なものだけ入れ直します。
rm -rf gems
bundle
Padrinoを入れたところで、次はPadrinoプロジェクトの作成です。 generateタスクが用意されているので、コマンド一行でプロジェクトのテンプレートが作成されます。
bundle exec padrino g project ../voyage_advent_calendar_2012 -n my_app
#conflict Gemfile
#Overwrite /your_app_path/Gemfile? (enter "h" for help) [Ynaqdh] Y
Gemfileがコンフリクトした!というメッセージが出てきます。 手元にあったGemfileとPadrinoが作成しようとしているGemfileが同じファイルだからです。 ここでは何も考えずYを押します。
さて、Padrinoは自分で必要となるgemが記入されたGemfileを用意してくれました。 先ほど同様、追記されたであろうgemを入れます。
bundle
これでPadrinoを動かす準備はできました。 後は、自分が作ったアプリケーションのコアファイルを移動し、 Sinatraを呼び出している部分をPadrinoに変えるだけです。
mv my_app.rb app/app.rb
# my_app.rb
class MyApp < Padrino::Application
get '/' do
'Hello Padrino!'
end
end
これでPadrinoへの載せ替えは終了です。
最後に、Padrinoを起動させます。
bundle exec padrino start
http://localhost:3000/ にアクセスしてHello Padrino!が見えたら、引越し成功です。
ということで、年末とは関係ないSinatraからPadrinoへのお引越し話でした。
明日は@hironomiuのエントリーです。
Gitlabを試してみる
昨年度GitHubのEnterprise版を試した感想のようなものをGitHub Enterpriseを試してみるにまとめた。
年が明けてからは、EnterpriseではなくOSSのGitHub、というか、Gitのホスティング管理ソフトウェアGitlabを試してみた。
GitHub上でソースコードが公開されていて、インストール関係の作業をshにまとめたものも公開されている。
個人的にはGitHubでのprivateリポジトリでプロダクトを管理している会社も多いのではないかと思う。
Businessプランとして提供されているものは最安コースだと$25、月3000円に満たないので、さほど大きくないPJやチームでは、SCMサーバの運用費よりも安く、手軽に使えると感じてこのコースを選ぶケースが多そうだ。
会社全体でSCMの主流をSVNからGitに据え、規模が大きくなるとGitHub Enterpriseという選択肢も出てくる。
ただ、GitHubはprivateなものは有料、畑は違うけれどプロジェクト管理ソフトウェアのRedmineのようにOSSの提供はされていない。
金銭面的な理由でとことんローコストを貫きたい、あるいは中身を自分達でカスタムしたいなら、GItHubのOSSに手を出すことになると思う。
ということで、一度は触ってみようと思い立ち、GitLabを試してみることにした。
環境構築
マシンのセットアップに使ったもの
VirtualBoxのインストール手順は割愛する。Vagrantのインストールを行いBase Boxesと呼ばれるVirtualBoxで使えるOSのtemplateを使用して、サーバを構築する。
$ gem install vagrant $ vagrant box add ubuntu-1110-server-amd64 http://timhuegdon.com/vagrant-boxes/ubuntu-11.10.box $ vagrant init ubuntu-1110-server-amd64 $ vagrant up
Ubuntuを選んだ理由は、Gitlabのページに書かれている通り、GitlabのofficialサポートのOSはUbuntuかDevianだから。
Fedora、CentOS、Red Hastでも稼働し、Mac OS X、FreeBSDでも動かせるけれど、今回は環境を縛る条件がなかったので、公式サポートを名言されているUbuntuを選択した。
インストール
遊び場ができたので、後はGitlabのインストール。ここで選択肢が二つある。
一つは、手動セットアップ、とはいってもWikiに公開されている手順を踏んでいくだけで、すんなり入る。
もう一つは、上記のセットアップ手順をshにまとめたものがGitHub上で公開されているので、そちらを使うこと。
最初は手動でセットアップして、その後にインストールshを使ってやってみた。
後は、Passengerで動かすのと、Passenger×Nginx、Unicorn×Nginxで動かすのをそれぞれ試してみたくらい。
Unicornを選ぶ理由としては、再起動時にダウンタイムを限りなく0に近づけられるから。
正直SCMサーバとして使う上では、使うユーザ数を考慮すればパフォーマンスの理由でApplication ServerやHTTP Serverを悩む理由はなさそう。
また、手動セットアップとインストールshでは細かい違いはあるけれど(インストールshの方では、システムユーザとしてnginxというアカウントを追加する)、
基本的な動きはほぼ同じ。ただ、Gitlabのバージョンやブランチを細かく指定したいなら、インストールshをいじらないといけない。
さらに付け加えるなら、インストールsh内部でユーザの追加やpythonのインストールなどもしているので、一度は手動セットアップするか、インストールshの中身をじっくり見た方がよい。(とはいっても、この手の作業をする人でshの中身を見ない人はいないと思う)
詰まりどころ
- よくWebでも書かれているのはPermissionの設定ミス
Gitlab内に登録されたリポジトリは、/home/git/repositories/以下に配置されるので、Gitlabを起動しているユーザにここへの書き込み権限がないといけない。
- SSH鍵による認証
Gitのリポジトリ書き込みは原則としてSSHによる認証。このため、GItlabを起動しているユーザは、鍵認証情報を保持している必要がある。
- Nginxを使う場合のNginxの起動ユーザ
NginxのWorkerプロセスを立ち上げているユーザもGitlabを起動しているユーザと同様に、というか、Gitlabを起動しているユーザがWorkerプロセスを立ち上げる必要がある。
いくつかはまる部分はあるけれど、半日もあればGitのホスティングサーバがセットアップできる。更新も定期的に行われているので社内でGitのホスティングサーバを無料で立てたいというのにはおすすめだと感じた。
ただ、最終的に常日頃から使いなれたGitHubと比較すると、どうしても使いづらいという感覚が拭えない。Redmine/Trackのように目的は同じだけどUIは全然違う、ではなく、目的は同じでUIも似通った感があるせいか、逆に違和感が払拭できない。
まあ、最終的には使いたいものを使えばいいと思ったのと、Railsアプリを公然と使えて楽しめたからいいやー、という結論に落ち着いた。