備忘録などいろいろ

イロイロ! 比較的Twitterの延長のノリで書くと思います。

Amazon Elastic Beanstalkのお付きのRDSはけっこうやばい

Elastic Beanstalkで環境を新規作成するときに、同時にRDSインスタンスを作ることができるんですよね。
で、安定稼働してしまうと、どうしてもappサーバとdbサーバは別々に動いていると思い込んじゃう。
ある日突然ebの環境が調子悪くなったりして「再構築」ポチッと押すと、昔々ebの環境の一部として作ったRDSインスタンスまで落とされて再構築されてしまい、現場は大パニックに。なんてことが起こることがあるかもよ?
これ、どれくらい皆さんやらかすのか分かってないんですが、やりがちっぽいし、自分もやっちまったし、やばい。なんとかしろ。
まあ、RDSはebとは別に作るのが良さそう。

HerokuでRails動かすときのカスタムLogFormatterでハマった話

結論から言うと、Rails 5を使うときはrails_12factor gemは使わないほうが良さそう。

アプリケーションログベースでの監視をしたい/アラートを上げたいので、loggerの上げるログのseverity(ログレベル)の情報はかなり重要。この辺の情報はloggerのformatterにActiveSupport::Logger::SimpleFormatterを使っちゃうと消されてしまうが、::Logger::Formatterを使えば指定すれば消されずに出力される。

config/environments/production.rb

config.log_formatter = ::Logger::Formatter.new

 しかし、herokuにデプロイしているアプリで上記のFormatterが動いてくれずに非常に時間を消費してしまった。いくらformatterを変えても、強制的にActiveSupport::Logger::SimpleFormatterが使われてしまう。そういえば、rails_12factor gemってherokuでログを標準出力に吐き出す設定を良しなにやってくれるgemだったっけ?考えられるとしたらこれしか無いな...

github.com

If you are starting a new application with Rails 5, you do not need this gem.

Rails 5ではもうこのgem要らないらしい。マジか。

Gemfileからgem "rails_12factor"の行を消したらちゃんと動いた。

 

Elastic Beanstalkへのデプロイ方法その3

先日の記事で、Elastic Beanstalkへのデプロイ方法には2通りあると言った。このたび、その2通りのちょうど中間に当たる方法が解ったのでメモ。前提として, awsebcliというpipパッケージを利用してコマンドラインベースでdeploy処理を走らせる場合のお話。

qpshinqp.hateblo.jp

上記の2パターンをまとめると下記のようになる。

パターン1: 丸ごとzipアップロード方式

メリット:

  • 簡単

  • .ebextensionsによるeb環境ホストの設定injectionが可能

デメリット:

  • デプロイ所要時間が短い

eb deployコマンドのデフォルトの挙動で, ebプロジェクトルートディレクトリ内すべてをzip化し, ebプラットフォームにアップロードする。

eb環境ホストは上記zipを落としてきて, docker buildした後docker runし, アプリケーションが動き出す。

パターン2: dockerリポジトリpull方式

メリット:

  • デプロイ所要時間が短い

デメリット:

  • .ebextensionsによるeb環境ホストの設定injectionができない

どこかのdockerリポジトリに予めdocker buildしたimageをpushしておく。

Dockerrun.aws.jsonファイルにそのimageの所在(リポジトリ:タグ)を指定しておき, Dockerrun.aws.jsonファイルのみをebプラットフォームにアップロードする。

eb環境ホストはDockerrun.aws.jsonに指定されているdocker image情報をもとにリポジトリからimageをpullし、docker runすることでアプリケーションが動き出す。

中間手法: buildartifact.zip方式

メリット:

  • デプロイ所要時間が短い
  • .ebextensionsによるeb環境ホストへの設定injectionが可能

デメリット:

  • デプロイの下準備が比較的面倒

eb deployによりzipアーカイブをアップロードし, それをもとにdocker runするのはパターン1と同じなのだが, zip生成過程を自前で準備するという点がパターン1と異なる。

zipアーカイブの中身に, 動かしたいdocker imageのリポジトリ:タグ情報を格納したDockerrun.aws.jsonと、.ebextensionsディレクトリのみを格納する。

これにより、パターン2と同様にeb環境ホスト側でのdocker build処理を回避しつつ、.ebextensionsによる設定injectionを可能にしている。

まあ、知っている人は知っているのかもしれないがいろいろと試行錯誤したのちにこの方法に落ち着いた。

AWS ElasticBeanstalk で Docker 動かすときの備忘録

単一コンテナ環境で何回かやってるんですが、dockerコンテナのデプロイ方法には2種類あります。この方法の選択についていつも忘れてしまうので備忘。

方法1: Amazon ECR などに事前に `docker build` したイメージを push しておいて、ElasticBeanstalk に Dockerrun.aws.json だけを食わせて ECR からpullしてきて起動
方法2: railsのファイルやらDockerfileやらを全部 zip にしてeb deployか何かでアップロードする

普通に考えれば、方法1は可搬性のあるdockerということだし手元で `docker build` してしまったほうがエラー対処の手戻りが少なかったり、EB上でbuildしなくていいのでEBのUpdating state時間が少なくなって楽なのだが、ある問題が生じる。

