この記事はフラーAdvent Calendar 2020の3日目の記事です。 2日目はid:gibachan03 さんで「Androidアプリエンジニアになって気づいたiOSとの違い」でした。 さて、公開当初色々して遊んだ GitHub Actions ですが、今年も引き続き遊んでました。 いくつか新しい Action を作ったものの、このブログでは紹介していなかったので、2020年作ったものを紹介したいと思います。 actions-upload-release-asset Yet Another Upload Release Asset Action 一言で表すのならば、 Yet Another actions/upload-release-asset GitHub Action です。 GitHub の Releases にファイルをアップロードする Action です。 このアクションは GitHub 公式という安心感はあるのですが、一度のステップで1個のファイルしかアップロードできません。 ソースファイル本体と、ビルド済みバイナリと・・・と色々アップロードしたいものがあったので、新しく作りました。 actions-upload-release-asset は @actions/glob の Glob Pattern に対応しているので、一つのステップで複数のファイルをアップロードすることができます。 例えば、カレントディレクトリにあるテキストファイルを全てアップロードする例は以下のようになります。 on: release: types: - created jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 # steps for building assets - run: echo "REPLACE ME!" > assets.txt - uses: shogo82148/actions-upload-release-asset@v1 with: upload_url: ${{ github.

なんだか今日はもうコードを書く気がしないので、最近思っていることをつらつらと・・・ タイトルの通り、最近 AWS SDK for Go v2 の行く末がちょっと気になっています。 あんまり話題になっているのを観測できていないので、少し現状を書いてみます。 背景 最近あったビッグイベントが v0.25.0 のリリースです。 Client Updates in the Preview Version of the AWS SDK for Go V2 パッケージの構成が見直され、APIの呼び出し方法も変わりました。 まあ、プレビュー版なのでよくあること・・・なんですが、ちょっと変更点が多すぎて追いきれない。 v0.25.0 移行で入った変更の数々 ちょっと一例を見てみましょう。 設定の読み込み Before: v0.25.0 より前は external パッケージを使って設定を読み込んでいました。 import ( "github.com/aws/aws-sdk-go-v2/aws/external" ) func loadConfig() (aws.Config, error) { return external.LoadDefaultAWSConfig() } After: これが config パッケージに変更になりました。 import ( "github.com/aws/aws-sdk-go-v2/config" ) func loadConfig() (aws.Config, error) { return config.LoadDefaultConfig() } API の呼び出し Before: Requestオブジェクトを作って、そのSendメソッドを呼ぶ形式でした。 s3svc := s3.

リリース当初は git push など GitHub 上のイベントしかトリガーにできなかった GitHub Actionsですが、 workflow_dispatch イベント の登場により手動実行ができるようになりました。 社内でもこの機能を利用してワークフローの手動実行をしていたのですが、人間とは欲深いもので「毎回ワークフローを選択してポチポチするのだるい」という声があがってきました。 そういうわけで、Pull Request のコメントをトリガーにしてワークフローを実行する簡単なボットを作ってみました。 方針 workflow_dispatch と issue_comment をトリガーにしたワークフローを作ればいいだけの気もしますが、 以下のような理由からワークフローからワークフローを呼び出す形にしました。 workflow_dispatch を使った既存のワークフローがあるので、それを流用したい トリガーが複数あると、イベントの種類に応じてペイロードの形式が異なるので、地味に処理が大変 issue_comment は全部のコメントに反応するので、本当に見たいログが埋もれてしまう コメントを投稿した Pull Request のHEADでワークフローを実行して欲しい issue_comment はイベントの発生元として、デフォルトブランチのHEADが渡ってきます イベントのペイロードには、プルリクエストへのリンクが入っているだけで、HEADの情報はわからない 実装 jfurudo1 がサードパーティのアクションを使ってゴニョゴニョやっていたものの、 あんまりうまく行ってなさそうだったので、bash script でエイヤッと書き直しました。 「build」 とコメントすると、.github/workflows/build.yml のワークフローを実行するサンプルです。 name: comment hook on: issue_comment: types: [created] jobs: distribute: runs-on: ubuntu-latest steps: - name: dispatch workflow run: | # イベントに関する詳細情報を取ってくる PAYLOAD=$(cat "$GITHUB_EVENT_PATH") NUMBER=$(echo "$PAYLOAD" | jq -c '.issue.number') # Issue と Pull Request のコメントが混ざってくるので、Issueは無視する if [[ "$(echo "$PAYLOAD" | jq -c '.

