Amazon SESでメール送信するときは必ず設定セットを使う

AWS メール 技術情報

設定セットとは

送信するメッセージに適用できるルールのグループのこと。
例えば

  • 成功したらログをCloudWatchに送信する
  • 配信(相手先に到達)したらSNSで通知する
  • テンプレートのレンダリングに失敗したらログをCloudWatchに送信する

というようなルールをあらかじめ定めておく。
定義した設定セットをメール送信時に利用すると、発生したイベントに該当するルールを実行してくれる。

使い方

説明のサンプルコードはAWS SDK for JavaScript v3のSESv2Client.SendEmailCommandを使う。

docs.aws.amazon.com

先に答えを書くと、下記のようなコードになる。

const { SESv2Client, SendEmailCommand } = require("@aws-sdk/client-sesv2");
const client = new SESv2Client({ region: "us-east-1" });

const params = {
  ConfigurationSetName: "利用する設定セット名",
  Destination: {
    ToAddresses: ["宛先メールアドレス"],
  },
  Content: {
    Template: {
      TemplateName: "利用するテンプレート名",
      TemplateData: "テンプレートに設定するデータ文字列",
    }
  },
  FromEmailAddress: '検証済みメールアドレス',
};

const command = new SendEmailCommand(params);
const response = await client.send(command);

SendEmailCommandに設定するパラメーターの中にConfigurationSetNameを含めるだけでよい。

これでメールを送信した場合、設定セットに定義したルールに該当するイベントが発生すると、ルールを実行してくれるという寸法だ。

おすすめとしては失敗系をCloudWatchやSNSに配信するルールだ。メールはどこかに到達しない限りなにが起こっているのか把握しづらい。最低限、失敗に関する情報を通知すれば、問題解決しやすくなるだろう。

なぜいまさらこのような記事を書いたか

AWS SDK for JavaScript v3を使いテンプレートメールを送信するLambdaを作って使っていた。

あるとき、少しテンプレート周りの処理をいじったらメールが送信できなくなってしまった。原因がわからなかった。もしかしたらDMARCの影響？と思って、AWSコンソールからテストメールを送信するも、これは問題なく配信できた。

丸二日ほど原因不明で、SESに関するログもなく、いまだDMARCが原因なのかもしれないという思いから、もしかしたらSESv2Clientを利用することでDMARC関連の何かが解決するのかもしれないと思って処理を直した。解決しなかった・・・😭

改めてSESv2Client.SendEmailCommandのドキュメントを読んでみるとConfigurationSetNameを設定できることに気づく1。もともと設定セット自体は作ってあったのだが使い方がわからずに放置していた。そうか、ここで使うのかといまごろ気づいたのだった。

設定セットを使ってメールを送信してみたところ、メールでエラー内容が通知された。やっと原因がわかった瞬間だった。

原因はテンプレートに定義した変数に値が設定されていないことによるものだった。そういえば設定する値が取れなくなったから消してしまうかと考えて、テンプレートに渡すパラメーターから消していたのだった。

問題が解決し、この情報はぜひとも世の中に発信しなくては！という思いから記事を書いた。
いつか誰かメール送信で困っていたときに発見してもらえたら嬉しい。

  1. ちなみにSESClient.SendTemplatedEmailCommandにもConfigurationSetNameはあるのだった↩

.NET MAUI 画像切り抜きサンプル。

Windows C# 技術情報 MAUI

jupitrisonlabs.hatenadiary.jp

前回の記事で WinUI3 を使った画像切り抜きサンプルコードを紹介した。どうせなら .NET MAUI バージョンも作って公開しようと思い作り始めたのだが、かなり手こずった😭

github.com

追記：Blazor版も作った。

github.com

続きを読む

Alpine Linux on WSL2 と nodenv と Node.js

WSL Windows 技術情報

nodenvを使ってAlpine Linux on WSL2にnodeをインストールする方法。

バイナリでは動かない

事前にanyenvのインストールと、anyenv経由でnodenvをインストールしておく。

nodenv install 18.17.1

上記コマンドを実行してnodeをインストールしnode -vを実行してみるものの

/home/username/.anyenv/envs/nodenv/versions/18.17.1/bin/node: fcntl64: symbol not found

このようなエラーになってしまって動かない・・・。

glibcではなくmusl libcを使う

Alpine Linuxはmusl libcを使っているので、glibcでコンパイルされたnodeのバイナリは動かないのだった。Alpine Linuxを常用したことがなかったので、今まで気にしたことがなかった。

知見が得られたことはよかったが、ちょっと恥ずかしい。

ソースからコンパイルする

