AR ホームベーカリー

オイラのアウトプット用ホームベーカリー!

ActionMailer でメール送信時に利用する情報を動的に変更する

qiita.com

/config/environments/ 以下で config.action_mailer.smtp_settings で指定した情報を、送信するタイミングで上書きできる。

ただこれ見てると、送信時に上書きするのでたくさん送ると負荷高くなりそーだな、という気はしている。

railsguides.jp

まあやりようはある、ってメモ。

AppleSillicon で古い Ruby を build する

具体的には 2.6 とかそれ以前のあたり。

www.hsbt.org

ローカルはめちゃくちゃしていいか〜、と思ってコンテナで頑張ったりしていたんだけど、シュッと確認したいときに rbenv と ruby-build に存在していると楽なので、とりあえずこれでやってみましょう。

RDS の role 名を変える

RDS のモニタリングロール

Terraform で RDS のモニタリングロールを設定する際、なるべく名前をデフォルトに寄せたくて以下のようにしている。

resource "aws_iam_role" "rds_monitoring_role" {
  name               = "rds-monitoring-role"
  assume_role_policy = data.aws_iam_policy_document.rds_monitoring_role.json
}

しかしこれだと、すでに RDS を構築したことがある (削除済み) だったり、DB インスタンスが立っている、みたいな環境に terraform する場合、デフォルトのロール名だと衝突して apply できない。

で、これって名前動かすとダメだと思ってたんだけど、実はそんなことはなかったのだった。

dev.classmethod.jp

というわけで、以下のようにして apply した所無事に動いた。

resource "aws_iam_role" "rds_monitoring_role" {
  name               = "${var.prefix}-rds-monitoring-role"
  assume_role_policy = data.aws_iam_policy_document.rds_monitoring_role.json
}

${var.prefix} には環境特有の文言を付与する。 これで便利にユニークな名前を設定できるはず。

おまけ

ALB とか 32 文字制限でつらすぎるのでせめて 128 文字とかに上限拡張しないかなあ、と思ったりしている。

あと Redis のライセンス形態が変わって for Redis の文言が使えないの、あからさまに AWS を意識していて笑っちゃった。 まあそうなる気持ちは分かるのだった。

USB-C マグネット式アダプタを使っていて FHD 以上の解像度が出なくなった

まぁまぁ検索していても引っかからんくて、解決まで時間がかかってしまったので。

USB-C アダプタのマグネット化

IntelMac (2019) で AppleCare 期間中に二度ほど修理しているので、教訓を胸に USB-C 接続部分を Magsafe 同様にアダプタ化することにしていました。

使っていたのはこれ。

https://www.amazon.co.jp/dp/B09924XQNN

で、これの差し込み (オス) 側にピンが実装されているんですが、そのピンが数本折れてしまって、映像転送の帯域が足りなくなったのかなんかで、掲題のような状態になっていました。

問題が出ている状態

FHD までしか認識できていない図

問題が解決した状態

1440p が認識された図

気付き

TimeMachine バックアップにくっそ怪しい上ノイズを滅茶苦茶出す 2.5inch SSD エンクロージャを採用しているので、それが原因かなあ……と思っていたのですが、着脱しても変わらず。

なんどかケーブル取り外す際にうまくいかず、本体側のメスコネクタまで引っこ抜けてしまって「あーあ」と思って見ていたら「あれ?! なんか中のピン折れてない……!」となり、気付きを得た、という感じです。

この製品を使っている理由

iPadPro (2018) の給電やデータリンクも同じものを使っており、特に iPad の USB-C はうまくいかない商品が多い中で通信まで出来て「Happy! Happy! Happy!」という猫ミームみたいな顔だったので、これを使い続けています。

HDMI 直接ブッさしたらちゃんと 1440p 認識されていたので、「もっと早く気付けたと思うんですけど」と思いつつ、便利な製品を使っているとハードウェア側でもレイヤー増えてても気付けなくて大変ですねえ、というマヌケな話ですが備忘録に。

現在

追加でマグネットアダプタと USB ケーブルを購入したのですが、理由が前述の通りで無駄にしてしまったな、という感じでした。

購入したhのはそれぞれ以下。

この組み合わせでも動いているので、購入する時は参考にしてください。

ケーブル

https://www.amazon.co.jp/dp/B0827KJ6DY?th=1

マグネット

https://www.amazon.co.jp/dp/B0BHWR827C?th=1

行き先を失ったプロセスを kill して平和を取り戻す

