AWS Lambda の Arm64 対応試してみた の続き。 Achieve up to 34% better price/performance with AWS Lambda Functions powered by AWS Graviton2 processor 前回は クロスコンパイルが簡単な Go で試してみました。 でもやっぱり・・・皆さん Perl を動かしたいですよね？ というわけでご用意しました。 ARN 一覧 ランタイム本体 ランタイム本体のビルド済みレイヤーです。使い方は過去記事をどうぞ。 AWS LambdaでCGIを蘇らせる arn:aws:lambda:ap-northeast-1:445285296882:layer:perl-5-32-runtime-al2-arm64:1 arn:aws:lambda:ap-south-1:445285296882:layer:perl-5-32-runtime-al2-arm64:1 arn:aws:lambda:ap-southeast-1:445285296882:layer:perl-5-32-runtime-al2-arm64:1 arn:aws:lambda:ap-southeast-2:445285296882:layer:perl-5-32-runtime-al2-arm64:1 arn:aws:lambda:eu-central-1:445285296882:layer:perl-5-32-runtime-al2-arm64:1 arn:aws:lambda:eu-west-1:445285296882:layer:perl-5-32-runtime-al2-arm64:1 arn:aws:lambda:eu-west-2:445285296882:layer:perl-5-32-runtime-al2-arm64:1 arn:aws:lambda:us-east-1:445285296882:layer:perl-5-32-runtime-al2-arm64:1 arn:aws:lambda:us-east-2:445285296882:layer:perl-5-32-runtime-al2-arm64:1 arn:aws:lambda:us-west-2:445285296882:layer:perl-5-32-runtime-al2-arm64:1 Paws AWS SDK for Perl のビルド済みレイヤーです。ランタイム本体と合わせてご使用ください。 AWS SDK for Perl Lambda Layerを公開しました arn:aws:lambda:ap-northeast-1:445285296882:layer:perl-5-34-paws-al2-arm64:1 arn:aws:lambda:ap-south-1:445285296882:layer:perl-5-34-paws-al2-arm64:1 arn:aws:lambda:ap-southeast-1:445285296882:layer:perl-5-34-paws-al2-arm64:1 arn:aws:lambda:ap-southeast-2:445285296882:layer:perl-5-34-paws-al2-arm64:1 arn:aws:lambda:eu-central-1:445285296882:layer:perl-5-34-paws-al2-arm64:1 arn:aws:lambda:eu-west-1:445285296882:layer:perl-5-34-paws-al2-arm64:1 arn:aws:lambda:eu-west-2:445285296882:layer:perl-5-34-paws-al2-arm64:1 arn:aws:lambda:us-east-1:445285296882:layer:perl-5-34-paws-al2-arm64:1 arn:aws:lambda:us-east-2:445285296882:layer:perl-5-34-paws-al2-arm64:1 arn:aws:lambda:us-west-2:445285296882:layer:perl-5-34-paws-al2-arm64:1 x86_64 レイヤー レイヤーの名前にCPUアーキテクチャーが入るようになったので、 わかりやすいよう x86_64 のレイヤー名も変更しました。 もちろん今までのレイヤー名でも同じものが利用可能です。

AWS Lambda の ARM サポートが発表されましたね。 Achieve up to 34% better price/performance with AWS Lambda Functions powered by AWS Graviton2 processor というわけで早速触ってみました。 祝日 API で試してみる 先日公開した祝日API で試してみました。 https://github.com/shogo82148/holidays-jp/pull/22 変更は実質2行です。簡単ですね！ diff --git a/holidays-api/Makefile b/holidays-api/Makefile index a39a3fa..0908902 100644 --- a/holidays-api/Makefile +++ b/holidays-api/Makefile @@ -1,6 +1,6 @@ .PHONY: build-HolidaysFunction build-HolidaysFunction: - GOOS=linux GOARCH=amd64 go build -o $(ARTIFACTS_DIR)/bootstrap -tags lambda.norpc ./cmd/bootstrap + GOOS=linux GOARCH=arm64 go build -o $(ARTIFACTS_DIR)/bootstrap -tags lambda.norpc ./cmd/bootstrap .PHONY: test test: diff --git a/template.

GitHub Actions で ID Token が使えるようになったと話題ですね。 うおー！サイコー！！！！！ https://t.co/2stS4miUOD — Tori Hara (@toricls) September 15, 2021 Ok I blogged about it. That's how excited I am. 1. Deploy this CFN template 2. Write this GHA workflow 3. Never worry about IAM users again https://t.co/KJrr2Jw4bE pic.twitter.com/9IcocgurxP — Aidan W Steele (@__steele) September 15, 2021 AWS IAM が OpenID Connect (OIDC) を使った認証 (sts:AssumeRoleWithWebIdentity) に対応しているので、認証プロバイダ(IdP)を用意してあげればシークレットの登録が不要になるということらしいです。 これは便利！ セッションタグを渡したい これはまさに「AWS_SECRET_ACCESS_KEY を GitHub Actions secrets へ突っ込むのに疲れた俺達は」で実現したかったことですね。 このままだとせっかく作ったアクションが不要になりそうで悔しいので このアクションにずっと追加したかった機能があるのですが、OIDCトークンを使うと簡単に実装できそうだったので、お試しで追加してみました。