nodenvはソースコードをダウンロードしてコンパイルすることも可能なようだ。ただコンパイルに必要なコンパイラやパッケージがなにも入っていないので、それらを事前にインストールしてからコンパイルを行う。

sudo apk add gcc g++ make linux-headers python3 --no-cache
nodenv install -c 18.17.1

およそ30分ほどかかってコンパイルとインストールが完了する。

node -v
v18.17.1

今度は無事に動く。

ARMアーキテクチャ搭載PCを求めて・・・

Windows 技術情報 ARM WSL

Apple M2 Proチップ搭載MacBook Proのあまりの発熱の少なさに驚愕した影響で、開発向けのArm搭載WindowsノートPCを探し求めた。

Snapdragon 8cx Gen 3搭載機に興味があるが、実用的な機種はほとんどなし

Windows11ノートPCでArm搭載機種となると選択肢が狭い。自分が調べた範囲だと、『ThinkPad X13s』しかないのではないかと思う。

www.lenovo.com

タブレットPCまで範囲を広げると『Surface Pro 9』が選択肢にあがってくるが、メモリ8GBでSSD256GBとちょっと心もとない。それにタブレットPCはキーボードをつけてもノートPCっぽく作業できない点がつらい*1。

www.microsoft.com

こうなると選択肢としてはThinkPad X13s一択だが、メモリ16GBという点が気になる。コンテナ起動して、Adobe XD起動して、Visual Studio 2022起動して、その他いくつかアプリ起動してといった状況では、CPU側がもたずメモリ関係なしに性能低下しそうな気もしている*2*3が、ひとまず開発向けとして役目を果たせそうである。

メモリより気になるのは、ThinkPad X13sに搭載されているSnapdragon 8cx Gen 3の発熱。性能よりも発熱が気になってしまう。Core i7-1185G7とSSD1TBを組み合わせたThinkPad X1 Carbon Gen 9は(室温33度の部屋において)恐ろしく熱い。ググった限りだと、Snapdragon 8cx Gen 3の発熱問題に関する記事はなさそうなので、ちょっと欲しくなってきた。

x64からArm64に切り替えることへの不安を解消する

ThinkPad X13sの仕様すべてに満足しているわけではないが、発熱と引き換えで妥協できそうな点は多い。しかし次の気になる点としてあがるのはアプリケーションや開発言語、各種ミドルウェアのArm64対応状況である。

最近、メジャーなアプリケーションや開発言語およびそれに関連するミドルウェアのArm64対応は進んでいるようだが、それでも自分が普段から利用しているものに関しては未知な部分がある点は否めない。

ThinkPad X13sを買ってはみたものの必要なものが動作せず、結局お金の無駄づかいになってしまっては困る。もっと選択肢が広がるまで待つべきか、Arm版Windowsが一般的になるまで待つか、そんなことを考えているときに見つけたのがMicrosoftから販売されている『Windows 開発キット 2023』。

www.microsoft.com

スペックは

  • Snapdragon 8cx Gen 3
  • メモリ 32GB
  • Windows 11 Pro
  • SSD 512GB

と開発向けとしては十分。

これならx64からArm64へ乗り換えるにあたって、以下の検証を実施できそうだ。

  • 各種ソフトウェアのArm64対応状況
  • 開発環境としての性能
  • 開発時の発熱

即購入した。また今後登場が期待されるSnapdragon 8cx Gen 4に向けての準備もできそうだ。

Chocolateyを捨て、Ubuntuを捨て、新たな環境にチャレンジ

Windows 開発キット 2023が届いたので、最低限これがあれば問題ないだろうという開発環境を作った。

winget

まず必要なソフトウェアのインストールはwingetを使うようにした。

learn.microsoft.com

これまでChocolateyを利用していたが、商用色が出てきたのとパッケージ検索への導線が少しずつトップページから遠ざかっていくことにいら立ちを感じていたので、これを機に利用をやめた。

wingetだとストアアプリまで対象とできるので便利だ。

Alpine Linux on WSL2

これまでなんとなく使っていたUbuntu。ディスク容量節約にならないかと思い、Alpine Linuxを使ってみることにした*4。

learn.microsoft.com

www.alpinelinux.org

作り方としては

  1. Alpine Linuxのダウンロードサイトにある『MINI ROOT FILESYSTEM』からaarch64版をダウンロードする
  2. ダウンロードしたファイルはtarファイル化しておく
  3. wsl --import <DistroName> <InstallLocation> <InstallTarFile>書式を使ってインポートする
    1. 自分は以下のコマンドにした
    2. wsl --import AlpineLinux C:\Distro .\alpine-minirootfs-3.18.3-aarch64.tar
    3. C:\Distroにvhdxファイルが作成される