Amazon Linux 2 への移行が進む AWS Lambda ですが、 ついに Custom Runtime にも Amazon Linux 2 がやってきました。 AWS Lambda now supports custom runtimes on Amazon Linux 2 同時に provided.al2 の Docker Image も公開されたので、 それを利用して Amazon Linux 2 対応の Perl Runtime Layer を作成しました。 AWS::Lambda ビルド済み公開 Perl Runtime Layer リージョン毎のArn一覧はこちら Perl 5.32 arn:aws:lambda:af-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-east-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-northeast-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-northeast-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-southeast-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-southeast-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ca-central-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-central-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-west-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-west-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-west-3:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:me-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:sa-east-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-east-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-east-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-west-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-west-2:445285296882:layer:perl-5-32-runtime-al2:1 --runtime provided.al2 と合わせてご利用ください。

僕が管理しているサービスでは、ALB が発行する Trace ID を調査時の手がかりとして使えるようログに出力しています。 これのおかげで、Nginx, アプリケーション, その他AWSのマネージドサービス, etc. といった異なるコンポーネントであっても、関連するログを抽出ができ、 障害発生時の役に立っています。 しかし、肝心の抽出作業がマネージドコンソールぽちぽちなため、完全に職人芸になっているというのが現状でした。 解決のための良いツールがないかな、と目をつけたのが CloudWatch ServiceLens です。 CloudWatch メトリックとログ、AWS X-Ray からのトレースを結び付けて、直感なインターフェースで分析できるというもの。 Amazon CloudWatch ServiceLens の発表 AWS X-Ray のトレース結果を送るのは、以前開発した Yet Another AWS X-Ray SDK for Go でできます。 CloudWatch Logs への出力方法は色々ありますが、僕は自作の cloudwatch-logs-agent-lite を使っています。 材料はそろった、さあ、ServiceLens で分析だ！と行きたいところですが、 ただ単にこれらの情報を送りつけるだけでは、得られる情報は X-Ray 単体、CloudWatch Logs 単体で使ったときと大差ありません。 X-Ray のトレース結果とログの関連付けが行われていないので、結局 Trace ID を使って CloudWatch Logs を検索する必要が出てきてしまいます。 ドキュメントを見る限り、2020-07-06現在 AWS X-Ray SDK for Java だけがログ関連付け機能に対応しているようです。 JavaにできてGoにできないわけがないだろう・・・ということで移植してきました。 使い方 aws-xray-yasdk-go の v1.1.1 移行で対応しているので、そのバージョンを落としてきます。 go get github.

@furusax が書いてくれた GitHub Action からの Slack 通知機能について以下のようにコメントしたところ、 対策案を考えてくれました。 そういえばこれって Pull Request Title Injection できないですかね？ まあ、タイトル書くの社員なのでいいんですが。 対策してみました #はてなブログ Pull Request Title Injection とその対策 - なまえは まだ ないhttps://t.co/hIkMykFUr8 — ふるさっくす (@furusax) March 31, 2020 Pull Request Title Injection とその対策 なるほど、こう来ましたか。しかし、まだまだ甘いですね・・・。 2021-08-19 追記 ドッグさん が便利なツールを作ってくれました。 rhysd/actionlint actionlint v1.4 → v1.6 で実装した新機能の紹介 GitHub Actions のワークフローファイルの静的チェッカーです。 チェック項目にこの記事で紹介したような脆弱性検知も含まれているのでおすすめです！ Pull Request Title Injection について まずはこの記事に出てくる「Pull Request Title Injection」についておさらいです。 以下のような Slack への通知を行う GitHub Actions があります。 github.event.pull_request.title はプルリクエストを送った本人が自由に設定できるので、 ここにうまいこと細工をすれば Slack への投稿内容を自由に改変できてしまうのでは？という問いかけでした。

