rails+unicornで特定のサーバーだけ異なる設定でunicornを起動する
production環境においてappサーバーと管理画面を同居させていた場合、unicornやnginxの設定を同一のものにしなくてはいけない制限が生まれてしまう。
今携わっているプロジェクトで、通常のappサーバーでタイムアウトを30秒に設定しているため管理画面から行う特別重い処理がタイムアウトが発生して満足に使えない状況が発生した。
このため管理画面を別サーバーに切り出す対応を行ったが、unicornの設定に少しだけ手こずったのでメモ。
task :set_unicorn_config_path do roles(:admin) do |host| set :unicorn_config_path, -> { File.join(current_path, "config", "unicorn", "admin.rb") }' end end before 'unicorn:start', :set_unicorn_config_path
対応内容は上記のみなのだけど、 capistrano3_unicorn
の unicorn.rake
における unicorn:start
にフックしてproductionのみ set_unicorn_config_path
タスクを実行するようにした。 role :admin
に指定したインスタンスは、別のunicornの設定ファイルをつかうことができる。
unicorn:restartからもinvokeされるので、結果 deploy:restart
からでも実行され、
cap deploy
でも cap unicorn:restart
でも上記タスクは実行される。助かる。
The theory of everythingを観た
職場の人にオススメを聞いてこの映画を観た。 残念ながら日本語に疎いので的確な表現が思いつかずにいる。
とりわけ評価するべき点としては、 主演のエディ・レッドメインとフェリシティ・ジョーンズの演技が映画の世界観に入り込むのに最大限の手助けをしてくれた。
個人的にはもう少し宇宙理論の話を掘り下げて欲しかった。原題の「The theory of everything」が「博士と彼女のセオリー」と訳される程度にはヒューマンドラマ、とりわけ「愛」にフォーカスした映画だ、という事前情報を得てから観ればそうは思わなかったのかもしれない。 演出も綺麗で、名作映画を見終わった後特有の余韻感を感じることができたので、ともすれば自分の中では「名作映画」のリストに入るのだろうな。
migration comment gemを使っていたらtableのROW_FORMATがCompactになって困った
何があった
my.cnf
にてinnodb_large_prefix = ON, innodb_file_format = Barracuda
であるのにvarchar(255)
カラムに対する unique index付与時Specified key was too long; max key length is 767 bytes
で怒られるinnodb_large_prefix = ON
なのにlarge_prefix
が有効にならないということは、ROW_FORMAT=DYNAMIC
でないとアタリをつけ検証したところ、確かにDYNAMIC
でなくCompact
になっていることが判明- 同migrationファイルを用いてstaging環境で実行すると、意図通りmigrationは実行されindexも付与される。
詳細
絵文字対応を行うためutf8でなく1文字4byteのutf8mb4エンコードでDB運用を行う場合、767byteまでしかindex column lengthを許容していないmysqlの仕様上varchar(255)のカラムに普通にindexを貼ることは出来ない。これに対応するためには、
- mysqlの設定で
innodb_large_prefix
を有効に - tableの設定で
ROW_FORMAT=DYNAMIC or COMPRESSED
に
する必要がある。 参考
このうち後者に関しては
ActiveSupport.on_load :active_record do module ActiveRecord::ConnectionAdapters class AbstractMysqlAdapter # utf8mb4 を使用するため index のサイズを拡大したい。 # そのために必要な設定です。 # @see config/database.yml def create_table_with_innodb_row_format(table_name, options = {}) table_options = options.reverse_merge(options: 'ENGINE=InnoDB ROW_FORMAT=DYNAMIC') create_table_without_innodb_row_format(table_name, table_options) do |td| yield td if block_given? end end alias_method_chain :create_table, :innodb_row_format end end end
のようにモンキーパッチを当てて対応を行っている。
だが、ローカル環境においてのみ上記のモンキーパッチによって付与されるはずの ROW_FORMAT=DYNAMIC
が正しく有効にならず、作られるテーブルは Compact
になっていることを発見した。
デバッグしたところ、何故かローカルではモンキーパッチ部分の引数にデフォルト値のようなものが渡されてしまい、意図せぬ挙動になってしまっていた。
development環境とstaging環境において挙動が変わる→development環境にのみ使用しているgemが怪しいとアタリをつけ調査を開始した。
調査
staging環境におけるデバッグ
From: ***/server/config/initializers/model_ext.rb @ line 193 ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format: 191: def create_table_with_innodb_row_format(table_name, options = {}) 192: binding.pry => 193: table_options = options.reverse_merge(options: 'ENGINE=InnoDB ROW_FORMAT=DYNAMIC') 194: create_table_without_innodb_row_format(table_name, table_options) do |td| 195: yield td if block_given? 196: end 197: end 2.1.5 (#<ActiveRecord::ConnectionAdapters::Mysql2Adapter:0x007fe2a9ae94d8>):0 > show-stack when_started hook failed: NoMethodError: private method `eval' called for nil:NilClass ***/server/vendor/bundle/ruby/2.1.0/gems/pry-stack_explorer-0.4.9.1/lib/pry-stack_explorer.rb:109:in `bindings_equal?' (see _pry_.hooks.errors to debug) Showing all accessible frames in stack (34 in total): -- => #0 create_table_with_innodb_row_format <ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format(table_name, options=?)> #1 [block] block in run <Byebug::PryProcessor#run(&_block)> #2 [method] run <Byebug::PryProcessor#run(&_block)> #3 [method] resume_pry <Byebug::PryProcessor#resume_pry()> #4 [method] at_line <Byebug::PryProcessor#at_line()> #5 [method] at_line <Byebug::Context#at_line()> #6 [method] create_table_with_innodb_row_format <ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format(table_name, options=?)> #7 [method] create_table <ActiveRecord::SchemaMigration.create_table(limit=?)> #8 [method] initialize_schema_migrations_table <ActiveRecord::ConnectionAdapters::Mysql2Adapter#initialize_schema_migrations_table()> #9 [method] initialize <ActiveRecord::Migrator#initialize(direction, migrations, target_version=?)> #10 [method] up <ActiveRecord::Migrator.up(migrations_paths, target_version=?)> #11 [method] migrate <ActiveRecord::Migrator.migrate(migrations_paths, target_version=?, &block)> ....
development環境におけるデバッグ
2.1.5 (#<ActiveRecord::ConnectionAdapters::Mysql2Adapter:0x007fee429f8cc8>):0 > show-stack when_started hook failed: NoMethodError: private method `eval' called for nil:NilClass ***/server/vendor/bundle/ruby/2.1.0/gems/pry-stack_explorer-0.4.9.1/lib/pry-stack_explorer.rb:109:in `bindings_equal?' (see _pry_.hooks.errors to debug) Showing all accessible frames in stack (36 in total): -- => #0 create_table_with_innodb_row_format <ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format(table_name, options=?)> #1 [block] block in run <Byebug::PryProcessor#run(&_block)> #2 [method] run <Byebug::PryProcessor#run(&_block)> #3 [method] resume_pry <Byebug::PryProcessor#resume_pry()> #4 [method] at_line <Byebug::PryProcessor#at_line()> #5 [method] at_line <Byebug::Context#at_line()> #6 [method] create_table_with_innodb_row_format <ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format(table_name, options=?)> #7 [method] create_table <ActiveRecord::ConnectionAdapters::Mysql2Adapter#create_table_without_migration_comments(table_name, options=?)> #8 [method] create_table_with_migration_comments <MigrationComments::ActiveRecord::ConnectionAdapters::MysqlAdapter#create_table_with_migration_comments(table_name, options=?)> #9 [method] create_table <ActiveRecord::SchemaMigration.create_table(limit=?)>
#7
においてstgには無かった処理が介入しているのを発見。
2.1.5 (#<ActiveRecord::ConnectionAdapters::Mysql2Adapter:0x007fc938689b70>):0 > frame 7 Frame number: 7/35 Frame type: method From: ***/server/vendor/bundle/ruby/2.1.0/gems/activerecord-4.0.8/lib/active_record/connection_adapters/abstract_mysql_adapter.rb @ line 471 ActiveRecord::ConnectionAdapters::Mysql2Adapter#create_table_without_migration_comments: 470: def create_table(table_name, options = {}) #:nodoc: => 471: super(table_name, options.reverse_merge(:options => "ENGINE=InnoDB")) 472: end
migration comment gem をロードした結果、ActiveRecord::ConnectionAdapters::Mysql2Adapter::AbstractMysqlAdapter#create_table
により下記メソッドの引数 options
に常時 { options: 'ENGINE=InnoDB' }
という値がわたってしまったことが原因。
def create_table_with_innodb_row_format(table_name, options = {}) table_options = options.reverse_merge(options: 'ENGINE=InnoDB ROW_FORMAT=DYNAMIC') create_table_without_innodb_row_format(table_name, table_options) do |td| yield td if block_given? end end
hash_a.reverse_merge(hash_b)
は hash_a
の値を優先するため ROW_FORMAT=DYNAMIC
が反映されなかった。
とはいえ、幸いなことに varchar(192) 以上必要なカラムは現プロジェクトに存在しないので、
migration commentのgemを使いindex使用時は limit: 191
をつける対応で乗りきれるので、問題は無かった。
atomのセットアップした
「何か作業をしようと思うと途端に部屋の掃除がしたくなる」あるあるネタ。 atomのセットアップした。
以前vimに出会う前、sublime -> atom の流れで触ったことはあった。 とはいえ完全にmarkdown専用エディタとなっていたatomをもう少し使いたいなと。
動機は2つ。
IDE揃えるコストお金かかる問題
普段ruby/railsを書いている時には会社が買ってくれたRubyMineを使用できるが、例えばjavascriptを書きたい場合WebStorm別途買うの?IDE派じゃないの?vimなの?
vimの環境構築コストかかる問題
vimのように調べれば調べるほど味が出るというか、好き勝手環境構築して自分好みにカスタマイズ!できるエディタを使い倒せばそれでいいのだけど、vim弱者の自分としてはそこまで使い倒せない+そこに苦労するより、簡単な方法あればそれでいいじゃんというのを前から思ってた。
要はvim使いこなせないので楽したいですという開き直り発言。
やったこと
とはいえvim modeは必須。以前vimのようにatomを使うチャレンジをしたとき、vimでできることが全然atomで出来なくて泣いた。 最近 ベターvimとしてAtomを使うを見て「vimいけるじゃん」と思いまんま書いてある通りにパッケージをインストール、そしてストレス無く使えるレベルになった。
入れたpackage listはこちら。
reizist@reizist ~/environments $ apm list -bi atom-beautify@0.28.22 autocomplete-paths@1.0.2 autocomplete-ruby@0.1.0 color-picker@2.1.1 editor-background@1.2.17 es6-javascript@0.5.0 ex-mode@0.8.0 git-plus@5.13.0 highlight-column@0.5.1 highlight-selected@0.11.2 linter@1.11.3 linter-ruby@1.2.1 merge-conflicts@1.3.7 minimap@4.19.0 monokai@0.7.0 pigments@0.24.1 project-manager@2.7.6 script@3.5.2 sort-lines@0.14.0 term3@0.21.2 vim-mode@0.64.0 vim-mode-visual-block@0.2.15
ちょっと雑にいじった感じ、パッと気軽に何かいじる程度だったら少なくとも問題無さそう。 ただ、仕事のプロジェクトでいじるような巨大なファイルとか、tsvの編集などはむずそう。
特に巨大ファイルの一斉置換とか、sublime textなどの他のエディタの軽量さには勝てない。 sublime textを今のatomと同じようなカスタマイズしようと思ったら色々とハマったのでまた困ったらsublime頑張ってみる。
飽きたらテーマ切り替えてみたりしよう。
「Web制作者のためのCSS設計の教科書」読んだ
正確には「読んでた」。 関わっているプロジェクトの都合上、フロントに触る機会はほぼ無く、cssも我流で雑な実装しかしたことがなかったので 頭にindexを作る目的で読んだ。
cssの設計について、モダンな設計手法をいくつか示した上で筆者独自の設計方法も紹介する本であった。 betterな考え方を踏まえて、プロジェクトに沿ってジャストフィットする手法を模索すべき、という感じの結論の無い本で、実際、BEMやOOCSS、SMACSSという考え方はあくまで考え方であり、ベストプラクティスではない。 しかしながら、何故CSSが壊れやすいか、再利用するとはどういうことなのか、堅牢とは何かを言語化しておくことで確かに良い設計に近づけるはずだ。 識者のCSSに対する考えを聞くという意味で読んでおいて損はないと思う。
ただし、昨今はモダンで素晴らしいcssフレームワークがたくさんあるので、自分でゼロからcss設計する機会があるかというと首を傾げるレベル。 「このフレームワークはこういう考え方に則って設計されているんだな」と理解するために読む感じになりそう。
「アルゴリズムが世界を支配する」を読んだ
kindleで500円程度で買えるので読み物として読んだ。
「アルゴリズムがカバーする領域は、日々拡大している。様々な業界において、人間がやっていた仕事をアルゴリズムが取って代わるようになった。」
アルゴリズムがどのような貢献をしているか、近世の動向を多くの例と共に示している。 「アルゴリズム」という言葉を既に知っている人間なら、「ふーん、そうか」というの感想で終始するのでは?というのが私の感想であった。
始めの例が「ウォール・ストリートにおける金融市場取引のためのアルゴリズムの発展、及び株式取引手段の変遷」なのだが、「フラッシュ・クラッシュ」という単語に興味があった関係上、最も面白い章だった。 暴論ではあるが、その後の章、例えば医療業界におけるアルゴリズムの利用など、「アルゴリズムが世界を支配する」という主張を支持するため無理矢理に作ったような薄い話だなと感じた。 実際にはもちろんアルゴリズムが貢献していることに間違いはないだろうが、自分には無関係の業界における小さな発展についてあまり興味が湧かなかったことに起因するのかもしれない。
筆者の主張どおり、今後のさらなるアルゴリズムの発展によって、間違いなく人間の生き方は変わるだろう。 この主張に「なんで?」「ほんとに?」と思う人がいれば、高いものでもないので読んでおくと少し考え方が変わりそうだ。
ローカルからパフォーマンスチェック時fdの制限値に引っかかる
厳密にネットワーク越しにパフォーマンスチェックを行う場合、それなりのスペックマシンを別途用意するなど何かしらの対応をするとは思うが、 最低限の温度感を把握するだけの場合などローカルからベンチマークを実行することがあるときの話。
尚例では boomを用いているが当然 apache benchなどでも同じ。
$ boom -n 3000 -c 3000 -m GET http://example.com/bench_path
として大量のアクセスを想定するテストを行う場合に
Too many open files
と怒られる場合がある。
これはローカルのデフォルトでのファイルディスクリプタの制限値が低いから。
$ ulimit -n
などとして値を確認し、必要に応じて調整する。
$ ulimit -n 1024