Hatena::ブログ(Diary)

ツユダクの肉増しのRuby on Railsの初心者で このページをアンテナに追加 RSSフィード

2015-10-20

使い捨てメールアドレス発行サービス作りました

| 23:34 | 使い捨てメールアドレス発行サービス作りました - ツユダクの肉増しのRuby on Railsの初心者で を含むブックマーク 使い捨てメールアドレス発行サービス作りました - ツユダクの肉増しのRuby on Railsの初心者で のブックマークコメント

http://instance-email.com/

1セッションで最大6個までメールアドレスをワンクリックで発行できます。
メールアドレスは作成から2日間利用可能で、5MBまでのメールを受信できます。
途中だるくなったり設定うまくいかなったりで制作期間2ヶ月くらいという感じです。
フロントはnginx + unicorn(Rails)でバックのメールサーバにはPostfixDovecot使いました。他にはmysql, debianで。
サーバはさくらのVPSで、 デプロイcapistranoであるあるな構成です。

f:id:jiikko:20151020233135g:image

あと、ブログを引っ越しました。以降は http://blog.jiikko.com/ で書いていきます。
http://blog.jiikko.com/

最近, Lokka => はてブロ に移動する人がちらほら見るのですが今回は逆パターンです。
自分でCMSをホストするとなると画像のアップロードどうしようか考えてます。全部base64エンコードして本文に含めたらポータビリティとか思ったり。

2015-09-07

デプロイツール

| 21:48 | デプロイツール - ツユダクの肉増しのRuby on Railsの初心者で を含むブックマーク デプロイツール - ツユダクの肉増しのRuby on Railsの初心者で のブックマークコメント

capistranoロールバックできるし一通りシムボリックリンク貼ってくれたりでだいたいのことはカバーしてれくるので導入コストはかかるが便利なんだけど、
railsデプロイするために必要な周辺gemの調査が毎度めんどい。

思えばcapstrano2 => 3の時もめんどかった。cap2系はrailsにフォーカスして作られていたので必須gemほとんどなかったんだけど,
3系からrvm, bundlerあたりが別のgemに切りだされて、railsアプリをデプロイするにはcapistrano-rvm, capistrano-bundlerあたりが必要になった気がする。

それで、半年ぶり新しいcapを使おうと思ったらrvm周りのgemが謎な名前になってるじゃん。

https://github.com/rvm/rvm-capistrano
https://github.com/rvm/rvm1-capistrano3

READMEに書いていた。

rvm-capistrano 1.3.0 with Autolibs requires at least RVM 1.19.0.
capistrano 3.0.0 is a rewrite and does not work with this gem, use rvm1/capistrano3 it will be extended to match this gem functionality.

代謝するものだし仕方ないのかなと思いつつ、古いバージョンを使うのも嫌なので仕方なく今のcapistranoについて調べているところ。

まとめ

capistarano捨てて自家製秘伝のタレshellスクリプトデプロイしよう!

2014-07-26

capistrano2を3にした

| 15:04 | capistrano2を3にした - ツユダクの肉増しのRuby on Railsの初心者で を含むブックマーク capistrano2を3にした - ツユダクの肉増しのRuby on Railsの初心者で のブックマークコメント

rails (4.1.2)
capistrano (3.2.1)
capistrano-bundler (1.1.2)
capistrano-rails (1.1.1)
capistrano-rvm (0.1.1)

cap2とcap3でデプロイコマンドは若干違ってる。(3は:migrationsがいらない。)
今自分は2と3を使っているプロジェクトをそれぞれやっており、
プロジェクトによってデプロイコマンドが変わることにストレスを感じていたのでアップグレードしようと思った次第。

アップグレードは下記記事を参考にと、cap3で動いているコードを見た感じ。
http://capistranorb.com/documentation/upgrading/

詰まったところ

エラーメッセージが不親切

cap2構文との互換性が一切ないので素のスタックトレースが出てくる。

unicorn

アプリケーションサーバのpidを置くファイルパスが間違ったまま今まで運用していて(cap2では動いてた)、cap3にした時にunicornをupgradeできないということがあった。

Couldn't upgrade,  starting 'bundle exec unicorn_rails -E production -D -c 

初期化スクリプトでは、APP_ROOT/shared/tmp/pids/unicorn.pid
unicornの設定ファイルでは、APP_ROOT/current/pids/unicorn.pid (tmpディレクトリがない)
というようなパスで書いいてこのままpidsファイルをshared配下に置く設定にすると、シンボリックリンクが噛み合ないことになってた。
本番サーバでのアップグレード作業時は、サーバが停止しないようpidsファイルを正しいパスにコピーしてunicornのupgradeが動くようになった。

linked_dirs

linked_dirsに相対パスを指定するとshared配下にシンボリックを貼ってくれる便利機能がある。
そして既にあるディレクトリを指定すると中身が消滅する。

public/system

のシンボリックリンクを貼る時は退避を忘れずに......。
<追記>
sheredへのシンボリックリンクのパスが2と3で変わってる。

はやい

tmp以下をshared配下におくようにしたのでprecompileが必要なものだけすようになったっぽくて早くなった。
(assetsの量によるけど)5分かかっていたのが1分でデプロイが終わるようになった。

まとめ

バージョンあげると浄化される。

2014-07-19

サーバかえた

| 12:36 | サーバかえた - ツユダクの肉増しのRuby on Railsの初心者で を含むブックマーク サーバかえた - ツユダクの肉増しのRuby on Railsの初心者で のブックマークコメント

少し前までぺろぺろあんてな某レンタルサーバで動かしていたんだけど、サーバがまともに稼働していなかったので一昨日くらいにVPSへ戻した。