プログラマーなら誰しも一度は祝日について頭を悩ませたことがあるでしょう(要出典)。 日付が固定ならまだ楽なんですが、「春分の日」「秋分の日」のように天体の運行によって決まる祝日があったり、 ハッピーマンデー制度によって「成人の日(一月の第二月曜日)」のような曜日固定の祝日があったり、 振替休日という概念があったりと、ちゃんと考えるとかなり面倒です。 更に面倒なのが国の施策によってたまに変更になるという点です。 東京オリンピックの延期で祝日が移動したのは記憶に新しいですね。 前年の 12 月 4 日に法律が公布されるという、カレンダーの印刷会社泣かせなスケジュール変更です。 2021 年の祝日移動について 東京五輪開催で夏の祝日が移動 〜各言語の祝日ライブラリの 2021 年の祝日対応を追ってみる〜 プログラムなら更新可能ですが、ライブラリとして組み込まれているとうっかり更新を忘れてしまうこともありますよね。 そういうわけで API として提供されていると嬉しいな、プログラミング言語に縛られることもないし、ということで作りました。 github.com/shogo82148/holidays-jp holidays-jp.shogo82148.com 使い方 パスに日付を入力して GET リクエストを投げるだけのシンプルな API です。 ある年の祝日一覧を取得する GET /{year} で year の祝日一覧を返します。 以下は 2021 年の祝日一覧を返す例です。 curl https://holidays-jp.shogo82148.com/2021 | jq . { "holidays": [ { "date": "2021-01-01", "name": "元日" }, { "date": "2021-01-11", "name": "成人の日" }, { "date": "2021-02-11", "name": "建国記念の日" }, (snip) { "date": "2021-11-23", "name": "勤労感謝の日" } ] } ある月の祝日一覧を取得する GET /{year}/{month} で月の祝日一覧を返します。 以下は 2021 年 1 月の祝日一覧を返す例です。

