先月 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 を使うにはアカウントが必要なので、以下のリンクから新規アカウントを発行します。

「GitHub Actions から継続的デプロイをしたい！」と思ったときに、 僕の扱うデプロイ先は AWS なことが多いので AWS のキー (AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY ) を GitHub Actions secrets へ突っ込む必要があります。 まあ一回や二回ならやるんですが、デベロップメント、ステージング、プロダクション、と複数環境あったり、 プロジェクトも複数あったりして、中々の回数設定を行わなければなりません。 設定するだけでつらいのに、AWS はキーのローテーションを勧めてきます。つらい。 と言うわけで、シークレットの管理を極力しなくて済む方法を考えて、設定用の Action を作成しました。 fuller-inc/actions-aws-assume-role Configure AWS Credentials by Assuming Roles 2021-08-19 更新 「会社でも使いたいな(ﾎﾞｿｯ」と言ったら社のアカウントで管理してもらえることになりました。 それにともないアクションの URL が shogo82148/actions-aws-assume-role から fuller-inc/actions-aws-assume-role に変更になっています。 正しくリダイレクトされるようですが、念の為 URL の変更をお願いします。 信頼関係に指定する AWS アカウント 053160724612 に変更はありません。 こんなこともあろうかと専用の AWS アカウントを作成しておいたので、まるごと権限を移しました。 使い方 まずは AWS 側に IAM Role を作成します。 IAM Role の信頼関係(trust policy) には以下の内容を記載します。 信頼する AWS アカウントには 053160724612 を指定してください。 これはフラー株式会社の管理している AWS アカウントなので、フラーを信頼できる方だけこの先に進んでください。 外部 ID(ExternalId) にはこのロールを使用する予定のレポジトリ名を入れます。

Dependabot から送られてくるプルリクエストのテストが最近良くコケるようになったなあと思ったら、 3 月 1 日から GitHub Actions Workflow 内の GITHUB_TOKEN のパーミッションが変更になったそうです。 GitHub Actions: Workflows triggered by Dependabot PRs will run with read-only permissions 更新されたパッケージに secrets を盗み見るような危険なコードが含まれているかもしれません。 そのようなコードでも安全に実行できるよう read-only のパーミッションで実行されるようになりました。 その結果以下のようなワークフローが失敗するようになってしまいました。 プルリクエストにラベルをつけるような、レポジトリに対して write パーミッションが必要なワークフロー 外部サービスとのインテグレーションテストをやっていて、連携のためにシークレットを読む必要があるワークフロー 2021-12-01 追記 その後のアップデートで GitHub Token のパーミッションをワークフロー中に明示できるようになり、 dependabot もこれに従うようになりました。 GitHub Actions: Workflows triggered by Dependabot PRs will respect permissions key in workflows 以下のような設定を追加すれば、GitHub Token を使ってレポジトリへの書き込みも可能です。 # Set the access for individual scopes, or use permissions: write-all permissions: pull-requests: write issues: write repository-projects: write またこの記事中で以下のように書いていますが、

AWS 大阪リージョンが一般利用可能になりました！ AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services [AWS] 日本 2 番目となる大阪リージョン ap-northeast-3 が利用可能になりました ［速報］「AWS 大阪リージョン」正式オープン。大阪ローカルリージョンを拡張し 3 つのアベイラビリティゾーンから構成、事前申し込みなど不要に というわけで、 AWS Lambda Perl Runtime AWS::Lambda in Osaka を公開しました。 ランタイム本体: arn:aws:lambda:ap-northeast-3:445285296882:layer:perl-5-32-runtime-al2:1 AWS SDK for Perl: arn:aws:lambda:ap-northeast-3:445285296882:layer:perl-5-32-paws-al2:1 Zip Archive: https://shogo82148-lambda-perl-runtime-ap-northeast-3.s3.amazonaws.com/perl-5-32-runtime-al2.zip Zip Archive: https://shogo82148-lambda-perl-runtime-ap-northeast-3.s3.amazonaws.com/perl-5-32-paws-al2.zip 大阪の Perl Monger の皆さん、ぜひご利用ください。

常用している Mac Book Pro の OS を Big Sur に上げたんだけど、 ghq list が以下のエラーを吐くようになってしまった。 $ ghq list error failed to filter repos while walkLocalRepositories(repo): interrupted system call ghq list sometimes fails with interrupted system call #311 結論からいうと Go 1.14 から入った以下の変更が原因だったんだけど、 実際に遭遇したのは初めてだったのでメモ。 Go 1.14 でシステムコールが EINTR エラーを返すようになった Go 1.14 でランタイムに入った変更 根本的な原因は Go 1.14 リリースノート のこの辺の変更です。 A consequence of the implementation of preemption is that on Unix systems, including Linux and macOS systems, programs built with Go 1.

仕事をしているときにふとひらめいた。 Perl と Golang で実行できる Polyglot 書いてみた 文字列置換の s/// に使う記号はダブルクオーテーションでも行ける！ package main; import (s"fmt"/*"); sub import { print "Hello macotasu"; } __END__ */) func main() { s.Println("Hello macotasu") } package main; import (s"fmt"/*"); sub import { print "Hello macotasu"; } __END__ */) func main() { s.Println("Hello macotasu") } Go で dot import をしなければならない、という制限がなくなるので、自由度が上がりました。 package main; import (s"fmt"/*"); sub import { print "Hello macotasu"; } __END__ */) import "math" func main() { s.

世の中にはたくさんの OSS が公開されていて、それを Linux 上で動かす選択肢も多様になってきました。 今まで通り自前でビルドするのはもちろん, Go のようにシングルバイナリになってるならバイナリ落としてくるだけのものもあります。 DockerHub で公開されているものなら Docker でコンテナイメージをダウンロードするという手もあります。 Homebrew on Linux なんてものも登場しましたね。 選択肢が増えて動かすだけなら楽になったんですが、 事前の環境構築が最小限で済んで、バージョン管理もできて、依存もいい感じに解決してくれて、 といろいろ考えると結局は Red Hat 系なら標準のパッケージマネージャーである yum が楽なんですよね。 そういうわけで JFrog Bintray にバイナリをあげて、yum レポジトリを公開していました。 ところが今月になって 突然の Bintray 終了のお知らせ！！！ Into the Sunset on May 1st: Bintray, JCenter, GoCenter, and ChartCenter 前置きが長くなりましたね。 要するに Bintray からのお引越しを考えないといけなくなったので、 yum レポジトリを AWS S3 上に移行した、というお話です。 標準的な yum レポジトリの作り方 yum レポジトリを作るには、まず公開したい rpm パッケージが必要です。 Bintray だろうが S3 だろうが、rpm 作成の手順は一緒なので省略します。 rpm さえできてしまえば、レポジトリの作成は非常に簡単です。 createrepo コマンドをインストールして実行するだけ。 yum install createrepo createrepo /PATH/TO/REPOSITORY /PATH/TO/REPOSITORY の中を自動的に検索して、 メタデータを作成してくれます。 これをこのまま HTTP で公開すれば yum レポジトリの完成です。

GitHub Actions が一般公開された際に Perl をセットアップするアクションを書きました。 Setup Perl GitHub Action を公開しました セットアップのたびに毎回コンパイルすると遅いので、コンパイル済みのバイナリを事前に Amazon S3 にアップロードしていました。 アップロード先に S3 を選んだのは単に自分が AWS に慣れているからなのですが、最近になってちょっとした問題に直面してます。 解決へ向けて S3 から Azure Blob Storage へ移行した、というお話です。 利用する分には全く影響ないはずなんですが、Azure Blob Storage を使ってみたメモも兼ねてやったことを書いておきます。 S3 の問題点 もちろん S3 自体が悪いわけじゃなくって、単に自分の見積もりが甘かっただけなんですが、 ネットワークのアウト向きのデーター転送料が高い！！！！ これまでの僕のユースケースではせいぜい数 MB のバイナリをアップロードするだけだったのが、perl のバイナリは 1 バージョン当たり 100MB 以上あります。 Perl Monger の方々は互換性に気を使うので、いろんな OS、バージョン、コンパイルオプションでテストを実行します。 各 OS(Linux, Windows, macOS)、Perl 5.6〜5.32、multi-thread オプションありなし、という条件でマトリックスのワークフローを組むと 84 ジョブ。 単純計算で 1 ワークフローを実行するだけで、約 8GB の転送が発生するわけです。 2021-02-05 現在のアウトデーター転送料は 0.09USD/GB なので、1 ワークフローあたり 0.72USD です。 去年の秋あたりから使ってくれる人が増えたようで、転送量だけで 100USD/mo を超えるようになってきました。 趣味の範囲でやってるので、ちょっと許容できる範囲を超えてきたかな・・・ということでコスト削減に乗り出しました。