koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

Next.jsのpublic配下の画像をS3から配信したら画像が表示されなくなった

<Image src="/images/hoge.png" alt="" ... />

Next/Imageでの↑ように画像表示をしている状態で画像の配信構成を変えたら表示が全滅した。

before

flowchart LR
    UA --> CloudFront
    CloudFront -- default --> Next.js

after

flowchart LR
    UA --> CloudFront
    CloudFront -- default --> Next.js
    CloudFront -- /images/* --> S3

にしてNext.jsのコンテナイメージ*1からは画像を消し飛ばした。

そうしたら

The requested resource isn't a valid image.

表示になった。

ちゃんと裏付けは取っていないのだけれど、Next/Imageのloaderはサーバー絶対パス*2指定された画像は自身の実行環境のファイルシステムから探すのだろう。それはそうだ。スキーム、ドメインは書かれていないし、loaderの実行環境ではそれらが何だったのかは本質的には分からない。

※Next/Imageは任意の画像最適化処理、ローダに画像のURLを渡してくれる、既定のローダではhttps://example.com/_next/image?url=%2Fimages%2Fhoge.png&w=1920&q=75のようなURLでローダを呼び出す(img要素のsrc属性に指定する)。

Next/Imageに限らず、画像を動的にオプティマイズする際には画像の指定を絶対URL*3で指定するのが基本なのだろう。

Next/Imageでは例外的にpublic配下に置いて自分の支配下にある画像も指定できると捉えるのが良さそうだった。

で、その場合は支配下にあるリソースは実行環境にちゃんと配置しなくてはならない。

静的ファイルやろ! と/_next/static配下と同じノリでオブジェクトストレージに逃がしたのがいけなかった。

そんな感じ。

*1:コンテナでNext.jsを動かしていた

*2:呼び方違うかもだけれど要は/images/hoge.pngのような指定

*3:httpsから始まる完全なURL

C#で書いたPlaywrightのテストをGitHub Actionsで動かす

Playwrightは結構いろんな言語でテストを書ける

C#Microsoft.Playwright.MSTestの場合、Playwrightのインストール用のスクリプトが付属している*1ため、それを実行してやればGitHub Actionsのワークフローで実行できる。

毎回インストールするのは不経済な気もするけれど、とりあえず動いているのでよし!

E2ETest/E2ETest.csprojMicrosoft.Playwright.MSTestを用いたテストプロジェクトがある場合のワークフローはこんな感じになる。

name: Playwright Test
on:
  workflow_dispatch:
env:
  DOTNET_VERSION: 8.x.x
jobs:
  e2e:
    runs-on: windows-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ env.DOTNET_VERSION }}
    - run: dotnet restore E2ETest/E2ETest.csproj
    - run: dotnet build E2ETest/E2ETest.csproj --no-restore
    - run: pwsh E2ETest/bin/Debug/net8.0/playwright.ps1 install --with-deps
    - run: dotnet test E2ETest/E2ETest.csproj --no-build --verbosity normal

CI GitHub Actions | Playwrightには以下のような感じでインストールするといいんじゃないの? って書いてあるけれど、.NETラッパーを使ってる場合はこの限りではない様子だった。

     - uses: actions/setup-node@v3
     - name: Install playwright browsers
       run: npx playwright install-deps chromium

そんな感じ。

*1:Playwrightがインストールされていない環境で実行すると、このスクリプトを叩いてインストールしろってメッセージが出る

Azure Functionsの従量課金AppのZIPデプロイに容量不足で失敗したら発行時のアーキテクチャを指定するといいのかもしれない

タイトルが全て。.NETのバージョンは.NET6(関数アプリのインプロセスモデルが現状は6まで対応なので)。

あるFunction AppGitHub ActionsのActionでデプロイしようとしたら There is not enough space on the disk.\r\n\r\nが出力されるのが趣深い)で失敗してイラついていた。

App setting SCM_DO_BUILD_DURING_DEPLOYMENT propagated to Kudu container
Setting ENABLE_ORYX_BUILD in Kudu container to false
Update using context.kuduService.updateAppSettingViaKudu
Response with status code 204
App setting ENABLE_ORYX_BUILD propagated to Kudu container
Package deployment using ZIP Deploy initiated.
Fetching changes.
Cleaning up temp folders from previous zip deployments and extracting pushed zip file C:\local\Temp\zipdeploy\zcwve14g.zip (179.97 MB) to C:\local\Temp\zipdeploy\extracted
There is not enough space on the disk.\r\n
Error: Failed to deploy web package to App Service.
Error: Execution Exception (state: PublishContent) (step: Invocation)
Error:   When request Azure resource at PublishContent, zipDeploy : Failed to use D:\a\_temp\temp_web_package_7244580107888943.zip as ZipDeploy content
Error:     Package deployment using ZIP Deploy failed. Refer logs for more details.
Error: Deployment Failed!

file C:\local\Temp\zipdeploy\zcwve14g.zip (179.97 MB)

とのことなので、展開前で180MBほどの容量があるっぽいけれど、展開したって一桁GBにはおさまるだろう? そんなしょっぱい容量でディスクが枯渇していいのか?

とは言え、従量課金でやりたい(し、App Service PlanのFreeにしても容量が劇的に容量が増えるわけでもないだろう)ので、何とかデプロイが通るようにしたい。

デプロイ用の成果物には実行環境以外のアーキテクチャアセンブリも同梱されている雰囲気があったので、ビルド時にランタイムとアーキテクチャを指定したら疎通した。

    - name: Restore
      run: dotnet restore "${{ env.WORKING_DIRECTORY }}" --runtime win-x64
    - name: Build
      run: dotnet build "${{ env.WORKING_DIRECTORY }}" --configuration ${{ env.CONFIGURATION }} --arch x64 --no-restore
    - name: Publish
      run: dotnet publish "${{ env.WORKING_DIRECTORY }}" --configuration ${{ env.CONFIGURATION }} --arch x64 --no-build --output "${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}"

dotnet restoredotnetdotnet build,dotnet publish--arch x64が該当箇所。

コマンド毎に指定の仕方がちょっと違うのはなんでか分かっていない(runtime(RID)が正で、archはそれの簡易構文らしいが、分けるメリットがよく分からん)。

各プロジェクトファイルに妥当な指定がされていればdotnetコマンドのオプションは不要っぽいのだが、そんなものを精査するよりオプション指定してしまった方が手っ取り早いのでそうした。趣味の遊びでDeep Diveしたい領域ではない。

指定前

The raw size of all the files that were specified for upload is 424107130 bytes
The size of all the files that were uploaded is 171362747 bytes. This takes into account any gzip compression used to reduce the upload size, time and storage

指定後

The raw size of all the files that were specified for upload is 271871447 bytes
The size of all the files that were uploaded is 103138755 bytes. This takes into account any gzip compression used to reduce the upload size, time and storage

オチ(この画像を生成するFunction Appのデプロイに失敗していた)もついてちょうどよい。そんな感じ。

プラモの写真を光らせたい x Blazor WebAssembly x OpenCV

デジラマを作るほどの気持ちはないのだれど、プラモの写真を少し加工してカッコよくしたい程度の気持ちがある。

Blazorのカレンダー | Advent Calendar 2023 - Qiitaの14日目です。昨日は"ゲームなどでよく見る「長押しのボタン」のUIをWEBで表現してみた" を Blazor で実装してみた #Blazor - Qiitaでした。ぼちぼちHTML要素のネイティブなイベントでフォローされたい。

一応はてなエンジニア Advent Calendar 2023 - Hatena Developer Blogの14日目でもあります。こちらの昨日はid:Windymeltシンプルで使いやすいマイクロHTTPフレームワーク『Cask』を紹介するよ - Lambdaカクテルでした。←これは一昨日で、13日目はid:maiyama4iOS アプリのマルチモジュール開発とインターフェースモジュール - maiyama logでした。実践的な記事の後にプラモを光らせて笑って終わりな記事でスマン。

はてなのエンジニアの日曜プログラミング感のサンプル数1を垣間見ることができます*1

自分の趣味の大部分はプログラミングとプラモデリングで、後者の記事である好みのシェルエットのガールズプラモを作る - koudenpaのブログでは、フォトレタッチソフトで少し剣を光らせたのだが、以下のような気持ちが強い。

今の時代ならAIに「剣を青く光らせて!」と指示したらもっといい感じにしてくれそうなものだけれど、どういうAIツールなら実現できるかなど分からなかったのでとりあえずは諦めた。

もっと泥臭く、

  1. 画像中の物体検出する
  2. 物体を選択させる
  3. 深度を得て3次元データを作る
  4. 選択した物体に光源を置いてレンダリングする

このような実装をできる人ならできるような気はする。

できる人ならな。

僕には画像処理ライブラリのコマンドを叩く程度のことしかできない。

それでも、エッジ検出して再度の高い色で塗れば多少それっぽくなるんじゃないか?

スーパーファミコン時代のステータス異常的な?

というわけでそういうBlazor WebAssemblyアプリを作った。

技術選定はスマホでポチポチしたい。WebAssemblyのOpenCVをちょっと触っておきたい。程度の理由による。

こうなった。

7474.github.io

無敵か? だがこれはプラモではない

魔炎気か? だがこれもプラモではない

リポジトリ GitHub - 7474/HikaraseTatiner

感想。

  • Blazor WebAssemblyはWebブラウザで動くGUIアプリをサッと作れて便利
  • OpenCVSharp)はWebAssemblyでも結構すばやく動く
  • .NETのWebAssemblyランタイムで画像のエンコード・デコードは遅すぎて地獄(試せばわかる遅さ)(WasmのOpenCVにはPNGJPEGのエンコーダ・デコーダの実装はない)
  • ラインデバッグVisual Studioでブラウザにアタッチ)が異様に重いのが厳しかった
  • Wasmの世界でCLIラッパー経由でWasm実装のOpenCVを使う意義があるかというと謎
  • 良い感じの画が欲しいならAdobeに課金した方が良い

以上、日曜プログラミング&プラモデリングでした。


余談

皆さんの職場にガンプラはありますか?

2023年12月下旬に株式会社はてなの京都オフィスに行くと、HGUCデンドロビウムを組み立てている様子を見学できるとの噂があります。

僕にはオフィスに完成すると全長1m超のプラモデルを持ち込むクソ度胸はない(そもそも普段出社してないし)のだけれど、自宅で組むのも厳しいサイズなのは確かなので東京オフィスで競作するのも悪くはないような気がしなくもない。

目下最大の悩み事である。

*1:記事内容と仕事の関連はほぼゼロです

タダ同然だと思いこんでクラウドリソースに課金し続ける方法

去年こんな記事を書いていました。

koudenpa.hatenablog.com

論より証拠なのでプライベートなAzureサブスクリプションの請求書一覧をご覧いただこう。

面倒くさいので請求書一覧のスクショを貼ってしまう

昨今の円安の影響でクラウドへの課金額は増えてしまうのだけれど*1、それにしたって9月と10月の差が激しすぎやしませんか?

何故か!?

従量課金だけだと思っていたAzure Front Doorに月額課金があったからでした。アホか?

ウケる

ちょっと試してみたいと思って作ったFront Doorを「どうせ大した額にならないだろう」とCDN代わりにしていました。バカじゃん?

まぁまぁいい感じの勉強代を今年も払ってしまいました。

「従量課金額こんなもんか、よゆー」とリソースを作って放置するとこうなることができます。

皆さんはちゃんと時間課金の有無をちゃんと確認しましょう。

あと、毎月請求書やクレジットカードの明細を確認しましょう。

なお、僕は去年の教訓を全く生かしていないアホです。

AWSのコストアラートは設定したし、Azureの予算アラートも設定*2してはありましたが無視していたし、クレジットカードの明細なんてちゃんと見やしません。

この分だと来年はGoogle Cloudに何か課金することになりそうです。


本記事はちょうどいい日付に空きがあったMicrosoft Azure Advent Calendar 2023に登録してあります。

qiita.com

*1:実際Visual Studioの値上がりでも増えてる

*2:設定しない人は設定した方が良いですよ! そしてアラートの通知が来たらちゃんと見ましょう

ECS Fargate + ecspresso + GitHub Actions 運用構成例

先日の記事でECS Fargate*1をアゲたので、どういう使い方の実感でアゲたのか軽くメモしておく記事。

AWS Containersのカレンダー | Advent Calendar 2023 - Qiitaにも登録しておいた。

手軽に箇条書きです。

*1:Amazon Elastic Container Service(Amazon ECS)のAWS Fargateが正しいか?

続きを読む

AWS App Runner 振り返り 2023~決別・ECSを使うぞ~

AWS Containers Advent Calendar 2023の4日目です。

qiita.com

AWS App RunnerAWSで手軽にコンテナを動かせるサービスで、2021年にGAしてから緩やかに使用しつつ所感を書いてきた。

去年のAWS App Runnerのカレンダー | Advent Calendar 2022 - Qiitaではサービス内容の振り返りをしたのだが、今年は記事のタイトルにも書いた通りApp Runnerを自分の中でどう位置付けたのかの整理記事とした。正直サービス内容には振り返るネタ(更新)もあまりない。

続きを読む