サーバがまともに稼働していない

先週の21時あたりからぺろぺろあんてながずっと503を返していることがあって調べたんだ。
ぺろぺろあんてなは、登録しているRSSを参照して未Insertの記事があったらInsertする処理を定期実行している。(なお、削除処理は実装していない。)
その記事レコードが多くなってMySQLで詰まってるかと思ったら関係なくて、
サーバがクソ重いせいでunicornがnginxにレスポンスを返すところでタイムアウトになってたっぽい。
見るとサーバのロードアベレージが100以上の状態が続いていた。

それとついでにprpr-antena.comのドメインをroute53に乗り換えた。

まとめ

capistrano便利。

2013-11-17

capistrano3使ってみた

| 13:26 | capistrano3使ってみた - ツユダクの肉増しのRuby on Railsの初心者で を含むブックマーク capistrano3使ってみた - ツユダクの肉増しのRuby on Railsの初心者で のブックマークコメント

3へのだいたいの変更点

setメソッドで定義した値を読むには、fetchメソッドを使う
capistrano-extがデフォでサポート
自作タスクの構文がかわった

今までdeploy:migeationsと実行していたmigrationタスクは、
cap production deployで一緒に実行されるようになってるみたい。

自作タスク定義の構文がかわった

2.x
namespace :deploy do
  desc "update database config file(database.yml) from database.release"
  task :update_databaseconfig, :roles => :app, :except => { :no_release => true } do
    run "cp #{release_path}/config/#{database_yml} #{release_path}/config/database.yml "
  end
  before 'deploy:finalize_update', 'deploy:update_databaseconfig'

  task :restart, :roles => :app, :except => { :no_release => true } do
    run "sudo service #{unicorn_service_name} upgrade"
  end
end
3.x
namespace :deploy do
  task :updated_database_config do
    on roles(:app) do
      within release_path do
        execute :cp, "config/#{fetch(:database_yml)}",  "config/database.yml "
      end
    end
  end
  before 'assets:precompile', 'updated_database_config'

  task :restart do
    on roles(:app), in: :sequence, wait: 5  do
      execute "sudo service #{fetch(:unicorn_service_name)} upgrade"
    end
  end
end

withinはディレクトリがあればブロックを実行するようです。すごく非直感的、、。
inオプション後で調べる。
set :linked_filesが便利らしい....

ハマたったところ

今まで使っていた/etc/init.d/unicorn_init.shで upgrade start stopができない問題に直面。

/var/www/antena/shared/bundle/ruby/2.0.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:193:in `pid=': Already running on PID:10475 (or pid=/var/www/antena/shared/pids/unicorn.pid is stale) (ArgumentError)

2.xだとunicornのpidsファイルは次のパスに置かれていたのだけど、3から置かれなくてなってた。
unicorn_init.shはcurrent/tmp/pidsを見ていたのでエラーになってたみたい。

/var/www/antena/current/tmp/pids

unicorn_init.shに定義しているpidsファイルを場所をshared配下に変更して解決。

ソース

Capfile
# Load DSL and Setup Up Stages
require 'capistrano/setup'

# Includes default deployment tasks
require 'capistrano/deploy'

require 'capistrano/rvm'

require 'capistrano/bundler'
require 'capistrano/rails/assets'
require 'capistrano/rails/migrations'

# Loads custom tasks from `lib/capistrano/tasks' if you have any defined.
Dir.glob('lib/capistrano/tasks/*.cap').each { |r| import r }
config/deploy.rb
set :user, 'jiikko'
set :use_sudo, false
set :application, 'antena'
set :scm, :git
set :repo_url, 'git@bitbucket.org:jiikko/antena.git'
set :branch, "master" # どのブランチをデプロイするか
set :git_shallow_clone, 1 # 1つ前のコミットまでとる
set :deploy_via, :export  # .git/のできるかできないか
set :app_name, 'ぺろぺろあんてな'
set :unicorn_service_name, 'antena_unicorn'

namespace :deploy do
  task :updated_database_config do
    on roles(:app) do
      within release_path do
        execute :cp, "config/#{fetch(:database_yml)}",  "config/database.yml "
      end
    end
  end
  before 'assets:precompile', 'updated_database_config'

  task :restart do
    on roles(:app) do
      execute "sudo service #{fetch(:unicorn_service_name)} upgrade"
    end
  end
end

after :deploy, 'deploy:cleanup'
config/deploy/production.rb
# -*- coding: utf-8 -*-
set :deploy_to, "/var/www/antena"
set(:app_uri, 'http://prpr-antena.net/')
set(:env, '本番')
set :branch, "master"
set :rails_env, "production"
set :migration_role, 'db'

set :database_yml, 'database.yml.production'

server "133.242.187.194", user: 'jiikko', roles: %w{web app db}

実行時間

2.x

27.73 real 0.79 user 0.19 sys

3.x

36.58 real 1.40 user 0.33 sys
時間かかってる、、、。

移行の感想

自作タスクの書き換えが気持ち大変だった感。
実行中のログはわかりやすくなってる。
2.xだとdeploy.rbがカオスだった気がするけど3はだいぶ整理された気がする。


ということで ぺろぺろあんてなcapistrano3でデプロイしています!

参考記事

http://blog.huangzhimin.com/2013/11/02/upgrade-to-capistrano3/
http://takkkun.hatenablog.com/entry/2013/10/12/Capistrano_3%E3%81%B8%E3%81%AE%E6%89%8B%E5%BC%95%E3%81%8D
http://qiita.com/satococoa/items/9b0cc416ffc042680b9b
http://www.capistranorb.com/2013/06/01/release-announcement.html