今日はちょっとした小ネタを dependabot が作ったプルリクエストを整理していたら AWS Go SDK のリリースノートに面白そうなリリースを発見。 Release v1.40.0 (2021-07-14) aws/session: Support has been added for EC2 IPv6-enabled Instance Metadata Service Endpoints (#4006) こんなところにも IPv6 の波が！ 早速試してみようと思ったんですが、なかなかうまく行かない。 今日ようやくやり方がわかったのでメモしておきます。 インスタンスメタデータ IPv6 エンドポイントを有効化する リリースのアナウンスによるとインスタンスメタデータサービス(IMDS)の IPv6 エンドポイントは明示的に有効化する必要があるそうです。 IPv6 endpoints are now available for the Amazon EC2 Instance Metadata Service, Amazon Time Sync Service, and Amazon VPC DNS Server To get started, you need to enable the IPv6 endpoint for IMDS on your EC2 Instances.

最近 Mackerel の AWS インテグレーション機能にいくつかセキュリティ強化のアップデートが入りました。 (「最近」と言っても最も古いアップデートは 2 年前ですが・・・) AWS インテグレーションで IAM ロールによる認証利用時の権限チェック頻度を変更しました ほか AWS インテグレーション CloudFront 連携で取得できるメトリックを追加しました ほか 【リリース予告】AWS インテグレーションの権限チェックを強化していきます AWS Step Functions インテグレーションをリリースしました　ほか これらのアップデートは「混乱した代理問題(Confused deputy problem)」に対応するものです。 僕が AWS インテグレーションの設定をしている際にふと 「この機能、攻撃に利用できるのでは？」 と思いついてしまったので、 Mackerel サポートに問題点を伝えて修正していただきました。 リリース記事に関連する AWS のドキュメントが貼ってありますが、正直 AWS のドキュメントは難しい・・・。 そういうわけで、Mackerel の AWS インテグレーションを例に「混乱した代理問題」を噛み砕いて解説しよう、というのが本記事の趣旨です。 (いちおう Mackerel のサポートから許可は頂いています。) TL;DR 「詳しい解説とかいらない！」という方も、最低限これだけはやっておきましょう。 Mackerel の AWS インテグレーション を利用している場合、以下の項目を確認すること。 Mackerel の AWS インテグレーション設定のページ で各設定の「編集」をクリックし、ロール ARN に緑のチェックマークが入っていること 連携用の AWS IAM Role に External ID (外部 ID)が設定されていること 設定されていても Mackerel-AWS-Integration になっている場合、それは古い設定です。今すぐ更新してください！ AWS インテグレーションのような「アクセス権の委任」を使った機能を提供する場合は以下の点に注意すること。

AWS Lambda で CGI を蘇らせる で蘇った CGI には致命的な問題点がありました。 カウンターの値が永続化されない この問題を Elastic File System(EFS) をマウントすることで解決したよ、というお話です。 Amazon Elastic File System for AWS Lambda もう一年前になるんですが、 AWS Lambda の環境に Elastic File System(EFS) をマウントできるようになりました。 新機能 – Lambda 関数の共有ファイルシステム – Amazon Elastic File System for AWS Lambda 従来 AWS Lambda でデーターを永続化するには DynamoDB, RDS, S3 といったデーターストアを別途用意する必要がありました。 ファイル書き込みができる領域として /tmp がありますが、 /tmp は 512MB に制限されていたり、永続化できなかったりと、用途は限定されます。 EFS がマウントできることによって実質これらの制限がなくなります。 プログラムからは普通のファイルとして見えるので、読み書きをするのも簡単です。 よし、じゃあ、 CGI の書き込み先として試してみるか！と思ったものの、 先のリリースを見つけたときには既に別の方がやってました。 懐かしの CGI 掲示板スクリプトを AWS Lambda ＋ EFS で動かしてみた AWS::Lambda を利用してもらって非常にありがたいのですが、作者が遅れをとるとは不覚・・・ 自ら二番煎じをする必要もないかと、ずっと放置していたのでした。

先月 AWS App Runner という新サービスがリリースされました。 📣 新サービス #AWSAppRunner のローンチです！🚀 ＼数クリックでソースコードやコンテナイメージをデプロイ！／ AWS Fargate より高い抽象度、あるいは AWS Lambda のようなスレッドではなくプロセスそのものを実行したかった方にぜひお試しいただきたいサービスです！1/nhttps://t.co/LPFNOP7CBT — Tori Hara (@toricls) May 18, 2021 既にたくさんのデプロイしてみた系の記事が公開されていますが、流石に(残念ながら？) Perl をデプロイしている人はいないですよね？ と言うわけで、ネタがかぶらないよう Perl でやってみましょう。 ソースコードは shogo82148/perl-on-aws-app-runner においてあります。 2022-02-13追加 NEW!! VPC への接続がサポートされ RDS へもつながるようになりました！！！ AWS App Runner に Perl をデプロイして RDS につなげてみた PSGI アプリを用意する Wikipedia の PSGI のページに書いてあった例をそのまま使います。 # app.psgi my $app = sub { return [200, ['Content-Type' => 'text/plain'], ["hello, world\n"]]; } Dockerfile を用意する PSGI アプリを起動するのに Plack を使用するので、 cpanfile に Plack への依存を書いておきます。

Perl 5.34 がリリースされましたね。 と、言うわけで、 AWS::Lambda と actions-setup-perl に Perl 5.34 を追加しました。 AWS::Lambda AWS Lambda Layers の ARN 一覧はこちら。 具体的な使い方は過去の記事を参考にどうぞ。 もちろん大阪リージョンも入ってますよ！ Amazon Linux 2 ベース Perl ランタイム arn:aws:lambda:af-south-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:ap-east-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:ap-northeast-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:ap-northeast-2:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:ap-northeast-3:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:ap-south-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:ap-southeast-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:ap-southeast-2:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:ca-central-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:eu-central-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:eu-south-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:eu-west-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:eu-west-2:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:eu-west-3:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:me-south-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:sa-east-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:us-east-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:us-east-2:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:us-west-1:445285296882:layer:perl-5-34-runtime-al2:1 arn:aws:lambda:us-west-2:445285296882:layer:perl-5-34-runtime-al2:1 Paws レイヤー arn:aws:lambda:af-south-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:ap-east-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:ap-northeast-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:ap-northeast-2:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:ap-northeast-3:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:ap-south-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:ap-southeast-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:ap-southeast-2:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:ca-central-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:eu-central-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:eu-south-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:eu-west-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:eu-west-2:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:eu-west-3:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:me-south-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:sa-east-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:us-east-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:us-east-2:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:us-west-1:445285296882:layer:perl-5-34-paws-al2:1 arn:aws:lambda:us-west-2:445285296882:layer:perl-5-34-paws-al2:1 合わせて Docker Image も公開済みです。

全国の Android エンジニアの皆さんこんにちは。 弊社では過去に maskarade/gradle-android-ribbonizer-plugin という Gradle Plugin を使っていたのですが、 メンテナンスされている様子がないので、フォークして自前のパッチを当て shogo82148/gradle-android-ribbonizer-plugin で開発を続けていました。 (何をするプラグインなのかは本題ではないのでまた今度) コンパイルした jar ファイルは jcenter で公開していたのですが、皆さんご存知の通り 5/1 を持って閉鎖してしまいました。 Into the Sunset on May 1st: Bintray, GoCenter, and ChartCenter 猶予期間として 1 年はダウンロード可能ですが、既に新規のアップロードはできなくなっています。 そういうわけで、重い腰を上げて Maven Central へ移行することにしました。 リリース作業 Maven Central Repository への公開手順(Gradle 版) の記事を参考に以下の手順でリリースを進めます sonatype の JIRA で issue を通してリポジトリ作成を依頼 GnuPG で jar を署名できる環境を作成 Gradle プラグインでリポジトリへ登録 Repository Manager で Maven Central Repository へリリース sonatype の JIRA で issue を通してリポジトリ作成を依頼 リポジトリ作成を依頼は JIRA で行います。 JIRA を使うにはアカウントが必要なので、以下のリンクから新規アカウントを発行します。