AWS X-Ray Go SDK の地雷処理をしている話 で投げたSQLのプルリクエスト も無事マージしてもらい、 その後もちょくちょくプルリクエストを投げて地雷処理をしていたんですが、我慢できずにやってしまいました・・・。 Yet Another AWS X-Ray SDK for Go そもそも AWS X-Ray ってなんだ、という方は以下のリンクから @fujiwara さんの記事へ飛べるのでどうぞ。 AWS Lambda Perl Runtime で AWS X-Ray を使えるようになりました 使い方 だいたいオフィシャルSDKと一緒です。 ただし、パッケージ分割をしたので、呼び出す関数名等はちょっと変わってます。 他にも微妙に挙動が違う箇所があります。 環境変数の設定 AWS_XRAY_DAEMON_ADDRESS, AWS_XRAY_CONTEXT_MISSING 等の環境変数の設定項目は本家と合わせました。 ただし、以下の点が本家とは異なります。 コード内の設定が優先されます。 環境変数はコード内で明示的に設定が行われなかった場合のフォールバックです。 AWS_XRAY_CONTEXT_MISSING のデフォルト値は LOG_ERROR です。 セグメントの作り方 オフィシャルSDKは seg.Close(err) のようにセグメントを閉じるときにエラーを渡します。 Go には defer という便利な機能があるので、セグメントを閉じるときもこれを使いたいところです。 だたエラーを正しく受け取るには、以下のように戻り値に名前をつけて、defer 部分を無名関数の呼び出しにする必要があります。 // オフィシャルSDKの場合 import "github.com/aws/aws-xray-sdk-go/xray" func DoSomethingWithSubsegment(ctx context.Context) (err error) { ctx, seg := xray.BeginSubsegment(ctx, "service-name") defer func() { seg.

AWS Lambda Perl Runtime で AWS X-Ray を使えるようになりました で紹介した AWSの分散アプリケーションの分析サービス AWS X-Ray。 Perl から使えるようにしたももの、自分自身は最近 Perl をあまり使っていないことに気がついた！！ので、AWSが提供しているGo実装である aws/aws-xray-sdk-goに 手を出してみることにしました。 結果、X-Rayのサービスマップやトーレスが見れるようになって便利！・・・にはなったんですが、そこまでの道のりが長かった。 「 @fujiwara さんのYAPC::Tokyo 2019での発表 から1年近く経ってるしそろそろ安定してきているでしょ！」と 軽い気持ちで始めたのが良くない。 色々と地雷(？)を踏んだので、記録として残しておきます。 依存ライブラリのcontext対応が地味に辛い X-Ray で実行をトレースするには、「今実行している関数がどこから呼ばれたのか？」という情報をうまいこと伝える必要があります。 Perlで使われているような黒魔術はGoでは使えないので、 context.Context を地道に引数に渡していくことになります。 まあ、こんなこともあろうかと、context.Context にはバッチリ対応してあるからサクッと行けるでしょ！ と思ってたんですが、現実はそうは甘くなかった。 X-Rayを入れようとしたプロジェクトではWebフレームワークとしてgoadesign/goaを使っています。 GoaのHTTPハンドラーには context.Context が渡ってくるので油断していたのですが、 contextの親をたどっていくと行き着く先は context.Background() (HTTPハンドラーなので request.Context() であってほしい)。 なんとなく context.Context 対応詐欺にあった気分です。 Goaは現在 v2, v3 の開発がメインで現在使っているのは v1 です。 v1からv3へのアップグレードには大幅な書き換えが必要なこと、アップグレードしたとしても直っている保証がないこと、 最近 Goa v1 のリリースが滞りがちなこと、などなどの理由から結局フォークしてくることにしました。 shogo82148/goa-v1 AWS X-Ray Go SDK 自体の問題ではないのですが、 Contextってタイムアウトをうまく処理するための仕組みなので、実装漏れがちですよね。 皆さん実装するときやライブラリの選定には気をつけましょう。 SQLクエリを実行する関数のシグネチャーが微妙に違う これに関しては @acidlemon 先生の kamakura.

