読者です 読者をやめる 読者になる 読者になる

There's an echo in my head

日々のメモ。

capistrano-pending v0.2.0をリリースした

https://rubygems.org/gems/capistrano-pending/versions/0.2.0

Capistranoプラグイン方式がv3.7から大きく変わって:scm変数が非推奨になり、さらにv4.0からは消されるらしく、その対応のため。といってもいただいたPRの挙動を確認しただけだけど。

github.com

仕組みが変わるのはメンテする側からすると厄介だけど、見た感じフックする方法やデフォルト値の設定のタイミングなどが整備されるみたいなので良さげな感じ。あと:scmが消えるというのも、Capistrano本体はリモート実行のフレームワークという側面が強くなって正統進化してるように見受けられる。

しかし今回の対応では英語でやりとりされてるニュアンスや、Capistrano自体の挙動やらがなかなか理解できなくて戸惑うことが多かった。

launchdで動かしてるmemcachedのログを取る

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

参考

`ps -ef | grep [f]oo`というやつ

調べては忘れるのでメモ。

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のほうが世には多いんだろうか。

innobackupex --move-backでファイルの移動

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を書いた

capistranoでrubotyをデプロイするのをよしなに助けてくれるgemを書いた。

github.com

デーモン化とPIDファイルの書き出しに対応したruboty v1.3.0が必要になるので要注意。

rubotyをデーモンとして動かす

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>オプションが導入された。

routes.rbでワイルドカードに引っ掛けたパスを別のサブドメインにリダイレクトする

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

Redirect /archive/* accesses to archive subdomain by a2ikm · Pull Request #10 · a2ikm/aerial.st · GitHub

%{foo}params[:foo]の値が取れるみたい。

ちなみにデフォルトだと"301 Moved Parmanently"になるらしく、特定のステータスコードを指定する場合はstatus: 302とかあわせて指定してくれとのこと。

参考

このブログに出てくるコードスニペッツは、引用あるいは断りがない限りMITライセンスです。