「いちいちちょっとしたViewの変更をリリースするの面倒だから、app/viewsごとS3に置いて管理できるようにしちゃえば良いじゃん」という、何ともマジかよ的な発想を実現できるGemがs3_railsです。
app/viewsを切り分けるという発想
app/views以下を切り分ける発想というのは珍しいものではなく、Crafting Rails4 ApplicationsではViewをDBで管理する方法も紹介されているようです。一方で、S3 RailsではそれをS3で管理できるようにしたよ、とのこと。
DBで管理できるようにすると、もはやそれはRailsの名を借りたCMSだよね、という感じで、むしろRails as a CMSのような使い方をしている人にはマッチするのかも知れません。
ただ更新の差分管理だとか、いろんな機能を実装する必要があると思うので、sonicgarden.jpは静的ファイル＆Gitの構成で記事を管理しています。Gitなら、Gitが差分管理してくれますからね！
S3 Railsの使い方
話はそれましたが、S3 Rails自体の使い方をざっくり紹介します。
S3 Bucketをつくる
まずはバケットがないと話にならないですね。バケットを作って、こちらのサンプルに従ってポリシーを設定しましょう。
s3_rails.ymlを作成する
config以下にs3_rails.ymlを作成します。
|
1 2 3 4 5 |
s3_rails: access_key_id: YOUR_S3_ACCESS_KEY secret_access_key: YOUR_SECRET_ACCESS_TOKEN bucket: 'bucket-name' region: 'us-west-2' |
ApplicationControllerに設定を追加する
S3で探す前にRails.root以下のviewを探索する場合は、ApplicationControllerに以下のように設定します。
|
1 |
append_view_path S3Rails::Resolver.instance |
Rails.root以下のviewを探索する前にS3上のファイルを探索する場合は以下のように設定します。
|
1 |
prepend_view_path S3Rails::Resolver.instance |
再起動＆S3Railsのキャッシュリロード
アプリケーションを再起動するのと、S3上のファイルを変更した場合はキャッシュをリロードする必要があります。
キャッシュリロードの方法はtouch tmp/s3_rails.txtするか、S3Rails::Resolver.instance.reloadを叩くかするとリロードされるようです。
一部だけS3に切り分けられるので、例えばランディングだけS3で管理するといった使い方ができそうです。