Diary of a Perpetual Student

Perpetual Student: A person who remains at university far beyond the normal period

メモ: PTCGL の通信だけを VPN 経由にした

テクノロジー Windows

Windows の標準機能で VPN に接続している、かつ Powershell スクリプトが書ける人向けです。とりあえず tunnelbear 入れようみたいな人には役に立たない情報が載っています。

インストール・アップデート時

msi ファイルが置いてある CloudFront の IP アドレスはたくさんあるので、大人しく通常通りすべての通信を VPN 経由にすると良いと思う。

一応以下に公開されているのでやれなくもないといった感じ。

docs.aws.amazon.com

プレイ時

このあたりのドメインの A レコードを引いてきて、 Add-VpnConnectionRoute に突っ込んでおく。十分条件であって必要条件ではない。

  • access.pokemon.com
  • op-core.pokemon.com
  • api.studio-prod.pokemon.com
$vpnName = "{VPN接続名}"

rasphone -h $vpnName

$domains = @(
    "access.pokemon.com"
    "op-core.pokemon.com"
    "api.studio-prod.pokemon.com"
)
foreach ($domain in $domains){
    $dnsResults = Resolve-DnsName -Name $domain -Type A | Select IPAddress
    foreach ($dnsResult in $dnsResults){
        if([string]::IsNullOrEmpty($dnsResult.IPAddress)) { continue }
        Add-VpnConnectionRoute -ConnectionName $vpnName -DestinationPrefix "$($dnsResult.IPAddress)/32"
    }
}

rasphone -d $vpnName

Powershell スクリプトは以下のエントリを参考にした。

qiita.com

lambroll を GitHub Actions で動かすときには明にバージョンを指定しよう

テクノロジー AWS Lambda GitHub Actions AgricolaDevJP

3行

  • lambroll を GitHub Actions 上で実行するには fujiwara/lambroll@v0 が使える
  • input に lambroll の version があるが必ず明に指定しよう
  • そうしないと、default 値として古い lambroll で動いてしまう
- uses: fujiwara/lambroll@v0
  with:
    version: v0.14.2 # <- ココ省略しない！

本文

前置き

前回のエントリ

blog.arthur1.dev

の最後にちらっと紹介した新生アグリコラカードデータベース API。

github.com

この API を動かすインフラとして、 AWS Lambda + Amazon API Gateway 構成を選択した。

このあたりの話はまたいつかするとして、この Lambda の deploy を GitHub Actions 上で lambroll を実行することで行っている、というのが本題だ。lambroll は、シンプルに Lambda の deploy と rollback を行えるツールである。

github.com

sfujiwara.hatenablog.com

lambroll on GitHub Actions が動かない…

lambroll を GitHub Actions で利用したいときには、 use 一発でインストールができる action fujiwara/lambroll@v0 が用意されているのでこれを使うとよい。

  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::0123456789:role/github-actions-role
          aws-region: ap-northeast-1
      - uses: fujiwara/lambroll@v0
      - name: deploy Lambda
        run: |
          lambroll --function ./function.jsonnet --region=ap-northeast-1 \
          --tfstate s3://sample-terraform-states/terraform_states.tfstate deploy

ということで、上のように GitHub Actions の workflow yaml を書いて実行してみたのだが、以下のようなエラーになってしまい deploy ができなかった。

Error: 2023/03/28 0000:00 [error] failed to read tfstate: s3://sample-terraform-states/terraform_states.tfstate: open s3://sample-terraform-states/terraform_states.tfstate: no such file or directory

lambroll には terraform の tfstate に含まれる値を読む機能がついていて、定義ファイルで利用することができる。今回は関数名や ECR のイメージ URI、実行ロールの arn を tfstate から取得するようにしていた。

{
  FunctionName: '{{ tfstate `aws_lambda_function.server.function_name` }}',
  MemorySize: 256,
  Architectures: [
    'arm64'
  ],
  Timeout: 7,
  Role: '{{ tfstate `aws_iam_role.server.arn` }}',
  PackageType: 'Image',
  Code: {
    ImageUri: '{{ tfstate `aws_lambda_function.server.image_uri` }}'
  },
}

