/config/environments/
以下で config.action_mailer.smtp_settings
で指定した情報を、送信するタイミングで上書きできる。
ただこれ見てると、送信時に上書きするのでたくさん送ると負荷高くなりそーだな、という気はしている。
まあやりようはある、ってメモ。
/config/environments/
以下で config.action_mailer.smtp_settings
で指定した情報を、送信するタイミングで上書きできる。
ただこれ見てると、送信時に上書きするのでたくさん送ると負荷高くなりそーだな、という気はしている。
まあやりようはある、ってメモ。
具体的には 2.6 とかそれ以前のあたり。
ローカルはめちゃくちゃしていいか〜、と思ってコンテナで頑張ったりしていたんだけど、シュッと確認したいときに rbenv と ruby-build に存在していると楽なので、とりあえずこれでやってみましょう。
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 できない。
で、これって名前動かすとダメだと思ってたんだけど、実はそんなことはなかったのだった。
というわけで、以下のようにして 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 を意識していて笑っちゃった。 まあそうなる気持ちは分かるのだった。
まぁまぁ検索していても引っかからんくて、解決まで時間がかかってしまったので。
IntelMac (2019) で AppleCare 期間中に二度ほど修理しているので、教訓を胸に USB-C 接続部分を Magsafe 同様にアダプタ化することにしていました。
使っていたのはこれ。
https://www.amazon.co.jp/dp/B09924XQNN
で、これの差し込み (オス) 側にピンが実装されているんですが、そのピンが数本折れてしまって、映像転送の帯域が足りなくなったのかなんかで、掲題のような状態になっていました。
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
アプリケーション側で実行流量の制御をしておらず、人力で大量にアクセスすると死ぬ機能がリリースされてしまい、無事に死亡する事案に遭遇していた。
以下のようにすると、カンマ区切りで 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 する。
一件ずつならそのまま 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 投げたりしているけど、コマンドが壊れたりはしていないので、ある程度多い場合はこちらで消しましょう。
AWS 的にはオンライン拡張をサポートしている、というか仕組み的に基本そうなっているので。
そんな感じ!
以外だと思われるが、公式にわりとマトモなナレッジベースがある。
なので以下では注意する点のみ書いておく。
インスタンスタイプ (世代) によって仮想化の方法が異なり、作業手順も違うらしい。
最近のインスタンスはだいたい 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 的に成功しているだけで、内部のファイルシステムやファイル自体が壊れていないとは言ってない、という事らしい。 残当。
なのでスナップショットは作成しておいてね、という話だ。
基本的に作成してから作業はじめて、終わったら SSH 接続やホスティングしているサービス利用して主だったトコでエラーが出ないことを確認できれば、スナップショットは消してもいいと思う。
転ばぬ先の杖理論で。
ManagementConsole から EBS 拡大するのも、その後 SSH 接続して growfs や resizefs を実行するのも、プロセス稼働中の環境で実施して問題ない。
想定される問題としては、突然ディスクサイズが増えたので監視系アプリケーションが「何事!?」となって例外を吐くとか、プロセスが掴んでいる inode や fd がズレる (新しく採番するとき、拡張後の値におっつけない) などがありそう。
とはいえ個人的には遭遇したことないし、困ったら大正義 fsck とか実行するしかないのでそんなトコだろうか?
EBS のサイズ変更だけにフォーカスすると、ステータスは以下の3つが存在する。
各種作業は EBS のステータスが optimizing 以降になってから実施する。
実際に modifying 中に EC2 に接続して lsblk などすると、タイミングによってはディスク拡張が終わっていない時があった。 optimizing になると最低限 lsblk から見えるディスク情報の反映は終わっている。
過去書いたけど、 拡張する時に環境によっては失敗する場合がある。