長く続けてきたいろんな事が終わった。
いろんな人が去って、離れていき。
楽しかった事、場所に興味が薄れてきて、
人生の中の「もう会う事もないだろうな」、な人の数が一気にカウントアップ。
大事にしてた服も断捨離してスッキリした。
なんだか終わりの季節を感じる。
多分、周りの人には何も変わってないように見えるのだろう。

ただ、何か新しい事が始まればいい。
まだまだ続いていくものもあるから。

laravelでcronによる処理と、管理画面などのログインが共存しているとタイトルのようなエラーになる場合がある。というか私の場合だけかもですがありました。

原因は/storage/framework/cache/data/配下のディレクトリ、ファイルのパーミッションが

ログイン時：個人ユーザー

cron実行時：nginxユーザー

とで作成されるために、どちらかのユーザーでchownとかしても一時的に解決するだけで永続的な解決法ではなくなっていたためでした。

プログラム的になんとかする方法（ログイン時ユーザーをnginxでcacheさせるようにする等）もあると思いますが、今回はlinux側での対応を行ったので、備忘録です。

cacheディレクトリ、ファイルのパーミッションが問題なので、そもそも新規に作成される場合のパーミッションを指定・固定します。

$ cd /storage/framework/cache/

$ sudo setfacl -R -d -m g::rwx ./data

setfaclでdataディレクトリ配下で作成されるディレクトリ、ファイルのパーミッションをdataと同じにするものです。

※上記操作と共に既存ディレクトリ、ファイルのchmodも忘れずに

※作成される可能性のあるユーザー（個人ユーザー、nginx）を同一のグループに所属させる事も忘れずに

これで、ユーザーは異なるものになる可能性はありますが、パーミッションは書き込み可能となるのでエラーにはならなくなりました。

「お前は何を言っているんだ？」という人は以下を参照ください。この記事の1000倍くらい丁寧に解説されています。

CentOS/Apache/Laravel使用時のpermission設定方法

分かりにくいタイトルですが、要するに複数のインスタンスをALB（ロードバランサー）で振り分けてる場合に、「このURLの場合はこのインスタンスに固定でアクセスさせたいなぁ。」といった場合、簡単に設定できるという事です。

複数WEBサーバをバランシングしてるが、とある事情で片方のインスタンス（WEBサーバ）にしか無いAPIをhttpsで叩きたい、というような要件があった場合です。

今回既に稼働しているシステムだったので、ロードバランサーは設定済み。そこへ振り分けのルールを追加していきます。

手順は2つ。

１．ターゲットグループ作成

２．リスナールール設定

だけです。

「ターゲットグループ」から後でリスナーで設定する振り分け先インスタンスの設定を行います。

気を付けたいのは、ヘルスチェックの設定でしょうか。

この部分を設定しておかないと、動作してくれないみたいです。

ターゲットグループが設定できたら、リスナーの設定。

追加します。

ルールは上に設定したものから順次判定されるみたいで、自由に優先順に設定できるようです。

「ルールの挿入」を押下すると、設定フォームが表示されます。

条件は結構細かく指定できるようですが、今回は特定のURLで判定させたいので「パス」を選択。

ドメイン以下のパスを設定して、このURLでアクセスされた場合に振り分けるターゲットグループを設定します。

上記では「https://hugahuga.com/hogehoge/index/」にアクセスされた場合に「web1」のターゲットグループで指定したインスタンスにアクセスさせたい、という感じです。

シンプルにこれだけで、設定は完了。

ブラウザなどで叩いてみると、ちゃんと指定したインスタンスにアクセスしているようです。

うちの車はなんか知らんが、芳香剤入れないと異様に臭う。汗臭いのか革の臭いなのかよくわからない独特のにおいがするので、とりあえず純正の芳香剤（パフュームアトマイザー）を使ってます。

これ、匂いは良くて付けておくと自動的に拡散してくれるので良いのだが、値段がアレです。さすがにベンツです。

8000円以上するけど、2年くらい持つのかな。そう考えるとそれほど高いものではないのかも。

子供が学校で体力測定したらしく「握力が全然ない！」と騒いでいたので、ポチってみました。

人の事言えなかった。

事務所の水やらが無くなってきたのでコストコへ。

入る時にマスクしてなかったら

「マスクして下さい！マスク持ってますか？！」

だって。まだまだ終わりそうに無いねぇ。

かなり期待してました。が、まぁコスパは良く無いですね。牡蠣が99円というのは驚きましたが、その他のメニューが…。全般的に高めで、渋谷ってこんなに高いのかと驚きました。さすが都会。

ネギ間の焼き鳥が一本確か580円くらいだったので、相当なデカさのヤツが来るのかなと思ってたら、まぁ普通。少し大きいかなくらい。250円てとこじゃないかなぁ。

極め付けは看板にドドーン！と写っているウニの四種盛り。「この量で3800円？！安いかも！」と思ってそれを3人分頼んだら、まぁ少ないこと、唖然としました。

これなら、少し良い回転寿司の軍艦食べた方が満足度は高そうです。いや、間違いなく高い。

量的にも全然満たされないので最後にご飯でもと、痛風の人が泣いて逃げ出しそうなヤツを注文。

写真だと大きそうに見えるけど実際は量は少な目で良かったです。

結果、3人で35000円とかでした。うち1人は女性で殆ど食べてなかったのでコスパ具合が分かるかと思います。

お金のある人はネタで行くのもいいかと思います。私はもう行かないと思います。

マスターに山崎の12年と白州の12年を勧められて飲んだら二日酔いです。

タイトル通り、pythonでSESからメール送信してみました。

今回は既に運用中のAWSアカウントにて設定したので、セットアップとかは省略。また、送信先については固定で1つだけなので制限解除申請などはしてません。

手順としては、

１．SES側での送信先メールアドレス認証作業

２．AMIで認証情報作成

３．python実装

という感じ。

SES側での送信先メールアドレス認証作業

登録と検証を行わずに送信しようとするとエラーに。

Email address is not verified. The following identities failed the check in region US-WEST-2:[送信先メールアドレス]

とりあえず、SESの画面から送信先を登録。

検証メールを送信してメール内のURLをクリックするだけで完了。簡単。

AMIで認証情報作成

こちらも既存のユーザーに認証情報タブからアクセスキーの作成を実行して保存。簡単。

python実装

いろいろやり方はあると思いますが、とりあえず公式のやり方が無難だろうという事で、こちらを参考。

https://docs.aws.amazon.com/ses/latest/dg/send-email-raw.html

なぜかアクセスキーとかセットする部分が無かったので、このままだとエラーに。

botocore.exceptions.NoCredentialsError: Unable to locate credentials

なので、

client = boto3.client(‘ses’,region_name=AWS_REGION)

この部分を

久しぶりの更新がこれかよですが、何かの約に立つかなと。

目的：

とあるサイトへのスクレイピング。

pythonはほぼ初めてだったが、まぁスクレイピングくらいならそれほど難しくはないですね。

やったこと：

とあるサイトにヘッドレスchromeで接続し、CSVをダウンロードする、というものです。

とりあえずEC2立ち上げ。

これは特に凝ったことはせず、とりあえずAmazonLinuxなインスタンスを立ち上げ。

ec2-userでログインしたら、以下実行。

「DevToolsActivePort file doesn’t exist」