Shogo's Blog

Mar 24, 2021 - 2 minute read - Comments - github

AWS_SECRET_ACCESS_KEY を GitHub Actions secrets へ突っ込むのに疲れた俺達は

「GitHub Actions から継続的デプロイをしたい!」と思ったときに、 僕の扱うデプロイ先は AWS なことが多いので AWS のキー (AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY ) を GitHub Actions secrets へ突っ込む必要があります。 まあ一回や二回ならやるんですが、デベロップメント、ステージング、プロダクション、と複数環境あったり、 プロジェクトも複数あったりして、中々の回数設定を行わなければなりません。 設定するだけでつらいのに、AWS はキーのローテーションを勧めてきます。つらい。 と言うわけで、シークレットの管理を極力しなくて済む方法を考えて、設定用の Action を作成しました。 shogo82148/actions-aws-assume-role Configure AWS Credentials by Assuming Roles 使い方 まずは AWS 側に IAM Role を作成します。 IAM Role の信頼関係(trust policy) には以下の内容を記載します。 信頼する AWS アカウントには 053160724612 を指定してください。 これは僕の管理している AWS アカウントなので、僕を信頼できる方だけこの先に進んでください。 外部 ID(ExternalId) にはこのロールを使用する予定のレポジトリ名を入れます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::053160724612:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "your-name/your-repo" } } } ] } IAM Role に付与するパーミッションは、用途に合わせてご自由に設定してください。

Mar 17, 2021 - 2 minute read - Comments - github

Dependabot が起動する GitHub Actions Workflow から write 権限が無くなった件

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 パーミッションが必要なワークフロー 外部サービスとのインテグレーションテストをやっていて、連携のためにシークレットを読む必要があるワークフロー 対応 pull_request_target トリガーを使うと、 フォークされたレポジトリからのプルリクエストも、Dependabot からのプルリクエストも、 write 権限がついた状態で実行されます。 プルリクエストにラベルをつけるようなワークフローはこれで十分です。 問題はインテグレーションテストのためのワークフローです。 シークレットへのアクセスをともなうので、内容を確認してからインテグレーションテストを実行する必要があります。 これに関しては Dependabot によってトリガーされたワークフローを re-run したら write パーミッションで走り出した (2021-03-17 現在) ので、面倒だけどまあ毎回 re-run するか・・・と現状なってます。 (そもそもこれって意図した挙動なんだろうか?) もっといい解決方法をご存じの方は教えて下さい。 GITHUB_TOKEN のパーミッション判定の難しさ さて、失敗するとわかっているインテグレーションテストを実行する意味はないので、 read-only パーミッションで実行されていることを早い段階で検知してワークフローを即失敗させたいですよね。 しかし、今回のこの変更により GITHUB_TOKEN のパーミッションが read/write なのか read-only なのか区別することが非常に難しくなりました。 今までは「フォークされたレポジトリからのプルリクエストか?」で判定できたものが、「Dependabot から送られてきたプルリクエストか?」という条件が加わり、 さらに 「Dependabot から送られてきたプルリクエストを re-run したか?」という判定の難しい条件が加わります。

Mar 2, 2021 - 1 minute read - Comments - perl aws

AWS Lambda Perl Runtime Layer in 大阪リージョン を公開しました

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 の皆さん、ぜひご利用ください。

Feb 28, 2021 - 3 minute read - Comments - go golang

ghq list が interrupted system call で死ぬ問題を直した

常用している 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.

Feb 23, 2021 - 1 minute read - Comments - go golang perl

改: PerlとGolangで実行できるPolyglot書いてみた

仕事をしているときにふとひらめいた。 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.

Feb 21, 2021 - 2 minute read - Comments - aws

AWS Lambda + S3 を使ってyumレポジトリを作った

世の中にはたくさんの 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 コマンドをインストールして実行するだけ。

Feb 3, 2021 - 3 minute read - Comments - github perl

Setup Perl Environment Action のストレージを Azure Blob Storage に移行しました

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 です。

Jan 29, 2021 - 2 minute read - Comments -

スーパー楕円をベジェ曲線で近似してみる