問題:
.ebextensions でdocker hostに関する設定のinjectionができない。
したがって(単一コンテナ環境では)awslogs (CloudWatch Logs) へのアプリケーションログのストリーミングを行う手段がない。
※方法1ではEBはDockerrun.aws.json というマニフェストに従って docker image のみをpullするので.ebextensionsが介入するタイミングが無いとかそういうやつ。

ということで、deployプロセスが冗長になりがちだが仕方なく方法2を使うのである。デプロイの時間はもちろん長くなるが、苦渋の選択です。

ハンコン G29 のペダルメンテナンス

ハンコン(Logitech G29)のブレーキペダルの調子が悪くなったのでメンテナンスしたら直った。

あんまりいないと思うが、万が一同じ症状で悩んでる方がいた場合のご参考として記しておきます。

症状:

ブレーキリリース直後、ブレーキに触っていないのにもかかわらず、入力値がピコピコ変動する(英: spike)

このため、レースシムなどで遊んでるとコーナーの立ち上がりがめちゃくちゃ遅かったり、不意に荷重変動してスピンしたりする

なお、ソフトウェア側でブレーキペダルの遊びを調整しても改善しない(入力値のノイズにけっこうな値のバラつきがあるため)

 

原因:

ブレーキペダルのセンサー部(可変抵抗器/ボリューム)の変位0付近における接触不良

 

対策:

1. 可変抵抗器をバラして接触面及びブラシ電極を掃除した(無水アルコールで拭いたが、もっと良いのがあるかも)

2. ブレーキペダル内の歯車の山をひとつ分ズラして、可変抵抗の変位0付近を使わないようにした。
2'. もしかするとソフトウェア側でブレーキペダルの遊び調整が必要かもしれない(自分の場合は不要でした)

参考:

www.gtplanet.net

この情報、日本語でググってもなかなか出てこなかったので情報格差を感じる。

読んでわからなかったらコメで聞いてください。

博多ラーメンについての地元民の一言への反論

「『博多長浜ラーメン田中商店』に長蛇を成して寒い中並ぶ意味がわからない。博多ラーメン食べたければ一風堂行っとけば十分。」と仰った(自称?)地元民がいたが、私はその言葉には断固として賛同しかねる。そもそも博多ラーメンと博多長浜ラーメンを混同している時点でナンセンスだ。歴史も方向性もぜんぜん違う。一風堂のような化学調味料風味の味が単独で十分うまいラーメンだと思っているならそれは狭い世界に住んでいる方なのかと思わざるをえない。

別に一風堂をこき下ろすわけではないんだが、あの言葉に対する強い反発と、同時に強い悲しさを感じたので勢い余って書いてみた。

【PUBG】思いつき次第書くその1【初心者向け戦術】

最近PCを新調したのをキッカケに、PUBG (PLAYERUNKNOWN'S BATTLEGROUNDS)遊ぶようになったのですが、ここ数日初心者とSQUAD組むことがあったので初心者向けの戦術的注意点をこのカテゴリで思いつき次第書いていこうと思います。

 

なにぶん初心者向けなので高度な戦術については書きませんがご容赦ください。

 

分隊で行動するときは付かず離れずの距離感を保つ。目安15〜40m程度(?)

移動中に敵に目視されたとき、分隊員が近過ぎると一度に全員の位置が把握されてしまう。ある程度距離を取った状態で移動することで、1人が発見されて射撃を受けても、他の分隊員が迎撃や制圧射撃などの反応を取ることで最初に発見された分隊員を生かす確率を上げられる。

ただし、距離を取り過ぎると反応までに時間がかかり過ぎて被発見者が一気に気絶→死亡させられたり、気絶状態から蘇生に向かうことができなかったりする。あくまで程よい距離感を保つべき。

 

★適切に制圧射撃を行う

初心者のプレイでありがちなのが、隠密を気にし過ぎて撃たないこと。反撃を恐れるあまり分隊どうしの交戦状態になっても、敵の姿を目視し確実に当てられる状況になるまで撃たない、かと言って積極的に有利ポジションに移動する気配もない「待ち」の時間が長いように見受けられる。ソロプレイのときはそれでも一向に構わないのだが、DUO/SQUADでそれをやられると堪らない。

有利ポジションでもない場所での「待ち」をしているプレイヤーは死んでいるも同然で、そうなれば4対4の戦いだったはずが仕事しない味方により数的不利を背負った味方分隊の残りは忽ち殲滅されてしまうであろう。味方が3名気絶した状態から撃ち勝って3名蘇生するのは、隠密を破って被弾しつつ撃ち勝つよりも遥かに難易度が高いことが多い。

味方が敵と全面交戦しているが自分は敵を目視できない状況の教科書的な立ち回りとしては、味方に敵の方位/距離を教えてもらい、その辺に弾をばら撒くことである。立場を逆転して考えてみれば、射手の正確な位置は分からないが自分の近くに撃ち込まれている状況は、そうでない状況に比べてかなり行動の自由が制限されるはず。この制圧射撃を利用して敵に有利ポジションを取らせないようにすれば、キルこそ取れないものの味方のサポートという意味で武器になる。

もしくは、自分の位置が敵に把握されていない、かつ味方戦線はある程度時間稼ぎ出来そうな状況であれば、回り込んで側面から敵を討つことも検討できる。

撃たない、しかも移動しない、という隠密行動を選択できるのは、味方全員の位置が誰にも把握されておらず誰も撃たれる事がない状況のみに限られる。