TL;DR 今GitHubにアップロードした内容は1000年残る！ デッドラインは 2020年2月3日(月) 午前7時(日本時間) Yahoo!ジオシティーズのデータがダウンロードできるのは2020年3月31日まで つまりYahoo!ジオシティーズから移行するなら、今！ GitHubが一番！ Yahoo!ジオシティーズは終了しました Yahoo!ジオシティーズ 公開停止からはや10ヶ月。 ちょっと古いリンクをたどると「Yahoo!ジオシティーズは終了しました」というページを目にすることが多くなりました。 Yahoo!ジオシティーズは終了しました 2019年3月31日をもちましてYahoo!ジオシティーズのサービス提供を終了いたしました。長らくご愛顧いただき誠にありがとうございました。 ホームページをお持ちのお客様につきましては、2020年3月31日までFTPによるファイルダウンロードのみご利用可能となっております。ホームページやドメインの移行方法などはサービス終了のお知らせをご確認ください。 https://info-geocities.yahoo.co.jp/ それ見てこんなツイートをしたのですが、なぜ GitHub への移行がいいのか知らない人が多いようなのでちょっと説明しますね。 みんな！FTP経由ならまだジオシティーズからホームページのダウンロードはできる！！今のうちにGitHubへ上げてその黒歴史を1000年後まで残すんだ！！！ — Ichinose Shogo (@shogo82148) January 31, 2020 GitHub Arctic Code Vault なぜ今 GitHub なのかというと、 GitHub Universe 2019 で GitHub Archive Programというプログラムが発表されたからです。 今から1,000年後にソフトウェアはどのようになっているのか、また人類はどうなっているのか、推測することしかできません。しかし、今日の時点で最も重要なビルディングブロックを、確実に明日に残せるようにすることは可能です。私たちの世界は、オープンソースソフトウェアで動いています。この文明の隠れた基盤であり、全人類の共有財産です。GitHub Archive Programの使命は、次世代のためにオープンソースソフトウェアを保護することです。 GitHubは、スタンフォード大学図書館、Long Now Foundation、 Internet Archive、Software Heritage Foundation、Piql、Microsoft Research、オックスフォード大学ボドリアン図書館などの機関や団体と連携し、世界のオープンソースコードを保護していきます。この貴重な知識を保護する方法として、あらゆるデータ形式でさまざまな場所に、継続的に複数のコピーを保存していきます。保存場所には、GitHub Arctic Code Vaultと呼ばれる、少なくとも1,000年は存続する非常に長期的なアーカイブも含まれます。 https://github.blog/jp/2019-11-14-universe-day-one/ このプログラムで最長の保存場所である GitHub Arctic Code Vault は、北極圏に広がる永久凍土の深さ250mに建設されたアーカイブ施設「Arctic World Archive」。 2020年2月2日 時点でのアクティブな公開リポジトリ※のスナップショットが、QRコードとしてエンコードされフィルムに印刷されたのち、この場所に保管されます。 Arctic World Archive は地政学的に地球上でもっとも安定した場所であり、1000年の長期保存にも耐えるとのこと。

この記事はフラーAdvent Calendar 2019の6日目の記事です。 5日目は@shogo82148 さんで「GitHub Goveralls Action を公開しました」でした。 さて、最近 GitHub Actions を作るのにハマっているので、今日も GitHub Actions の紹介です。 GitHub Action for CloudFormation Linter with reviewdog shogo82148/actions-cfn-lint Amazon CloudFormation Infrastructure as Code の盛り上がりも一段落し、今では当たり前のように使っている人も多いと思います。 フラー共創スタジオはAWSがメインなので、CloudFormationをメインに使っています。 色々とクセは強いですが、少なくともtfstateが行方不明になったりはしないので、まあまあ仲良くやっています。 CloudFormation Linter テンプレートを書いている上で地味にややこしいのが、プロパティーの名前や型の統一感が微妙にない、ということです。 例を挙げると、AWS::ApplicationAutoScaling::ScalableTarget の MaxCapacity は整数型です。 これはまあ、納得できますね。 ところが AWS::AutoScaling::AutoScalingGroup の MaxSize は 文字列型 なんです。説明文には「Auto Scaling グループの Amazon EC2 インスタンスの最大数」とあるのに！ オートスケールという似たような機能を持っていて、どちらもスケーリンググループの最大数を表しているの、名前も違えば型が全く違う。 この手のミスは aws cli に付属している テンプレートの validation 機能では見つけられす、実際に反映してみるしかありません。 すぐに失敗してくれればいいんですが、失敗するまでにも十数分かかったりしてかなり面倒です。 そこでおすすめなのが CloudFormation Linter。 この手の名前のミスや型のミスを指摘してくれるコマンドラインツールです。 各種エディタ用の拡張もあり、VSCodeでも使える ので、ぼくはいつもこれを使っています。 CloudFormation Linter については Classmethod さんの紹介記事もどうぞ。