パパエンジニアのアウトプット帳

30歳に突入した1児のパパエンジニアのブログ

ActiveJob with sidekiqでリトライをしないようにする

非同期処理のど定番のsidekiq。

それをActiveJob経由で使っている場合は、sidekiq_optionsが使えないので細かな設定ができない。

今回、sidekiqにするにしたがってリトライは現時点では全てのジョブで不要なので、リトライしないようにしたかった。

結論としてはconfig/initializers/sidekiq.rbにSidekiq.options[:max_retries] = 0を設定してあげればいい。


sidekiqのwikiでこの設定見当たらなかったので、ソース調べたら見つけた。

https://github.com/mperham/sidekiq/blob/v5.1.3/lib/sidekiq/job_retry.rb#L46-L49

デフォルトが25らしいので、それを変更する際にもこの設定方法でいいと思われる。

Capybara::Poltergeist::StatusFailErrorが出たら

このエラーはローカルで

Capybara::Poltergeist::Driver.new(app, js_errors: true, timeout: 1)

のようにpoltergeistのtimeoutをすごく短くすると同様のエラーになる。


原因はassets compileに時間がかかっていてタイムアウトしている説らしい。

とりあえず、timeoutを伸ばして様子をみて、ダメなら先にassetファイルにアクセスするやテスト前にprecompileをするなどの方針を考える必要がある。

Capybara.register_driver :poltergeist do |app|
  Capybara::Poltergeist::Driver.new(app, js_errors: true, timeout: 60)
end

Capybara::Poltergeist::StatusFailError · Issue #791 · teampoltergeist/poltergeist · GitHub

Capybara::Poltergeist::TimeoutErrorが稀に起こる問題の対応 - Qiita

Timeout::Error: execution expiredの場合

このエラーの場合はどのgemがというよりはテスト内にTimeout.timeout(5)とかやっている場合がある。

自分の場合はajaxの処理が完了するまで待つみたいなやつがあった。

Aurora MySQLのmax_connectionsの設定

テスト環境でrailsのdatabase.ymlのpool設定を本番に合わせたいが、Auroraの方のmax_connectionsが45になっていた。

これでは足りないので45より多くしたい。


まず、Auroraのmax_connectionsはインスタンスタイプでデフォルトが決まるような設定がされている。

docs.aws.amazon.com

なので、これを変更する。


そのために、AWSのコンソールからRDS→パラメーターグループから対象RDSに対応するパラメーターグループを選択して、フィルターでmax_connectionsで検索して"パラメーターの編集"を押して変更すればOK。

特に RDSの再起動をしなくても設定が適応されている。(適用タイプがdynamicなので)

mysql> SHOW VARIABLES LIKE 'max_connections';で確認

logrotateを使ってローテションを行う

設定方法&確認

下記などを参考にした。

logrotateでログのローテーションをする - おもしろwebサービス開発日記

logrotate でデフォルト以外のフォーマットで日付ファイル名にしたいとき - Qiita


こんな感じで設定してみた。

日次で前の日のログをローテートするのに日付がローテートした日付なのがなんか気持ち悪いから、lastactionで前の日のファイル名にしてみた。

(これでいいかはちょっと自信ない)

追記(2018/04/12)

postrotateでやってないのは、compressを指定しているから。

ローテート→postrotate→compressの流れになるようなので、postrotateでrenameするとcompressがrename前のファイルを圧縮しようとしてエラーになった。

