ぱろっと・すたじお

技術メモなどをまったりと / my site : http://parrot-studio.com/

レガシーなシステムでbundlerをgemインストーラーとして使う

そうすると便利ですよ

・・・以上!Σ(・ω・ノ)ノ


さすがにこれではまずいので、もうちょっと真面目に書きますが、
タイトル以上の内容は出てきません

皆さんご存じだと思いますが、Ruby1.8.7のメンテナンスは終了しています

Ruby 1.8.7 は引退しました

まして、Rails4がリリースされたこのご時世に、
Ruby1.8.7+Rails2*1のシステムなんてレガシー以外の何者でもありません*2

だからといって、実際に利益を上げているシステム*3ですし、
何か理由がない限り、作り直しする理由なんてありません*4

とはいえ、メンテナンスしやすいようにはしておきたいので、
サーバ移転のついでに、2つの施策を実施しました

  • svn -> gitへ移行
    • gitによるリリースフローが可能になったため、FTPでちまちまファイルをUPしなくて良くなる=リリースミスも減る
  • bundlerによるgemの取りまとめ
    • あくまでインストールに使うだけで、システムの動作には影響しない

前者については以前記事を書いています(´・ω・)っ

SubversionのリポジトリをGitリポジトリに移行する - ぱろっと・すたじお

で、今回はbundlerなのですが、
bundlerが正式に採用されたのはRails3の時です
Rails2の時代には、個別にgemを管理する必要がありました

なので、使っているgemとそのバージョンを資料にまとめておき、
構築時に手動でインストールするという、
「昔はそれでいいけど、今はどうなの?」的なもやもや感が(´-ω-)

しかも、最近になって大きな問題が出てきました
具体的には「composite_primary_keys」の手動インストールに失敗するのです

このgem、その名の通り複合プライマリーキーを扱えるようにするgemなのですが、
もうメンテナンスされておらず、しかも依存性が「最新のactiverecord」なのです

今まではこれでも良かった*5のですが、
現在における「最新のactiverecord」は4.0系であり、
Ruby1.8.7ではインストールすらさせてくれませんΣ(゚Д゚)ガーン

そこで、bundlerの出番です

要は「bundle install」って、「実行したディレクトリにある、
Gemfile.lockに書かれたgem一式をインストールするコマンド」です

なので、あらかじめ「Gemfile」を作って開発環境でbundlerを実行し、
適切なGemfile.lockを作っておけば、
それをサーバに持っていってbundlerを実行するだけで一発ですヽ(`・ω・´)ノ

例えばこんなのを

source 'https://rubygems.org'

# 細かいバージョンは念のため伏せます
gem 'rack', '1.x.x'
gem 'rails', '2.x.x'
gem 'composite_primary_keys', '2.x.x'
gem 'mysql', '2.8.1'
gem 'will_paginate', '2.3.15'
gem 'passenger', '<3.0' # システム自体とは関係ないが、インストールしたいgem

gem 'httpclient'
gem 'json'
gem 'net-scp'
gem 'net-ssh'
gem 'hpricot'

本来、bundlerの大事な機能として、
「使用するgemを制限する」というのがあります

つまり、システムの頭でこうやって書くあれです

### Padrinoのboot.rbより抜粋

# Load our dependencies
require 'rubygems' unless defined?(Gem)
require 'bundler/setup'
Bundler.require(:default, PADRINO_ENV)

しかし、特に仮想化全盛のこのご時世において、
「1サーバで1アーキテクチャ」というのは良くある話ですので、
今回の場合はあえて制限するためのコードを入れてません

そのサーバには各gemが1バージョンしか入っていないのと、
下手にbundlerを組み込んで、
動作がおかしくなる可能性を排除したかったので・・・

Gemfile/Gemfile.lockならシステムのコードと一緒に管理しやすいですし、
お手軽に環境を整備するための手段としておすすめです(´・ω・)っ *6

*1: しかも、prototype.jsやらrjsまで使っているという・・・(´・ω・`)

*2: とはいえ、当時はそれが「最先端」だったので、その時点での判断が間違っていたわけではありません

*3: しかもクローズドに運用されている社内システム=外部リスク極小

*4: 個人的にはRuby2.0+Rail4で、かつ設計上ミスった部分を直したいのですが、それで会社の利益が上がるわけでもなく・・・

*5: インストールした後、不要なgemを消すという手間がありましたが・・・

*6: え、Chefを使え? そこまで頻繁に構築をおこなうわけでも、多数のサーバを管理するわけでもないので、今回のシステムにはコストが高すぎます(´-ω-)