https://rubygems.org/gems/capistrano-pending/versions/0.2.0
Capistranoのプラグイン方式がv3.7から大きく変わって:scm変数が非推奨になり、さらにv4.0からは消されるらしく、その対応のため。といってもいただいたPRの挙動を確認しただけだけど。
仕組みが変わるのはメンテする側からすると厄介だけど、見た感じフックする方法やデフォルト値の設定のタイミングなどが整備されるみたいなので良さげな感じ。あと:scmが消えるというのも、Capistrano本体はリモート実行のフレームワークという側面が強くなって正統進化してるように見受けられる。
しかし今回の対応では英語でやりとりされてるニュアンスや、Capistrano自体の挙動やらがなかなか理解できなくて戸惑うことが多かった。
homebrewでインストールしてるのでlaunchdに読ませてるplistは~/Library/LaunchAgents/homebrew.mxcl.memcached.plistにある。
下記にコメントしたあたりをよしなに記載する。
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>homebrew.mxcl.memcached</string> <key>KeepAlive</key> <true/> <key>ProgramArguments</key> <array> <string>/usr/local/opt/memcached/bin/memcached</string> <string>-l</string> <string>localhost</string> <string>-v</string> <!-- どれだけ詳細な情報を出すか。sshみたいにvvもvvvも指定できるがvvの時点で通信内容が吐かれるので今回はvに留める --> </array> <key>RunAtLoad</key> <true/> <key>WorkingDirectory</key> <string>/usr/local</string> <key>StandardOutPath</key> <!-- 標準出力の出力先 --> <string>/usr/local/var/log/memcached.log</string> <key>StandardErrorPath</key> <!-- 標準エラーの出力先 --> <string>/usr/local/var/log/memcached.log</string> </dict> </plist>
あとは上記を再読込する。
launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.memcached.plist launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.memcached.plist
調べては忘れるのでメモ。
grep [f]ooって結局grep fooと同じなのになんだこれはと思ってたけど、psはgrep自身のプロセスも返してくる（ことがある）ので、
ps -ef | grep foo だと foo を探しているうちに grep foo というプロセス自身にマッチしてしまうps -ef | grep [f]oo も同じように foo を探すけどgrepのプロセスは grep [f]oo なのでマッチしないということらしい。
ちなみに[ ]は角括弧、大括弧、square bracketらしい。< >は同じブラケットでも山括弧というんだとか。
cf. 括弧 - Wikipedia
自分は初めて触ったサーバがSolarisなので手癖ではps -efを打ってしまう。やっぱりps auxのほうが世には多いんだろうか。
xtrabackupからファイルを復元するとき、ネットの記事とかPerconaの記事とかを見ると--copy-backを目にすることが多いんだけど、コピーするほどのディスク領域などない…！という場合には--move-backを使えばいい。
innobackupex --move-back /path/to/BACKUP-DIR
これならファイルの移動をするだけなので、バックアップファイルの展開ぶんと復元後のデータ領域とで重複してディスクを消費することがなくなる。
なお上記コマンドを実行したあとも展開した場所には中間ファイル？が残るので、それらは削除しても問題ない。
rm -rf /path/to/BACKUP-DIR
調べてる過程で古いバージョンだとログファイルが移動されないという不具合があったような記述を見かけたけど、今回使用した2.3.6では発生しなかった。
capistranoでrubotyをデプロイするのをよしなに助けてくれるgemを書いた。
デーモン化とPIDファイルの書き出しに対応したruboty v1.3.0が必要になるので要注意。
Herokuで動かしてたりdockerでデプロイしてたりするとあまり旨味はないのかもしれないけど、普通にcapistranoでデプロイして動かしたいようなときもあるのでやってみた。
下記のスクリプトを例えばyour_ruboty/lib/daemonize.rbみたいな場所に置いておく。
# nochdir: true - 相対パスでファイルの読み込みをするプラグインがあったときに # 不具合の出ないように # noclose: false - capistranoでデプロイしたときに制御端末を切り離すために Process.daemon(true, false) # killしやすいようにPIDを書き出す require "fileutils" pid = File.expand_path("/tmp/ruboty.pid", __FILE__) FileUtils.mkdir_p(File.dirname(pid)) File.open(pid, "w") { |f| f.write Process.pid }
そして起動時に--loadオプションで上記のスクリプトを指定して読み込んでやればデーモンとして動いてくれる。
$ bundle exec ruboty --dotenv --load lib/daemonize.rb
killしたいときはPIDファイルを見て適当にシグナルを送ってやればいい。
$ kill -TERM $(cat /tmp/ruboty.pid)
PIDファイルとデーモン化のオプションがそれぞれ本体に取り込まれたので、追々上記のようなことは不要になる。
ruboty 1.3.0から--daemonオプションと--pid <path>オプションが導入された。
http://aerial.st/archive/...に来たアクセスを一律にhttp://archive.aerial.st/archive/...にリダイレクトするようにした。
Rails.application.routes.draw do # (snip) get "archive/*path", to: redirect(subdomain: "archive", path: "/archive/%{path}") end
%{foo}はparams[:foo]の値が取れるみたい。
ちなみにデフォルトだと"301 Moved Parmanently"になるらしく、特定のステータスコードを指定する場合はstatus: 302とかあわせて指定してくれとのこと。