アプリケーション側で実行流量の制御をしておらず、人力で大量にアクセスすると死ぬ機能がリリースされてしまい、無事に死亡する事案に遭遇していた。

タイムアウト時間を超えた MySQL 内プロセスを kill する

対象を抽出する

以下のようにすると、カンマ区切りで kill すべき ID が取れる。

time >= 60 で、60 秒以上経過しているプロセスを状態問わず絞り込んでいるので、例えば前面の ALB だったり httpd, Nginx なりのタイムアウトが 120 秒だったりする場合は、ここを time >= 120 とすればいい。

mysql> SELECT GROUP_CONCAT(id) FROM information_schema.PROCESSLIST WHERE time >= 60 and user != 'rdsadmin';
+------------------+
| GROUP_CONCAT(id) |
+------------------+
| 1, 2, 3, 4       |
+------------------+
1 row in set (0.00 sec)

これを kill する。

対象を kill する

一件ずつならそのまま MySQL CLI から kill ${id}; のようにして消せるが、今回はまとめて消したいので mysqladmin を使う。

# example.1145148101919.ap-northeast-1.rds.amazonaws.com こんなエンドポイントは実際に存在しないので例です、存在してたまるか
❯ mysqladmin kill 1, 2,3,4  -u example -p -h example.1145148101919.ap-northeast-1.rds.amazonaws.com

これでよい。

ちなみに同時に 70 くらい id 指定して mysqladmin から kill 投げたりしているけど、コマンドが壊れたりはしていないので、ある程度多い場合はこちらで消しましょう。

参考

qiita.com

EBS サイズをオンラインで拡張する

AWS 的にはオンライン拡張をサポートしている、というか仕組み的に基本そうなっているので。

そんな感じ!

作業手順

以外だと思われるが、公式にわりとマトモなナレッジベースがある。

docs.aws.amazon.com

なので以下では注意する点のみ書いておく。

Nitro か Xen

インスタンスタイプ (世代) によって仮想化の方法が異なり、作業手順も違うらしい。

最近のインスタンスはだいたい Nitro を利用しているが、 昔のインスタンスタイプだと Xen を採用している場合がある。 概ね T2 とか M3, M4 あたりが該当する。

❯ aws ec2 describe-instance-types --instance-type t2.micro --query "InstanceTypes[].Hypervisor"
[
    "xen"
]

❯ aws ec2 describe-instance-types --instance-type m4.large --query "InstanceTypes[].Hypervisor"
[
    "xen"
]

エフェメラルストレージが付いていたり VPC の区切りが存在しなかった時代、そのあたりを生きていたインスタンスが概ね対象と思えばよさそう。

スナップショットの作成をしておく

公式的には「失敗したらロールバックするよ」と書いているけど、失敗せずに拡張出来たとしてそれは EBS 的に成功しているだけで、内部のファイルシステムやファイル自体が壊れていないとは言ってない、という事らしい。 残当

なのでスナップショットは作成しておいてね、という話だ。

docs.aws.amazon.com

基本的に作成してから作業はじめて、終わったら SSH 接続やホスティングしているサービス利用して主だったトコでエラーが出ないことを確認できれば、スナップショットは消してもいいと思う。

転ばぬ先の杖理論で。

オンライン拡張

基本的に稼働中のインスタンスSSH 接続して作業する。

ManagementConsole から EBS 拡大するのも、その後 SSH 接続して growfs や resizefs を実行するのも、プロセス稼働中の環境で実施して問題ない。

想定される問題としては、突然ディスクサイズが増えたので監視系アプリケーションが「何事!?」となって例外を吐くとか、プロセスが掴んでいる inode や fd がズレる (新しく採番するとき、拡張後の値におっつけない) などがありそう。

とはいえ個人的には遭遇したことないし、困ったら大正義 fsck とか実行するしかないのでそんなトコだろうか?

EBS のステータス

EBS のサイズ変更だけにフォーカスすると、ステータスは以下の3つが存在する。

  • modifying
    • 変更中
  • optimizing
    • 最適化中
  • completed
    • 完了済み

各種作業は EBS のステータスが optimizing 以降になってから実施する。

docs.aws.amazon.com

実際に modifying 中に EC2 に接続して lsblk などすると、タイミングによってはディスク拡張が終わっていない時があった。 optimizing になると最低限 lsblk から見えるディスク情報の反映は終わっている。

その他

過去書いたけど、 拡張する時に環境によっては失敗する場合がある。

donbulinux.hatenablog.jp

参考

qiita.com