S3 などに置いた remote state を読むこともできて、そのためにオプション --tfstate s3://sample-terraform-states/terraform_states.tfstate をつけていた。しかし、エラーメッセージを見るに、この URL で指定しているものがローカルのファイルだと誤認識されているようだ。

解決策: version を明に指定

自分の手元環境でこのコマンドを叩くと正常に deploy できていたので、GitHub Actions のための IAM ロールの設定が間違っているのかなあといろいろ試行錯誤していた。最終的に lambroll の実装を見に行くかとソースコードを読みに行ったところ、解決の手がかりを見つけた。

https://github.com/fujiwara/lambroll/blob/94d3c71cdc46645ade1a97ec29f5a0f7190ef701/action.yml#L1-L4

上記のコードを見ると、version という input があることと、そのデフォルト値が v0.10.0 であることが分かる。このエントリ執筆時の lambroll の最新版は v0.14.2 なので、デフォルト値はそれなりに古いということになる。

そして、 v0.10.0 の時点では S3 に置いた remote state を読む機能がまだ実装されていなかったので、上に示したようなエラーが出てしまった、というわけだ。version を指定できることは知っていたが、未指定の場合は最新版が使われると勝手に思いこんでいた。

ちなみに、コードを見る限りでは、仮に uses: fujiwara/lambroll@v0.14.2 としたしても、デフォルトのバージョン値に影響は与えない。

おまけ: setup-go の観察

デフォルトが最新版だと勘違いした原因は、公式で用意されている actions/setup-*** 系の action がバージョン未指定でもちゃんと最新版で動くと思いこんでいたことにある。

試しに、actions/setup-go でバージョンを指定しなかった場合、どのような仕組みで動作するのかを追ってみた。

https://github.com/actions/setup-go/blob/8dbf352f069be09d9a0b567cc1a9d16a5663fc3a/src/main.ts#L14C6-L59

このあたりのコードを読むと分かる。最新の、というよりは GitHub Actions の実行環境にプリインストールされている go のバージョンが使用されるとようだ。（ということは lambroll action の仕様を勘違いした理由がそもそも嘘だったということになる。）

試しに、version を指定せず go version してみたところ、

go version go1.18.10 linux/amd64

と返ってきた。別に最新ではないし Go 1.20 が出たのでサポートも切れているバージョンのはず。

lambroll に限らず、こういった setup 系の action ではできる限りバージョンを明に指定したほうがよさそうだ。

AgricolaDevJP という org を作りました

テクノロジー AgricolaDevJP アグリコラ

GitHub org: AgricolaDevJP

GitHub 上で AgricolaDevJP という organization を立ち上げました。今さっき作ったみたいな書きぶりをしていますが、実際に org を作ったのは 2022 年 8 月ごろです。もう半年以上経っていますね。

github.com

これまで、ボードゲーム関連、とりわけアグリコラに関連したアプリケーションをいくつも個人開発してきました。

db.buratsuki.page

app.buratsuki.page

これらのリポジトリを、これまでは自分の GitHub アカウント(@Arthur1)にぶら下げて公開していました。今後作るものに関してはこちらの organization に紐づけて公開することになります。

組織としての AgricolaDevJP の目的は以下の3つです：

  • アグリコラに関する様々なアプリケーションの開発と運用
  • 上記を手軽に開発するためのライブラリや API の開発と運用
  • 技術検証や交流

一緒に開発したい！というアグリコラプレイヤーがいたらぜひ id:arthur-1 まで一声おかけください。リポジトリは基本的に公開しているので fork して contribute できるはずですし、知り合いであれば organization にメンバーとして招待もできます。目的に合致するものでしたら、この org 下でソースコードを公開しても構いません。

自分以外の人がコードを自由にいじれる状態にリスクがあるのも承知していて、適切な権限を持ったロールを割り当てるなどの準備もきちんとしています。このあたりの管理には、 Terraform の GitHub Provider が役に立ちました。

registry.terraform.io