という手順になる。

なおルートユーザーしかいないので、デフォルトユーザーの変更は/etc/wsl.confを作ってその中に定義しておく。sudoなんかもないので、先にルートユーザーで必要な環境を整えてから、デフォルトユーザーの変更を行うとよい。

ちなみに/etc/profileにexport PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"がある影響で本来のPATHが上書きされている。これだとWindows側のPathを参照できず相互運用に支障をきたすので、これをコメントアウトしてwsl --shutdownする。

Oh My Posh

ターミナル見た目変更のため。PowerShellとWSL2、両方にインストール。

ohmyposh.dev

Visual Studio 2022など

Visual Studio 2022や.NETはArm64対応しているので問題なくインストールできる。WPFアプリをプラットフォームx86でビルドしてみたが問題はなさそうだ。ビルドしたアプリも起動する。

marketplace.visualstudio.com

惜しむらくはInstaller Projects 2022がArm64非対応＼(^o^)／ｵﾜﾀ

https://developercommunity.visualstudio.com/t/Microsoft-Visual-Studio-Installer-Projec/1381244

こちらで対応を求める声があがっているが、2年経過しても対応していないところを見ると期待できないか・・・。

docker関連

wiki.alpinelinux.org

上のドキュメントを参考にして、以下の設定を行う。

# rc-serviceを使うためにOpenRCインストール
sudo apk add openrc --no-cache
sudo mkdir /run/openrc
sudo touch /run/openrc/softlevel

# dockerインストール関連
sudo apk add docker --no-cache
sudo addgroup username docker
sudo rc-update add docker default

# 以下rootless用の設定
echo 'https://dl-cdn.alpinelinux.org/alpine/edge/community' | sudo tee -a /etc/apk/repositories
sudo apk update
sudo apk add docker-rootless-extras --no-cache
sudoedit /etc/rc.conf
  これ追加 -> rc_cgroup_mode="unified"
sudo rc-update add cgroups

# Docker composeインストール
sudo apk add docker-cli-compose --no-cache

そしてdocker起動を試みるがすでに起動しているという警告が発生。

sudo rc-service docker start
* WARNING: docker is already starting

ステータスを確認すると停止済み。謎。

sudo rc-service docker status
 * status: stopped

/etc/wsl.confに設定が足りていなかったようなので、sudoedit /etc/wsl.confで以下を追加。

[boot]
command = "/usr/bin/env -i /usr/bin/unshare --pid --mount-proc --fork --propagation private -- sh -c 'exec /sbin/init'"

再度、起動を試みるがネットワークエラーのため起動できず。

sudo rc-service docker start
 * Starting networking ...
ifquery: could not parse /etc/network/interfaces
 * ERROR: networking failed to start
 * ERROR: cannot start docker as networking would not start

どうやらネットワーク設定が足りていなかったらしくsudoedit /etc/network/interfacesでファイルを作成して以下を追加。

auto lo
iface lo inet loopback

作成後にsudo rc-service networking restartしてネットワークを再起動した後にdockerを起動したら無事に起動した。

sudo rc-service docker start
 * /var/log/docker.log: creating file
 * /var/log/docker.log: correcting owner
 * Starting Docker Daemon ...

それでこのあと、Docker composeを利用している適当なリポジトリでdocker compose up -dを実行するもCannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?が発生し途方に暮れていたが、Windowsを再起動したら解決した。

終わりに

dockerが一番苦労した。

ちなみに解決していない問題としてanyenv＆nodenvによるnpmコマンド実行が残っている。

node -v
/home/username/.anyenv/envs/nodenv/versions/18.17.1/bin/node: fcntl64: symbol not found

上記のエラーが発生してしまい、yarnがインストールできずに進められない。

追記：解決

単純にコンパイラの違いからくるエラーだったようだ。Alpine Linuxはmusl libcを使ってコンパイルするが、ダウンロードしてくるバイナリはglibcを使ってコンパイルしたもの。

nodenvを利用したコンパイル手順を記事にしたので、同じ境遇の方は参考にしてほしい。

jupitrisonlabs.hatenadiary.jp

ちなみにコンパイル中のWindows 開発キット 2023は熱かった。ファンレスだからしょうがないのかもしれない。ファンが備われば温かいぐらいに熱は下がるのかもしれない。

*1:膝に置けないので机必須

*2:漠然とした感想だが

*3:ちなみに32GB仕様のThinkPad X1 Carbon Gen 9でサーマルスロットリングが発生していて性能低下中

*4:結局dockerを使うと使用量が激増するのだが・・・