最近アプリの UI で角丸アイコンを見ることが多くなりました。 この角は完全な円ではなく、スーパー楕円というものだという情報を入手しました。 スーパー楕円 UI を iOS+Swift で実装する 丸よりも丸みを感じる!? スーパー楕円の魅力とデザイン 記事の中ではベジェ曲線で近似する方法が書かれています。 なるほど、こうすれば描けるのか!と関心したので、自分でもベジェ曲線で描いてみることにしました。 スーパー楕円 スーパー楕円というのは円の方程式を以下のように拡張したものです。 {% math %} \left|\frac{x}{a}\right|^n + \left|\frac{y}{b}\right|^n = 1 {% endmath %} n は曲線を制御するパラメーターで n=2 は円となり、n>2 の場合は円と四角形のあいだのような形になります。 n が大きいほど四角形に近づいていきます。 3 次のベジェ曲線 Illustrator のようなベクターツールではおなじみのベジェ曲線です。 ベジェ曲線は任意の次数に拡張することができますが、コンピューターグラフィックスで多く用いられるのは 3 次ベジェ曲線です。 制御点を {% m %} \boldsymbol{B}_0, \boldsymbol{B}_1, \boldsymbol{B}_2, \boldsymbol{B}_3 {% em %} とした場合の 3 次ベジェ曲線の数式を具体的に書き下すと以下のようになります。 {% math %} \boldsymbol{P}(t) = \boldsymbol{B}_0(1-t)^3 + \boldsymbol{B}_1 3t(1-t)^2 + \boldsymbol{B}_2 3t^2(1-t) + \boldsymbol{B}_3 t^3 {% endmath %}

Jan 2, 2021 - 2 minute read - Comments - perl

Perl Runtime for AWS Lambda の Docker コンテナ対応を公開しました

いつかやろうと思っていた AWS::Lambdaの Docker コンテナ対応、 年を越してしまったけど、ようやく手を付けました。 AWS Lambda の新機能 – コンテナイメージのサポート 使い方 以下の handler.pl を Docker コンテナとして AWS Lambda デプロイする例です。 use utf8; use warnings; use strict; sub handle { my $payload = shift; return +{"hello" => "lambda"}; } 1; ビルド済みイメージを使う Amazon Linux 2 ベースの Perl Runtime 入りイメージをDocker Hub で公開しています。 これをベースにデプロイしたいファイルを追加し、CMD に実行したい関数名を指定するだけ。 簡単ですね。 FROMshogo82148/p5-aws-lambda:base-5.32-paws.al2COPY handler.pl /var/task/CMD [ "handler.handle" ]Docker Hub からのダウンロードに Rate Limit が適用されるようになったので、 同じイメージを Amazon ECR Public Gallery でも公開しました。 こちらを利用することも可能です。

Dec 30, 2020 - 2 minute read - Comments - github

排他制御を行う GitHub Action を作った

弊社では GitHub のレポジトリ管理に Terraform GitHub provider を使用しています。 いちいち手元で terraform plan や terraform apply を叩くのは面倒なので、 GitHub Actions を利用することを考えました。 tf ファイルと現実のリソースとの不整合を避けるために、 これらのコマンドは排他的に実行する必要があります。 例えば terraform apply を実行している最中に terraform plan を実行することはできません。 ここで問題になってくるのが GitHub Actions のジョブ並列数です。 2020-12-30 現在、GitHub Actions は同時に 20 並列まで実行可能ですが、逆に並列数を制限できないという贅沢な悩みがあります。 一応 Matrix Build の並列数を制限するオプションはありますが、 ワークフローをまたいだ並列数の制限はできません。 これを解決するために作ったのが actions-mutex です。 shogo82148/actions-mutex actions-mutex Marketplace 使い方 ただワークフローから uses を使って呼び出すだけ。 面倒なアクセスキーの設定等は必要ありません。簡単ですね。 on:push:branches:- mainjobs:build:runs-on:ubuntu-lateststeps:- uses:actions/checkout@v2- uses:shogo82148/actions-mutex@v1- run:": 排他的に実行する必要のあるタスク"仕組み actions-mutex と同様のことを実現する Action として GitHub Action Locks があります。 これの使用も考えたのですが、GitHub Action Locks はバックエンドに AWS DynamoDB を使用しています。 DynamoDB のテーブルを作成した上で AWS IAM を適切に設定する必要があり、セットアップが面倒です (まあ単に DynamoDB 食わず嫌いしているだけ、というのもあります)。