org を作ったきっかけ

自分のリポジトリが増えてきたので整理したい

@Arthur1 下のリポジトリは 2023 年 3 月現在、プライベートを含め 98 個あります。しょうもないリポジトリ*1も多々あるのですが、しょうもなくないものも大分多くなってきました。

自分が個人開発として丁寧につくるもののほとんどがアグリコラ関連であることから、これらを別 org に切り出すことで整理がつくかなと思ったのです。

自分だけで開発・メンテはしんどい

これまでいろんなものを作ってきたのですが、自分だけで開発・運用・保守のすべてをやるのはかなりしんどいです。学生時代ならまだしも、今はフルタイムで働いており自由に使える時間も限られています。

アグリコラ関連の開発には、どうしても人力でやらなければならない toil がつきまといます。たとえば、延々とカードのテキストを入力する、playagricola というサイト上で管理されている ID と丁寧に紐づける、といった作業があります。これらは正直やる気があれば誰でもできることなのですが、今は自分が全部やっています。ここがボトルネックになって何ヶ月もサービスをリリースできないことがままあります。

とすると、手伝ってくれる他人を招待したくなってくるのですが、個人のリポジトリに他のユーザーを admin として招待することはできません。そこで、organization による管理にしてしまおうと思ったわけです。

気持ち的には、下のエントリの事例がやや近いですね。

motemen.hatenablog.com

バトグラ技術部への憧憬

やるからには、この organization を GitHub 上の単なる organization を超えた存在にしたいと考えています。

自分が目指しているのはバトグラ技術部というコミュニティです。バトルグラウンドというオートチェスライクなゲームがあって、僕も好んでよくプレイしています。

note.com

このゲームの戦略を研究するためのトラッカーやシミュレーターなどを提供しているのがバトグラ技術部です。開発者とユーザーの距離が近く、集めたデータが素早く有効に活用されているところがとても良いなと思っています。少なくとも自分一人でやっている状態からすると雲の上のような存在です。

The State of AgricolaDevJP

この org を自分がどういう風に使っていくか、という現在とちょっと先の未来までの話をします。

砂場としての AgricolaDevJP

普段の仕事で得た知識を用いて実践する砂場として AgricolaDevJP を活用します。この 1年間で自分が新たに学んだこととして、

などがあるのですが、これら新たに身につけた技術を積極的に使うようにしています。

逆に、この org での活動で得た知識を仕事に還元することもできています。この org で試しにやってみて良い設計の決定をしたなと思うことについて、仕事のチームに持ち帰りブラッシュアップした上で ADR を書きました。このあたりの話はまたどこかでします。

持続的なサービス提供のために

バトグラ技術部を目指すためのリソースを確保するためにやるべきことは、現在自分依存になっている開発・運用・保守を自分からできる限り引き剥がすことだと思っています。

テストの用意、CI・CDの整備、Dependabot の導入などを通じて、自分が手作業でやらなければならないことを極力削減しようと試みています。運用面についても、監視を導入する、インスタンスの管理をしなくて済むように FaaS や CDN などを利用する、などの改善を進めています。

今自分が提供しているものがどのように運用されているかというと、1つの VPS 上に複数サービスがコンテナを使わずにごった煮になっているという状況です。デプロイも全手動だし、他のサービスにも関わるので PHP のメジャーバージョンを上げられないなどの弊害も発生しています。デプロイにダウンタイムが発生するので、深夜作業が避けられません。また、Chef などの構成管理もしていないしバックアップもほぼ取っていないので、このサーバが何らかの事故で吹っ飛んだら元の状態に戻すことはできないでしょう。

最低限今サービスを提供できている状態なので、自分の手から離し、持続的にサービスを提供する仕組みづくりのために一旦しゃがむという選択をします。

AgricolaDB をリニューアルします

AgricolaDevJP org 下で開発したものの最初のリリースは AgricolaDB のリニューアル版にすることを予定しています。このサービスは利用者が多いものの、前述の通り、今の仕組みでは維持が大変になってきました。

