UMIHICO BLOG.

以前にverifiedにしようとしたら公開鍵がED25519だと手順が煩雑だったので諦めてましたが、久しぶりに調べたら簡単になってました

パスワードレス認証の１種であるマジックリンクっていいですよね。ユーザーは認証の手間なく、かつID・パスワード管理や漏洩のリスクの無いログイン基盤を提供できます。

AWSでも似たことができないかと思い、色々漁ってみたネタ記事になります。フェデレーテッドログインで近いことができそうなので試してみました。スクリプトはgithubに上げましたが、肝は以下の部分です。

routesとcontrollerをモックすることで、includeしたControllerとしてテストするのではなく単体テストが実現できました。

クローンした際に割り当てたフォルダ名を失念して、gitのオリジンから調べたくなった、かつclone済みの全フォルダを走査する必要があったので

いろいろ試してきたので、メリデメ書いていきます

マイグレーション編

• CIからECSタスク起動でマイグレーション
• CIからLambda起動でマイグレーション
• CIでセッションマネージャで踏み台と繋ぎながらマイグレーション

踏み台編

• EC2と公開鍵
• ECSとセッションマネージャ
• EC2とセッションマネージャ

見ている情報が古かったのか、ずっと誤った書き方をして以下のエラーと格闘していました

KeyError: 
Trait not registered: 
"title" referenced within "article" definition

curlとjqでゴニョゴニョやるのが辛くなってきたり、API以外にもライブラリで提供されている場合に速やかに叩けるようにメモ。ライブラリで型ついてると、Github Copilotも最大限活きるので、とても高速に開発できました

シェル芸ではjq,　yqを筆頭にその他awk, sed, xargsを使いますが、それでゴリ押しを卒業する個人的なライン

• jsonから値を1つ抽出して次のコマンドにパイプするというより、json全体を整形して渡したいとき
• npmでライブラリが提供されているとき（Github Copilotの命中率が上がるので）
• Node,TypeScriptなどの環境がすぐ整備されているとき（今まで無かったので、本件で解消）
• 上記に該当しなくても可読性が圧倒的に落ちてくるとき（割とすぐくる）

端的に言うとGithub Actionsでは、Action中にpushするパターンは無限ループが発生するリスクがあるので、実行者がボットgithub-actions[bot]の場合に限り、merge/pushした際には、その先のブランチで走るべきCIをキックしない仕様があり、対策が必要です。

ジョブ毎にhttps://awscli.amazonaws.com/awscli-exe-linux-x86_64.zipからダウンロードしてるのでこれをCircleCIのキャッシュを入れてみましたが、もともと３秒の処理時間は全く改善しなかった話

Ngrokと同じことをするのに何が必要かというとこれだけでした。

• リモートポートフォワードでSSHする
• Nginxでフォワードされたポートをインターネットに公開するよう設定する

EC2の起動テンプレートをterraformで作り、起動テンプレから立ち上がったサーバーはあらかじめ仕込まれたユーザーデータのスクリプトで自動でNginxや必要なセットアップを行うようにしました。

調べてみるとRake::Task.tasks.eachで全タスクにenhanceする例が多く見つかったが、そうなると:environmentなど継承先のタスクにも付与されるからか、なぜか私の環境では実行したいタスクより先に実行されてしまった。 これを防ぎ正しく後から実行するにはRake::Task[Rake.application.top_level_tasks[0]]と指定する必要があった

モノレポ運用をしてるPJにて、導入寸前まで思案したcircleci/path-filteringというorbsですが、導入を諦めた懸念点をメモします

効率的なエイリアスのために、体感ではなく実際に使われているコマンドの出現頻度に基づいてエイリアス設定を行えるように、ワンライナーを作成しました。

CIのビルド時にECRからキャッシュ用にイメージをプルするパターンは多いと思いますが、その際は簡単に最も日時が新しいイメージが選ばれがちかと思います。

しかし「最新のイメージをとる」方法では複数のブランチで複数人が交互にプッシュする状況で、例えば片方がnode_modulesなど依存関係に変更を加えるものであると、互いのキャッシュを活かせないことになります。 この解決法は「最新のイメージをとる」ことではなく、「自身のコミットログと一致する範囲での最新のイメージをとる」ことです。そうすることで、まだマージされてない他所のコミット（イメージ）をスキップして、自身の直系の先祖にあたるコミットのイメージをプルしますので、キャッシュ効率が高くなります。

GithubのIssueの発行時に作成して、クローズ時にプロパティを変更するようにしました。

デフォルトブランチへのPRマージでIssueをクローズできるので、Issueベース、PRベースでNotionを更新できます。

一番粒度の小さいタスクをこのようにIssueで管理して、それらをNotion上のEpicなどでグルーピングして、エンジニア以外でも分かる粒度の進捗管理にあてれば手間や更新漏れのない管理ができると思いました。

また、検索に引っかけるためにIssue URLをプロパティに追加してますが、このおかげで完了したNotionページ見た時に起きる「このPRどれだっけ」問題がなくなりました。

整数のGithub Issue NoからIssue URLを生成したかった

if(empty(prop("Github Issue No")), "", concat("https://github.com/umihico/hoge/issues/", format(prop("Github Issue No"))))

ECSのアプリがRDSのDBにつながらない事態が発生し、どうも解決できないのでEC2を同じVPCに立ててRDSに接続できるか確かめてみることにしました。再利用できるようにメモ

aws ec2 describe-subnets --filters "Name=tag:Name,Values=COMMON_PREFIX_HERE*" --query "Subnets[].[SubnetId]" --output text | python -c 'import sys; print(",".join(sys.stdin.read().splitlines()))'

CircleCIのECSのOrbsに使いたかったが、そもそもCommandにしろJobにしろ引数は環境変数など静的にセットするか、circleci/continuationを使わないとダメそう

fixupしたコミットを上から数えて10ならgit rebase -i --autosquash HEAD~10とかやってましたが、rebaseもまとめてやるコマンド作った話

これ→(hoge.*fuga|fuga.*hoge)

「このMacについて」→「ストレージ（タブ）」→「管理」から空き容量を作ることができますが、システムデータという編集が不可能な項目で300GB近く専有しており、削除までに調査が必要だった話

aws-nukeで削除可能なリソースを調べたら、タスク定義が大量に残っていることが分かったたので、以下のコマンドで削除した。

別の新規プロジェクトに既存のTerraform資産を流用した時に、App RunnerとECRを一発で同時デプロイすることになりましたが、そうなると当然ECRのレポジトリは空なので失敗するわけで、次回スムーズに流用できる方法がないか試行錯誤しました

aws-nukeで削除可能なリソースを調べたら、タスク定義が大量に残っていることが分かったたので、以下のコマンドで削除した。

アカウント内のリソースを全削除してくれるライブラリaws-nukeを触ってみました

Next.jsとRuby on RailsのプロジェクトをDockerを通じて環境依存せず指定した言語バージョンで構築する

某サイトからCSVのインポートをよく行うのですが、インポートしたデータを使った後に毎度足したシートが増えており、消すのも大変なのでスクリプトを書きました。

議事録、日報などなにかと必要になる本日の日付をショートカットで呼び出す方法を紹介します

Nextとしてサーバーを建てるのではなく、RailsのViewからscriptタグでJS配信するだけなら、本番イメージ内にインストールする必要ないのでは？と思ったらできた話