/my/rails/application/log/*.log {
    daily
    rotate 30
    missingok
    notifempty
    copytruncate
    dateext
    dateformat .%Y%m%d
    compress
    su root root

    lastaction
        for infile in $1; do
            if [ -f $infile.`date '+%Y%m%d'`.gz ] ; then
                mv $infile.`date '+%Y%m%d'`.gz $infile.`date --date '1 days ago' '+%Y%m%d'`.gz
            fi
        done
    endscript
}


logrotateのテストはf,dオプションをつけて確認する。

# dオプションを付けるとデバック実行で実際には実行されない
$ logrotate -d /etc/logrotate.d/rails

# fオプションだと実際に実行される
$ logrotate -f /etc/logrotate.d/rails

といあえず指定できるやつは下記をみたら意味がわかると思う。

@IT:logrotateの設定ファイルで指定できる主なコマンド

他のオプションはmanを見るなどします。

logrotate(8) - Linux man page

cronの設定は必要か?

下記のように、/etc/crontabか/etc/anacrontabを確認しましょう。

【logrotateの実行タイミング】/etc/crontabに無い時の確認方法 - Qiita


今回検証していたCentOSの場合は/etc/anacrontabに設定されているので特にcronの設定をしなくても動くはず。

https://daichan.club/linux/639

細かすぎて伝わらない anacron の挙動 - Qiita

Macで特定のアプリにショートカットを割り当てた

下記のやつをやっただけなんだけど、開発とかでよく使うChrome,Terminal,RubyMineにショートカットを割り当てて一発でそのアプリをアクティブにできるようにした。

qiita.com

あとウィンドウ操作系は下記のやつを職場の人に教えてもらったので、早速インストールした。

Spectacle

今さらjquery-railsがcsrfトークンをいい感じにしてくれていたことを知った

RailsでPOSTなどするときはCSRFのチェックが行われるのでトークンを送る様にしないといけないのだけど、axiosとかで自分でajaxリクエスト投げる時はちゃんとcsrfトークンを付与しないと行けなくて面倒だなーと思っていた。

その時、そういえばなんでRailsjQueryの$.ajax使ってる時はトークン渡さなくていいんだっけ?となって調べて見たらjquery-railsがいい感じにしてくれてましたということでした。

jquery-rails/jquery_ujs.js at 47d15123e27ca22f642b7befaeb152339f5d466a · rails/jquery-rails · GitHub


jquery-ujsでも同様なのでwebpacker使ってても安心。

jquery-ujs/rails.js at 4849eca8ff76a0a2a83a8ff4d5cefef2c2fa3cb4 · rails/jquery-ujs · GitHub

Cloudfront,S3で307リダイレクトに苦しめられた

完全に下記のヤツなんだけど見つけるまですごくハマった。。。

miyasakura.hatenablog.com


S3のcssファイルとかを直接参照するのではなくCloudfrontからのみ参照できる様にクラメソさんの下記の記事を見て色々設定を検証していたんだけど、なぜかcloudfrontのURLにアクセスしてもS3のURLにリダイレクトされてAccess Deniedになってしまって???となった。

dev.classmethod.jp


原因としては上記のURLを辿って行ったstackoverflowに書いてある。

amazon web services - AWS CloudFront returns http 307 when origin is S3 bucket - Stack Overflow

All buckets have at least two REST endpoint hostnames. In eu-west-1, they are example-bucket.s3-eu-west-1.amazonaws.com and example-bucket.s3.amazonaws.com. The first one will be immediately valid when the bucket is created. The second one -- sometimes referred to as the "global endpoint" -- which is the one CloudFront uses -- will not, unless the bucket is in us-east-1. Over a period of seconds to minutes, variable by location and other factors, it becomes globally accessible as well. Before that, the 307 redirect is returned. Hence, the bucket was not ready.


Cloudfrontは上記でいう2つ目のエンドポイントを利用するので、すぐには有効にならずCloudfrontがリダイレクト状態をキャッシュしてしまう。 (なので、時間をおいてCloudfrontでinvalidationをしてやればいいらしいが、これ数分とかでなく1時間とか2時間くらい必要な時もある。。。)


バージニアリージョンにバケットを作成するとこの事象は起きないので、特にリージョンを気にならないならバージニアに作った方が変にハマらなくていいと思う。

(その他のリージョンの場合も先にバケット作成して時間おいてからCloudfrontの設定すると発生しづらい?)

リクエストのリダイレクトと REST API - Amazon Simple Storage Service

米国東部 (バージニア北部) リージョン (s3.amazonaws.com エンドポイント) にバケットを作成した場合は、リダイレクトされません。このリージョンがデフォルトのエンドポイントであるためです。