こちらのサービスを具体的にどのようにリニューアルするかについては、近日エントリを書く予定なのでお楽しみに。

最後に

「技術で農場を楽しく豊かにしたい」
アグリコラプレイヤー、募集中

*1:これとか GitHub - Arthur1/endless-lcr: 歴史の彼方 遠くて近いソラ キミとの約束 受け継がれる想い 終わらないボクらの系譜

YAPC::Kyoto 2023 は血の通った人間の匂いがした

テクノロジー 日記

なけなしの社交性を YAPC::Kyoto 2023 で全て使い果たしてしまって元気がない id:arthur-1 です。

前日祭で登壇した話はすでに書いたのですが、（こっちも読んでね）

blog.arthur1.dev

先のエントリでは触れなかった、参加者目線での YAPC::Kyoto 2023 に関する話を雑多に色々します。

幸運なことに

前提として、僕は新卒1年目だし、仕事で Perl を書く機会もほぼほぼなかったです。既存のコネクションもはてなスタッフ以外にはほぼないという状態。リアルイベントもこれまで全然なかったですよね。

最初は心細かくて仕方なかったのですが、何だかんだたくさんの方とお話できました。特に、自分はたまたま前日祭に出ていたんですが、LT マッチ に出場したことをきっかけに話しかけてくださった方がたくさんいました。LT なかったら本当に道端の石ころになってたと思います。

とはいえ、コミュニティにすでにある既存の関係がかなり強く、そこに入っていくのはやはり厳しいなという感想も持ちました。（これは学生枠などでいらした方も同じような気持ちなんじゃないかなあと思う。）

そんな僕の心情を汲み取って絡んでいただいた皆さんには本当に感謝でいっぱいです。何とかメンヘラ拗らせずに3日間過ごすことができました。ありがとうございました。

インターネット上で出会った人と物理で出会う

僕は仕事として Mackerel の OSS 製品の保守をすることがあります。ユーザーさんが出してくれた Pull Request のレビューをしたり、issue に反応したりしています。

今回のイベントで、

と物理対面してお話しすることができました。自分が関わっているサービスに関するディスカッションはオフラインでやるとやりとりにスピード感があって良かったです。

また、僕はちょっと前にこんなエントリを書いてちょっと広まってしまったのですが、

blog.arthur1.dev

このエントリに対してアンサーブログを書いていただいたにゃるら（カラクリスタ）さんともお話しできました。

the.kalaclista.com

自分がどういうトーンであの話を書いたかとか、その後どう感じていたのかとか、結局顔を見て会話しないと伝えられない精緻なニュアンスもあると思っていて、その感情を表明できた安心感は計り知れないものでした。オフ会になることを狙って行ったわけではなかったので、これもまた思わぬ収穫だったのでした。

はてなスタッフ多すぎ問題

40人弱ぐらいあの会場にいたんじゃないでしょうか。リモートワークメインでお会いできない方も多いので、社内でも軽く同窓会になってました。

企業ブースの使い方は正直勿体無かったなあと思っていて、次回出展することがあれば何か考えたいですね。他社が面白い企画をやったり工夫を凝らしたノベルティを配布したりしているのに我々は何もないですね、とボヤいたら、「人がコンテンツ」と返されたのはちょっと面白かったです。

はてなブースとぼく

現役だけでなく、ex-hatena の皆さんもたくさんいらっしゃったのが印象的でした。僕は入社して 1年も経ってないのでこれまで面識はなかったのですが、社内の git リポジトリや Wiki で見かけた人々とお話しできてよかったです。

Soudai さんへのお手紙

ex-hatena の中でも特に id:Soudai さんにお世話になったので、色々書いておきます。

僕が前日祭で LT をした後「今のうちに潰しておかなきゃ」とコメントをいただきました。誠に光栄です。僕は売られた喧嘩をもれなく買うポリシーなのですが……

https://qiita.com/advent-calendar/2017/mackerel-plugins

……。

こんな話をされてしまって、「やります」以外の返答を僕がしても全く締まらないので、はい、ご期待ください。

それはさておき、めっっっっちゃくちゃ心残りなことが一つあって、それは Soudai さんの発表の後質疑応答での出来事です。僕は質疑応答で手を挙げて以下のような質問をしました：

  • Row Level Security を、テナントという粒度に加えてユーザ単位でも適用できるか（権限の入れ子が可能か）
  • ユーザごと Row Level Security で制御するのは一般的か

これは想定通り、できるけどやらない（ユーザが何百人といるサービスを考えると管理コストがスケールしない）というお返事が返ってきました。

それを聞いた僕は「ありがとうございます」と月並みの返事をしてしまったのですが、そうじゃなかっただろと。「『要はバランス』っすね」と気の利いたレスポンスを返せなかったのがめちゃくちゃ悔しくて。

キャラが強い人が多いので、瞬発的に気の利いた発言ができる大人でないと埋もれてしまうなあという感触を持っています。この辺りの瞬発力を磨く方法は皆さんの背中を追って学んでいきたいですね。

onishi さんのキーノートで泣きそうだった

最初はまあ昔話をしているな〜程度に聞いていた（僕は基本的に昔話に興味がない）のですが、途中からやけに emotional な気分になっている自分に気づいたのです。

まず better late than never という言葉で、今自分が仕事でやっている内容が頭に浮かびました。 id:onishi さんが自称モブとして地道に一人受託チームで食い繋いで、そうやって維持し、自社サービスで拡大してきてここまで来れた会社から金を出してもらって今日自分がここにいて……、ということにも気づき始めます。 そして、これまでの出来事の中で何かの結果が違っていたら、きっかけがなかったら、こうはなっていなかったかも知れないというのが自分とシンクロしていました。僕も何かが違っていたらここにはいなかったし何ならエンジニアにはなっていなかったでしょう。そして、その一瞬一瞬の出来事には絶対に他者の存在がある。僕にとってのその1人は onishi さんだろうな。

他人事ではなく自分事だと気づいたとき初めて、このキーノートの価値を強く感じ、目に涙を浮かべたのでした。本当に全てが良かったです。

その他 (GKPT)

  • G: 前日の Helpfeel 飲みで dankogai さんとツーショットを撮る人々を眺めていた。dan さんがいちいちポーズを変えていてホスピタリティがすごかった
  • G, T: 京都で帰れなくなっても朝まで過ごせそうな場所をいくつか知れた。もうホテル取らなくて良くない？？？？
    • お風呂はルーマプラザに行けば何とかなることが知られている
  • G: YAPC と自分の母校（東工大）がかつて大いに関係があったのがわかって面白かった
  • K: 下手に電車で移動せず全部タクシー移動にしたのが楽で良かった
    • 漢気を見せたら運転手に逆にまけてもらうという謎展開もあった
  • T: 見た目でキャラ作るのもありだなあと思った。王っぽいアクセサリーとかなんかないですかね
  • P: PC 充電問題がシビアだった。省電力 PC 持っていけないならモバイルバッテリー持っていくべき
    • あんまり荷物増やしたくない問題はある……*1
  • P, T: メイクポーチ家に忘れてノーメイクでテンサゲの極みだったので持ち物チェックをする

まとめ

我々はエンジニアであり、それ以前に人間である、ということを感じさせられた YAPC::Kyoto 2023 というお祭りでした。技術カンファレンスってもっとこうお堅くてビジネスの香りがするものだと思っていました。本当にみなさんお世話になりました！！ここまでエモいと逆張りして次回はゴリゴリ技術で勝負したい気もしてきますね。

祭りの後でふわふわしていて非常に良くないので、地に足をつけるために真面目なエントリをしばらく書いていこうかなと思ってます。ではでは

*1:このエントリが良かったです 俺的！遠方カンファレンスの参加体験向上テク 2023最新版 - uzullaがブログ

YAPC::Kyoto 2023 前日祭 ネコトーストラボ杯争奪東西対抗LTマッチ に登壇しました

テクノロジー 日記

YAPC::Kyoto 2023 前日祭の一コンテンツである、ネコトーストラボ杯争奪東西対抗 LT マッチに登壇してきました。

blog.yapcjapan.org

東西対抗とあるように所属企業の所在地で東西チームに分けられており、順番に自分は西チームのトリを飾らせていただきました。

成果目標と結果

開催前に Hatena Developer Blog に意気込みを載せてもらっていました。

developer.hatenastaff.com

新卒カードをかざせるギリギリ最後の機会に、このようなイベントに参加でき大変嬉しいです。LTマッチという勝敗が決まるものに参加するわけですから、絶対に勝つぞという気持ちで挑みます！！！

絶対に勝つぞということで、自分が定めた目標はもちろんこれです：

  • 西チームが勝つ
  • 西チーム内の MVP になる

で、結果はどうだったのかというと、チームとしては勝ちましたが MVP 賞はもらえませんでした。未達。

ネタ選びには後悔していないものの、準備不足なのもあって荒削りだったな〜という反省があります。スライドをめくるテンポ感とかもっとやりようがあったはずなのだけれど、とても発表の detail にこだわっている時間はなかったです。

賞品

勝利チーム賞として、ネコトーストラボ様から可愛いネコのグラスをいただきました！ありがとうございます！！

発表内容

「Something New」がテーマだったので、「新卒エンジニアが1年間で顔を売るために取った行動100連発」というタイトルで発表させていただきました。

LT なんで資料だけ見ても全く面白くないと思いますが、せっかくなので公開しておきます。

メイキング

この LT がどのように生まれたのか。舞台裏を時系列に沿って紹介します。

前々日 11:30

  • ソフトウェアアーキテクチャに関する LT にしますと頭出し
  • アウトラインだけ共有して広報担当によるレビューを受ける → passed

前日 16:30

  • id:onk さんがたまたま東京オフィスにいたので壁打ちしてもらう
    • 真面目なネタは話としては良いけどLTとして勝ちには行けてないよね〜という危機感を共有

前日 17:00

  • 「新卒エンジニアが1年間で顔を売るために取った行動100連発」で行くことに決めた
  • Mackerel チームの Slack チャンネル で、自分の印象的な振る舞いをどんどん挙げてってくださいとお願い
    • すると続々と id:arthur-1 の悪行報告が集まっていった

    • ここまでだいたい奇行じゃん

前日 20:00

  • ネタが出揃ったのでこの方針で話がまとまりそうだなと感触を持つ
  • すでに広報レビュー通していたアウトラインの破棄を宣言
    • 許可より謝罪の精神

当日 5:30

当日 6:30

当日 7:30

  • 京都到着
  • 喫茶店を渡り歩いて居場所を確保し、スライドを作り始める

当日 10:00

  • はしごして飲み物を飲みすぎた結果お腹が痛くなる

当日 12:30

  • スライド仮完成

当日 15:10

  • スライドを映せるか機材の確認を行う
    • 他の登壇者のタイトルだけ見て真面目なネタで勝負しに来ていることを確認
  • 発表順が決まる。西チームのトリであることを確認しガッツポーズ
    • 絶対後半の方が有利でしょ

当日 15:30

  • #yapcjapan ツイートが盛り上がった結果 Twitter のシステムが不安定になる（要出典）

当日 16:30

2日後 12:30

  • 「もうこれで発表しちゃったのでごめんなさい」して広報担当にレビューしてもらう
  • あああああ〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

所感

前日祭で登壇したのをきっかけに、前日祭や YAPC 本番で色々な方に話しかけてもらって大変嬉しかったです。「技術的アウトプットに疲弊した の人ですよね？」とか、「Mackerel の OSS 製品に Pull Request 出したら id:arthur-1 にレビューしてもらいました！」とか、LT 以外の要素とも結びつけて認知していただいたのにはびっくりしました。YAPC という場で「顔を売る」ことができたので良かったです。

次は本祭でしゃべりませんか？と言われているので何か考えないといけないですね。もうすぐ新卒ラベルが剥がれてしまうのですが、新しい1年をまた走り抜けてネタ探しをしていきます。お世話になった皆様ありがとうございました。