2022年12月20日
3年目
このシリーズも、もう3年目になります。
例によって冒頭の画像はwakatimeによる2021年1月1日から12月16日までのプログラミング言語使用率です。3位はYAML、4位はOtherとのことです。
立場
フリーランスで、主にRailsやAWSを使用しているサービスの運用、開発に関わっています。いくつもの会社を見てきた訳ではなく、数社に深く関わっている都合上、視野が狭いかもしれません。(昨年同様)
今年は仕事の成果として公表できるものはありませんでした。
利用した技術一覧
昨年とは違い、純粋に使用した記憶があるもの、印象に残っているものをリストアップしています。
Language
Ruby
TypeScript
Python
Go
C
Framework
Middleware/Infrastructure
Docker
PostgreSQL
MySQL
AWS (略)
GCP (略)
Terraform
Kubernetes
CI
Monitoring
Sentry
Prometheus
Grafana
OS
Editor (wakatimeによる使用時間合計順)
VS Code
IntelliJ Idea系
Vim
概念的なもの
その他
昨年と比較すると少し減りましたかね。
Ruby/Rails
今年もRubyとRailsで仕事をし、収入を得ることができました。やっぱりなんだかんだRailsはいいですね。今年は新規サービスの立ち上げに関わったのですが、良くも悪くも自分が一番手が早く動くのがRubyでありRailsなので、最速で顧客に価値を提供するにはこの選択になってしまいます。このポジションの道具としてNext.jsを加えられるともっと入れる現場が増えたりするんじゃないかとは思いますが、とりあえず来年もRubyとRailsで頑張っていけそうです。
Next.js
今年2番目に書いた言語がTypeScriptとなっていますが、実質Next.jsでした。これに関してはKaigi on Rails 2022の運営記として書いたブログ にあるように、Firebaseを活用したWepアプリを作ったのがそれです。
まだまだこの分野においては経験値が不足しているのを実感しており、具体的にはRDBとの通信やかっちりとしたバリデーションが必要な性質のものは書いたことがありません。ViewをReactで書き、API部分をRailsで書く、という構成から自分が抜け出せていないのを感じています。サーバーサイドもJavaScriptで書くという技術投資にプライベートの時間を割くのは今年はできませんでしたし、来年も厳しそうです。
来年頑張りたいこと
Ruby/QUIC
言わずもがな、まさに現時点で2022年のRuby Association Grantに採択されたということもあって、QUICのRuby実装を進めているところです。今はただaioquicの移植をしている段階であり、それでも予想はできていましたが大変です。がんばります。
OpenSSL
「OpenSSLをがんばる」とは何だという話ですが、QUICをやっていくと必然的にTLSをやっていくことになり、そして必然的にOpenSSLのAPIに触れる必要が出てきます。ところがもちろん、OpenSSLの内部APIに関する初心者向けのドキュメントなんてあるはずがないので苦労するわけです。
暗号技術の専門家を目指して頑張る、ということではなく、OpenSSLの内部APIがどうなっているのか、どう使っていくのが正しいのか、生のCで書かれた処理フローをRubyのOpenSSL gemを使う形式に書き下すにはどうするか、公式ドキュメントの読み方などの方向感覚を付ける、などというのを頑張りたいです。というかできないと厳しい……
C/Rust/Zig
現在、QUICの実装に関連してC拡張を含むruby gemを作成しなければいけない状況にあります。なのでC言語を書く必要があるのですが、現在は(もし使用できるのであれば)C言語の代替としてRustやZigを採用したほうがより良いでしょう。
ひとまず既存の資料も多いことから一旦C言語で実装するつもりでいますが、ゆくゆくはRustもしくはZigによる書き換えをしたいと目論んでおり、そのためにもRustとZigはキャッチアップ、比較検討したいところです。そして、それ以前にC言語を書くのが学生以来なので、C言語の基礎的な部分も学び直しです。
Kaigi on Rails
今年こそはProposalを出したい……！Grantの最終報告が終われば時間ができるはずなのでそのタイミングで概念実装を、と言いたいところですがRubyKaigiもありますね。どうなるんでしょう。
そしてそれとは別にin-personとonlineでのハイブリッド開催となっており、スタッフ業としても準備するもの、やることが結構あるはずで、しかしまだ全体像が見えていない状況にあります。直前になってバタバタしないように気を張っておきたいところです。
English
これは昨年やると言ったもののあまりできていないことです。まずできることとして、Grantのreportは英語で書いてみようか……と考えてはいますが、果たして。
あと海外カンファレンスにProposalを出せたらいいなとか考えていますが、果たして。
2022年11月29日
私がこれを書く動機
私はKaigi on Railsのオーガナイザーのひとりです。Kaigi on Rails 2023は物理会場にて開催されることが公開されました。そうなるともちろん、会場でのインターネットについてはどうなる、どうする、という問題が出てきます。それに備えて、先輩イベントであるRubyKaigiを参考にしようというわけで、自分の理解のために書くことにしました。
おことわり
私はRubyKaigi 2022のネットワークをお手伝いしましたが、ケーブルの巻き直し、APの設営、撤収時の諸々を手伝ったのみです。よってこれから言及する内容については、一般参加者に毛が生えた程度の事前知識しかありません。
またこれから読み解くコードにおいて、コメントする内容の正確性は一切ないものと思って読んでください。
RubyKaigiのネットワークについて
RubyKaigiのネットワークにおけるL3(OSI参照モデルで言うネットワーク層以上)より上の構成(多分)については、このリポジトリで公開されています。
今回は、2022年の会場ネットワークの構築が始まったあたりからのcommitを順を追う形で読み解いていきます。
e419d86 destroy itamae/ and start from scratch
今回のネットワークの準備はここから開始したと見られます。これ以前にもcommitsはあるのですが、それらは2019年以前のものをimportしたもののようなので、今年には関係ないとして無視します。
実際、このcommitでもitamaeのrecipeを削除してscratchからやりなおす、という意図を感じられます。
073c8e71 onpremises subnet
subnetを3つ、route_tableをひとつ定義しています
AWS Direct Connect ゲートウェイを定義しています。AWS Direct Connectとは……
AWS Direct Connect は、お客様の内部ネットワークを AWS Direct Connect ロケーションに、標準のイーサネット光ファイバケーブルを介して接続するサービスです。
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/Welcome.html
とのことです。(今知った)
3c07751 rubykaigi.net route53 zones
Route 53に rubykaigi.net のZoneを定義しています。ネットワーク関係の色々は *.rubykaigi.net で提供されました。
6e1f798da setup bastion instance
踏み台インスタンスを定義しています。関連するIAM roleであったり、SSH loginできるユーザーの公開鍵の設定などもあります。
b29183d awsroute53 zone.ptr-10 => 10.in-addr.arpa.
DNSの逆引きを設定しているんだと思います。この記載で 10.0.0.0 になるってこと……？
https://manual.iij.jp/dpf/help/19004700.html
c3a8f29c1 mv terraform/ => tf/core/ in order to have multiple tfstates
これは単純にTerraformのdirectory構成の変更ですね。
4dd4bae2 create hosts DNS records with terraform
様々な機器のDatacenter、Network、CIDR、IP等を定義したhosts.txtを作成(というより更新)し、その内容から aws_route53_record を作成するRuby scriptを経由してRoute 53にTerraformからrecordを登録するようにしています。まあこれは手では書いていられないですね……最終的なhosts.tfは1400行弱になっています。
8fcc2cf remove route53/ (roadworker)
Roadworkerを削除しています。RoadworkerはRubyによるRoute 53をDSLによって管理できるgemです。Terraformによる管理に乗り換えたから、ということなんでしょう。
01b95c6 enable nat gateway
NAT Gatewayが有効になりました。
687e37b initialize k8s cluster
EKSによるKubernetes clusterが爆誕しました。というか、Cookpad org以下にterraform moduleが公開されているんですね。
https://github.com/cookpad/terraform-aws-eks
注目すべきは、このクラスタは全部ARM instanceで稼動するような設定になっているところです。
a8b808f6 aws_vpn_gateway_route_propagation (import)
VPN間でのrouteのpropagationを設定しています。
dd6967e provision node groups
K8s clusterに属するnodeの設定です。
14e22a3 deploy node-termination-handler
https://github.com/aws/aws-node-termination-handler をHelm経由でdeployしています。こんなのがあるんですね。
ddb5c69 deploy aws-load-balancer-controller
AWS Load Balancer Controllerをclusterにdeployしています。
AWS Load Balancer Controller アドオンのインストール - Amazon EKS
ff3f013 addcreate shared ALB (ops-lb.rubykaigi.net)
証明書とALBを作成して *.rubykaigi.net ないくつかのhostを定義しています。こんなの生えてたのか。
144b3b6 deploy dex at idp.rubykaigi.net
dexをdeployしています。dexというのは https://dexidp.io/ です。 これで何をしたいかというと、 *.rubykaigi.net でhostされているいくつかのresources(例えば grafana.rubykaigi.net )へのアクセス権限を絞るためです。今回はGitHubの特定teamに所属しているメンバーに対しての許可を与えるような設定が書かれています。
また主にこのcommit以降からだと思いますが、K8sで使用するYAMLをJsonnetから生成するようになっています。
f5d628c test.rubykaigi.net with authenticate_oidc action through dex
で、そのテスト用のendpointを作成しています。ちゃんとAuthrorizeされていれば画像が見れるはず、というやつ。
wgbridgerを導入しています。wgbridgerというのは、
build L2 bridge using Wireguard to bring NGN to behind IPv4 NAPT only environment…
というもの(？) これはあれかな、準備作業中に見せてくれた、どこでもNGNに繋がる便利Raspberry Piの実体かな？
43c0b1a amc: to gain access to AWS through dexidp
dexをOIDC準拠IdPとして使用した認証を利用し、AWS Management Consoleへのアクセス権限を特定のIAM Roleによって行えるような機構、AMCを用意しています。つまりどういうことかというと、あるGitHub teamに所属している場合、その認証情報を用いてAWSのConsoleに入れる仕組みです。 tf/amc/src/app.rb がキモだと思うんですが、難しいよぉ……
5d66255 amc: enhance readme
AMCのREADMEに追記が行われています。
1db6e03 amc(ca_thumbprint): validate certificate chain
AMCに関連する処理のなかで、curlによる証明書チェーンが正当かどうかの検証を追加しています。
dc4ec4d build kea Docker image
ここからKeaのための準備が始まります。Keaが何者かというと、DHCP serverです。このcommitでは、Docker imageのbuildやKeaを起動するためのscriptなどの準備をしています。
https://www.isc.org/kea/
cd4d420 create kea backend rds
これはKeaのためのAuroraを準備しています。
bf917ef gen-k8s: use rsync instead of rm -rf & cp
JsonnetをYAMLにするscript内部で、生成したファイルの扱いがちょっと変更されています。rsyncにしたのは更新日時とかそのあたりの都合？
857d625 deploy kea-dhcp4
Keaが運用され始めました。
f64e1a1 dhcp: add health check server for NLB
Keaに対するhealthcheck用のendpointを用意しています、Rustで。Healthcheckそうやってやるんだ……なるほど……？
36c0f97 NocAdmin: allow elasticloadbalancing:*
NocAdmin roleに対してロードバランサーへの権限を解放しています。
04171ac dhcp: roll c866cff
Kea関連のdeploymentで参照しているcommit hashを更新しています。
7a7a1c3 nocadmin: grant rds:*
NocAdmin roleに対してRDSへの権限を解放しています。
cc0d6cb employ permission boundary on NocAdminBase policy
これはちょっとわからない……NocAdminBaseとNocAdminに権限を分離して、権限昇格を防いでいるんだと思いますが多分。
権限の昇格を防ぎ、アクセス許可の境界で IAM ユーザー範囲を限定する
🍝
4756245 NocAdmin: grant more iam permissions
NocAdminに対して許可するiamへの権限をいっぱい追加しています。
2c09e19 tf/k8s: arm64 support has been merged but not yet released
687e37bで導入されたterraform moduleをfork先のものからfork元のものを使うよう修正しています。ARM対応がmergeされたのがこのタイミングだったのかな。
Terraformのexternal data sourceとして、Jsonnetを指定してJSONを吐くときに使うためのRuby scriptを定義しています。
9743d8f tf/core: ALB rules for prometheus/alertmanager
このあたりからPrometheusの設定が始まります。ここではALBのための設定を作成しています。これらのendpointもdexを経由して認証されるようにしていますね。
6cf6189 tf/k8s-prom: install kube-prometheus-stack
Helm経由でPrometheusをK8s clusterにdeployしています。
9020ef2 tf/k8s-prom: Install prometheus-blackbox-exporter chart
blackbox exporter を用意しています。ICMP (ping)でどこかを監視する用かな。
6e086c7 k8s/prom: Probes
8.8.8.8 に対して60秒ごとにICMPを投げるように設定しています。これはインターネットへの疎通確認かな？
287eba2 tf/k8s-prom: Set retention to 30 days
Prometheusのdata retensionを1分から30日に変更しています。
f86fb99 tf/k8s: Export cluster config
clusterへの設定を他のtfから参照できるようにoutputしています。
7c1f56c tf/k8s-prom: Import cluster config via terraform_remote_state
ハードコードしていた設定値を、先ほどoutputしたclusterの設定を用いた形に書き換えています。
025d95 update hosts.txt
hosts.txtが更新されました
f52e1bc tf/k8s: snmp-exporter
snmp-exporterを設定しています。SNMPはSimple Network Management Protocolのこと。CiscoのWireless LAN ControllerやNECのIX Routerの監視に用いていたのかな。
22b1104 k8s/prom: Example config for blackbox/snmp probes
先のcommitで作成した設定値をprometheus側に反映されるようにK8sのmanifestを設定している、という理解でいいのかな
743b14b tf/k8s-prom: Grafana
Grafanaです。
218ec5 k8s/dhcp: Monitor kea4
Keaの監視もPrometheusで行うようになりました
99cb633 wgbridger: increase wg0 mtu
wgbridgerのためにMTU値を上げています
034fe8f wlc.rubykaigi.net
Wireless LAN Controllerにアクセスできるようになりました。
42df8b0 k8s-prom: Slack alert
PrometheusからのアラートがSlackに送られるようにしています。
c89d220 jsonnetfmt -i */ .jsonnet
Jsonnetに対してformatterをかけています。
dd79016 prom: scrape-interval 20s
Prometheusがmetricsをscrapeする間隔を60秒から20秒に変更しています。
d397d5a tf/k8s: Export cluser OIDC config
clusterでのOIDC configを別tfから参照できるようにexportしています
0344245 nocadmin: dynamodb:*
NocAdmin roleに対してDynamoDBに関する権限を解放しています。なんかで使うんでしょう。
68781de tf: state lock
なるほど、State lockでDynamoDBを使うためだったんですね。
Backend Type: s3 | Terraform | HashiCorp Developer
3fa3622 noadmin: Allow iam:UpdateAssumeRolePolicy
NocAdmin roleに対して iam:UpdateAssumeRolePolicy を許可するよう変更しています。
a5268cf prom: cloudwatch_exporter
cloudwatch_exporterを有効にしています。AWSのresourceもPrometheusでモニタリングするためでしょうね
d36e815 update hosts.txt
hosts.txtを更新しています。IPv6の指定が増えてますね。
18af871 update hosts.txt
さらにhosts.txtの更新。もりっとhostが追加されています。
3902ba6 hosts_to_tf: fix error that single name allowed only single rrtype
hosts.txtからtfに変換するscriptを修正しています。IPv6の取り扱いとかに修正が入ってますね。
fd15430 update hosts.txt (typo)
typo
e21aec7 script to generate tunnel iface configurations…
これは……なんだろう、多分何かの機器用の設定を生成するためのscript。NECのルーターだと思うけど。
マニュアル : UNIVERGE IXシリーズ | NEC
6febb97 nocadmin: Allow s3:* on rk-syslog bucket
Syslogを置くためのS3 bucketへの権限をNocAdmin roleに付けています
335669f tf/syslog: init
Syslog関連のterraformのための場所を作っています。
8440359 tf/syslog: ECR repo for custom fluentd image
Syslogのためのfluentdを置くECR repositopryを定義しています
dbc46d8 docker: custom fluentd image
Syslogのためのfluentd containerを作成しています。GitHub Actionsでdocker buildをしていますね。
9eef1d4 Use https transport for cnw submodule to allow unauthenticated checkout
git submoduleのrepository URLをssh形式からhttps形式に変更しています。鍵がない環境でcloneできないから、でしたっけ。たぶんGitHub Actionsで不都合になったのか……？
d89649d docker/syslog: fluend plugins
fluentd pluginを作成しています。これはまずhealthcheckだけやってる感じ？
c690a8f tf/core: Allow GHA to push fluentd images
GitHub ActionsからECRにpushできるような権限を付与しています
71ae2b9 tf/syslog: k8s service account for fluentd
Syslog用のIAM role、K8sのservice accountを作成しています。EKSでIAM roleとの連携ってこうやってやるんだ。
2ab09ff k8s/syslog: deploy fluentd
fluentdの設定、k8sのdeployment諸々が作成されています。これでEKS clusterにfluentd containerが稼動し始めたのかな。
eb9d2bd tf/syslog: SGs
SyslogのためのSecurity groupを作成しています。fluentdに向かう通信を許可しているはず。
06cafcf k8s/syslog: use monitor_agent plugin for healthcheck
fluentdのhealthcheckのために、pluginを作ってやっていたものからmonitor_agentを使う方式に変更しています。
https://docs.fluentd.org/input/monitor_agent
850181c workflow: correct path
GitHub Actions内で参照していたpathの修正です
8c44f4d k8s/syslog: Inject fluentd hostname in records and object keys
S3に置くlog fileにhostnameを付与するようにしています
c72628c k8s/syslog: Use default chunk_limit_size as timekey is enough short
fluentdが終了するときにbuffer(？)をflushするようにしています。これないと書き出し切らずに終了してしまう？
7160fc0 k8s/syslog: No separete chunks by tag
tagでchunkが分離されてしまうのを防いでいる？
73d7542 bastion: ignore ami id change
terraformでbastion instanceに対してはAMIの変更を無視するようにしています。
51869fc configure private NAT gateway for onpremises
use static NAT on onpremises router devices so they don’t need to handle dynamic NAPT table and allow redundancy
「オンプレミスのルーターデバイスで静的NATを使用することにより、動的NAPTテーブルを処理する必要がなく、冗長性を確保できる。」 あ～はいはいなるほど完全に理解した
b0c0737 tf/core: Allog GHA to push unbound image
unboundがアップを始めている
dafaaeb tf/dns-cache: ECR repo and SG
unboundをCache DNS serverとして運用するみたいで、そのためのECRとsecurity groupを定義しています。
9d4ead6 docker/unbound: unbound with modified unbound_exporter
独自のunbound exporterによる監視を有効にしたunboundのcontainerをbuildしています。Jsonnet大活躍。
ac08623 tf/dns-cache: typo
フィックスタイポ
bbd2f10 k8s/dns-cache: unbound
unboundの設定です。
68c205f k8s/dns-cache: forward reverse lookup zones and rubykaigi.{net,org} to VPC resolver
特定の逆引きに対しては特定のIPに送るようにしてい……る？このIPがVPC resolverを指している？
c15afdf k8s/dns-cache: Update image
deployされるunboundを更新しています。
831f13 k8s/dns-cache: fixup 68c205f
68c205fで設定したlocal-zoneに対してnodefaultを付けています。unboundなにもわからない。
nodefault AS112ゾーン（※）のデフォルトの設定をオフにする
※ AS112ゾーンはプライベートアドレスやリンクローカルアドレスの逆引きのゾーンのことです。Unboundではデフォルトでこのゾーンに対する問い合わせにはNXDOMAIN（情報なし）を返します。
第4回 Unboundサーバ運用Tips | gihyo.jp
NXDOMAIN を返さないようにした、ということなんでしょうか。
unboundの設定を変更して性能を調整しています。
48cead4 k8s/dns-cache: setuid
unboundが unbound userで動作するようにしています。
83645b1 update hosts.txt, generate ptr for public IPs
グオオオ
477f8a1 add kea4 config for all venue subnets
venue下のsubnetに対してKaeで払い出すIP rangeを指定している……でいいのか？
ceca0e4 dns-cache: Expose TCP port
unbound containerに対してTCPでも通信できるようにしています。heathcheckとかでも使うから。
ae37486 Enable pod-readiness-gate-inject
https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/deploy/pod_readiness_gate/
なる、ほど、ね……？
😜
ae96cb9 tf/dns-cache: Restrict access to healthcheck port from NLB subnets
NLBのsubnetからunboundへのhealthcheck accessをできないようにしています。metricも同じportで提供するから、というのはmetricに影響が出る？
9d02422 Use loop over map value
これはterraformのfor loopの設定。
a4e3dd3 ./gen-workflows.rb
./gen-workflows.rbを実行した結果をcommitしたんだと思います。
2c84d6c tf/k8s: node_onpremises min_size=2
Availability Zoneごとに配置されるよう、nodeのmin_sizeを2にしています
hosts.txtが更新されました。tmpに対して名前が付きましたね。
137ce90 Probe dns-cache
unboundに対するPrometheusからの監視を設定しています。internalなhostnameとexternalなhostnameに対する名前解決もするようにしていそう。
017aca1 k8s/dns-cache: topologySpreadConstraints
unboundに対してtopologySpreadConstraintsを設定しています。Zoneごとにちゃんとばらけてくれるようにしています。
ef6d2bb k8s/dhcp: nameserver IPs
KeaがDNS resolverとして使うものを 8.8.8.8 からunboundに変更しています。
d9d2a64 air: more dynamic ips
IP addr足りなかった？
PrometheusがSNMPで監視する対象のhostを増やしています。
3551e94 snmp_exporter cisco wlc
CiscoのWLCに対してSNMPで取得するmetricを追加しています。
5788b2eで指定したWLCのhostnameを修正しています
306e534 prom: wlc uses public2 community
これちょっとよくわからない……WLCの居場所に関する設定？
345596c snmp-exporter: damerashii
ダメらしい。 f52e1bc で追加した一部の設定をコメントアウトしています。
hosts.txtを更新しています。順番が上に移動しただけ？
4124beb add am-i-at-rubykaigi s3 bucket
さて、会場でRubyKaigiのライブ配信を見ようとした場合には見られなくなっていたと思いますが、これがそれです。特定のS3 bucketに対し、会場内ネットワークからのアクセスであればDenyするような設定をしています。
ライプ配信視聴アプリ側ではここでその制御を行っています。
https://github.com/ruby-no-kai/takeout-app/blob/2657a8f46ac3068954c8ef46aaffeb2caac01eb2/app/javascript/Api.ts#L680-L699
d6f4953 cloudwatch: DX
AWS Direct Connectのmetricもcloudwatch-exporterで収集するようにしています。
fac7459 cloudwatch: MediaLive
AWS Elemental MediaLiveのmetricもcloudwatch-exporterで収集するようにしています。
RubyKaigiのライブ配信がどのようにAWSのサービスを使用して実現されているかはこの記事に詳しいです。まあ作者が書いてるので……
プリンター？
44518e6 dns-cache: temporarily set to permissive mode
一時的に val-permissive-mode: yes にしています。これなに？
DNSSECを無効にする方法 – 日本Unboundユーザー会
なるほどね。
a6affeb dns-cache: Reverse IPv4/6 zones
先の変更を削除し、zoneの逆引きの設定を変更しています。
836e010 dns-cache: trust reverse IP zones
privateなzoneは信頼するように設定しています……というかDNS周りのこれらの設定を日本語に起こすときの言葉の選択が正しいのか全然自信がない。
0f0f71b dns-cache: Only forward private IP reverse zones
private IPのみ逆引きをforwardするよう変更しています。
EC2やEBSなどへの監視設定をPrometheusに対して行っています。
9ef4827 Copy prometheus rules from cnw
sorah/cnw からPrometheusの設定を拝借しています。
ここからは設営日 (9/9)になります。
58ab522 prom: SNMP target down
SNMPで監視する対象がDOWNしている場合のアラートを設定しています。
f1dd400 prom: IXSystemUtilization
NECのルーターに対してのアラートを設定しています。CPU使用率かな？
8a48bd7 snmp-exporter: scrape sysinfo from wlc
WLCに対してSNMPで取得する項目を追加しています。
プリンターの居場所(というよりはhosts.txtから生成される定義？)が間違っていたっぽく、それを修正しています。
今思い出したけど、これテプラのラベルプリンター？
3307051 prom: alert on sysUpTime resets
SNMPで監視している対象の機器が再起動したときのアラートを設定しています。
4e85ec7 nocadmin: moooar bucket
NocAdmin roleに対してtakeout-app(配信視聴アプリ)関連のS3 bucketへの権限を付与しています。
9b5dfe8 86400 nagai; to 3600
自分が会場ネットワークにいるかどうかの判定に使用するBucketのresponse cacheが長いので1時間に変更しています。
いかがでしたか？
いかがでしたか？
2022年10月23日
ありがとうございました。
Kaigi on Rails 2022に参加していただいた皆様、ありがとうございました。登壇者の皆様、Proposalを出してくださった皆様、協賛してくださった企業の皆様、そして一般参加者の皆様のおかげで、Kaigi on Railsは今年も開催することができました。
Kaigi on Railsが継続的に開催されるためには、もちろん登壇したいとProposalを出してくれる方々、協賛して下さる企業の方々の存在も欠かせませんが、参加者の方々の感想も非常に重要です。楽しかった、学びになったなどのご感想は非常に嬉しいですし、ここはもっとこうだとよかった、などのご意見も、次回開催をより良いものにしていくためにはとても重要なものです。
では今回も雑用1
Proposalを出せなかったという個人的な後悔
自分も日々Railsアプリを開発することを生業とするプログラマーの1人なので、もちろんProposalを出したいという気持ちもあり、あたためているネタもありました。また業務委託として関わっている会社においても、Proposalを書く会に参加したり、Slackで迷っている人の背中を押したりしていました。
そんな中、Proposalを書き進めていくうちに、これに本当に価値があるのか？という疑問が浮かんでしまい、とうとう提出できないまま締め切りを迎えてしまいました。Proposalを出してもらう側としては、「価値があるかどうかはこちらが決めるからとにかく出してほしい！」と言う側だっただけに、自分自身がこういう結果になってしまうのは本当にいかがなものかと思います。
あとは実際に開催準備を進めていくなかで、この作業量で登壇するのは無理があったなということもわかりました。ふーがさんはすごい。
スポンサーブースについて
昨年のreBakoの体験が良すぎたので、今年もそのようなものを期待されていた会社さんも多かったのではと思います。しかし裏側の準備が実はとても大変でした。昨年の大倉さんによるレポート でもそのことが伺い知れるかと思います。端的に言ってしまえば、業務として取り組むレベルで作業時間が確保できるのであれば完成度の高い「場」が作れるが、我々はそうではなかった(昨年は無茶をした)ということです。それらの反省を踏まえ、今年はSpatialChatにブースを置くということになりました。スタッフが増えたこともあり、ブース設営に関しては昨年と比較して非常に健全な労力で行われたと感じています(ブースの準備には僕は参加できていませんが、準備期間のSlackの流量が全然違う)。
僕は配信を担当していたということもあり、SpatialChatのほうには顔を出せませんでしたが、他スタッフからの様子の報告であったり、TLを流れていくスポンサー各社様の催しの告知や感想を見ている様子では、reBakoじゃないとやっぱり厳しいかなという気持ちは取り越し苦労だったのかな？と感じました。それぞれのツールにはそれぞれの利点もあり、それぞれのつらみもあるものですが、今年のブースも皆さんに楽しんでいただけたようで何よりです。
登壇動画を集める仕組み
Kaigi on Rails 2022では録画での発表をサポートしています。これまでは、発表内容を録画した動画を提出してもらうのに、Google Formを使っていました。これは手軽な反面、Google Driveの容量を消費してしまいます。現にKaigi on RailsのGoogle Driveの使用率は80%に達しており、何か別の方法を考えたいところでした。もちろん保存容量は購入すれば済む話ではありますが……
そこで、ファイルをアップロードしてもらい、Firebase Storageに保存する2 3
同様のものはもちろんActive Storageを使用したRailsアプリでも実現することができます。しかし数ヶ月の使用期間しかないものに対してサーバー(herokuで言うところのDyno)を維持するのもなんだか、ということもあり、Next.jsとFirebase Hostingを選択しました。結果は37GBほどの動画ファイルを受け付け、諸々にかかった費用は2000円弱となりました。
動画編集
今年も昨年同様、提出していただいた登壇動画のレイアウトはめこみや音量などの調整、基調講演の字幕付けを行いました。ここについては特筆することはなく、単純に手を動かすだけ4
配信の画作りについて、昨年からのupdate
今年もKaigi on Railsは、ZoomとOBSとYouTubeを組み合わせた配信によって開催しました。ライブでの登壇者にはZoomの部屋に入ってもらい、そこから映像をOBSに流しこんで画作りを行い、YouTubeへ配信する、という構成です。具体的には2020年に書いたKaigi on Rails STAY HOME Edition 配信の裏側 に書いたような構成です。
さて、2020年及び2021年は、ZoomのデスクトップアプリとChromeから参加しているZoomの画面を、それぞれ登壇者の共有している画面、登壇者のカメラ映像に割り当て、それぞれの映像をOBSでウィンドウキャプチャしたものを配信レイアウトに流し込んでいました。この方法の欠点は、Zoom側の操作で画面のレイアウトが変化するとレイアウトが崩壊する、画面の切り抜きの領域を細かく調節する必要がある、など、要は登壇者の切り替わりのタイミングの数十秒で細心の注意を払い、なおかつ素早くレイアウト調整を行う必要があるということです。
そこで今回は、NDIを使用するためにZoom Roomsを導入しました。Zoom Roomsでは、NDIによる映像出力が可能です。
Using Network Device Interface (NDI) – Zoom Support
この機能を用いて、まず完全に独立したWindows機5
また、配信担当メンバーである僕のメインPCが最近謎のブルースクリーンで再起動をする6
具体的な配信の構成はこのようになりました。
検証を始めるタイミングが少し遅かったせいで、結局僕の家のZoom Roomsが単一障害点となってしまう問題は発生してしまいまいたが、配信中の細かい共有範囲の調整などのトータルの労力は昨年よりは減ったのではないかな、と感じています。
NDIを使用したイベントの配信に関する詳細については、以下の記事が参考になるかと思います。僕も参考にさせていただきました。
Zoom以外の選択肢として、ここ最近、様々な企業が開催する配信イベントでStreamYardが使われているのを観測しています。Kaigi on RailsでもStreamYardは試してみており、とても使いやすいと感じました。しかしStreamYardでは、Kaigi on Railsでやりたい「スポンサー企業のロゴをループでずっと流し続ける」ということができませんでした7
趣味 スティンガートランジション
これはイベント自体の運営には必須でない、趣味の領域でやったことについてです。(イベント運営自体そもそも趣味の領域なのかもしれませんが)
昨年の配信において、場面転換のところでアニメーションがかかっていたのを覚えていらっしゃるでしょうか。あれは配信班のメンバー、yrindaさんが突然持ってきたもので、僕含めスタッフ一同すごい！となったものです。
VIDEO
今年は、あれから僕も高専DJ部で映像を出すためにAfter Effectsを触るなどして少しわかってきたので、トランジション動画を作ってみることにしました。できたのが以下の2つです。
VIDEO
VIDEO
こういうものは、ツールの使い方を習得するのはもちろんですが、そもそもどういう映像を作ろうか、というアイデアを思い付くのも大変でした。一時期は寝る前に布団に入った後、ずっと頭の中で動画の構成を考えていたほどです。
僕がKaigi on Railsにかける想い
熱が冷めないうちに書いておきます。この3年間、決して少なくない時間を割いて、このKaigi on Railsというイベントの運営に関わってきました。僕がなぜそこまでするのか。それは以前「Railsを主戦場としている自分が今後学ぶべき技術について(随筆)」 にて、
学生時代にRubyを触ったのが始まりとなって新卒でRailsを書き始め、そこからキャリアの大部分にRubyとRailsがしっかりと喰らい付いている自分は、Rubyに対してもRailsに対しても結構愛着がある。レガシーとなってほしくはない。採用され続ける選択肢であってほしい。
と書いたように、Railsという技術に対しての愛着や、その周辺に存在するコミュニティへの感謝があるからです。そしてそれだけではなく、Kaigi on Railsが、そのコンセプト として掲げている、
また、名前の通りRailsを話題の中心に据えるカンファレンスではありますが、広くWebに関すること全般（例えばフロントエンドやプロトコルなど）についてもカバーすることで参加者の知見を深め、また明日からの仕事に役立てていただければと考えています。
にもあるように、「広くWebに関すること全般」を扱うカンファレンスでもあるからです。Railsはもちろん好きですが、それに留まらないWeb技術を広く扱うことのできるカンファレンスというものを続けていきたいのです。例を挙げるならば、2020年のsylph01さんによる、メールに関する各種概念の解説があったセッション「Action Mailbox in Action」 や、2021年のohbaryeさんによる、IETF draftとして提出されているIdempotency-Key Headerに関するセッション「Safe Retry with Idempotency-Key Header」 や、今年のursmさんによる、ギガバイトクラスの大規模なファイルを扱うためにWeb Workerを駆使したセッション「大量塩基配列登録申請システムができるまで」 などです。
RubyKaigiがRubyの話に留まらず、C言語やコンピューターサイエンスの最先端の話題を扱うように、Kaigi on Railsも、Railsというフレームワークに縛られない、Webの最先端の技術であったり、組織論についての話題であったりを受け入れる裾野の広いカンファレンスであっていたい、そんな話題を聞きたい、そのためにオーガナイザーとして今後も関わっていくつもりです。
また、カンファレンスを運営する立場になると、「好きなことができる」というのは、少なくない時間を投入する立場としては嬉しい点でもあります。例を挙げるなら、前述のファイルアップローダーは完成したものをいきなりスタッフ間に公開して「今年はこれを使うぞ！！」ということをしましたし、NDI経由での映像をGCP上のWindows Serverで受けとりそこから配信する、といったチャレンジも僕がやりたい！と言ったからできたものです。
もちろん自分の言い出したことで失敗しないように検証に検証を重ねることは必要ですし、そこで費用が発生するのであれば申請が必要だったりと手間はかかりますが、やはりカンファレンスを内側から好きなように運営できるというのは非常に楽しいことです。
Next
来年もKaigi on Railsは開催される予定です。そしてクロージングでも言及があったように、ようやくリアルに会場を押さえたin-person形式での開催ができそうです(記事公開時点で未確定)。リアル会場での開催となると、今までのようなリモートでの開催とは比にならないほど考えることが増えるでしょう。そういう意味でもスタッフはより増えてほしいですし、お手伝いはしたいが、そんなに時間を割くことはできないという方でも、当日スタッフという形での協力もできるのではないかと思います。
来年も皆さんの、様々なかたちでのご協力をお待ちしております。
2022年09月15日
発表について
https://slide.rabbit-shocker.org/authors/unasuke/rubykaigi-2022/ (みんなRabbit使おう！)
昨年の発表から方針を変更し、実装をしていく中で、Rubyだとつらいな～と感じた事について話しました。発表内で、「Ractorをやめた」という表現をしましたが、実際にはRactorに依存しない部分もそれなにり書き直しており、そのためコードの外部から見た振る舞いは、昨年からは微々たる進展しかありませんでした。
発表後、バイナリデータをRubyでそのまま扱うことについて、Samuel氏から IO::Buffer の存在について教えていただきました。
これはバイナリを扱うことについては既存のString、Integerよりも適していそうではあるものの、その内容に対して演算したい場合にまだまだ機能が不足しているのではないかと感じました。また、発表で用いたString、Integerでの操作を行うベンチマークを IO::Buffer も対象にして実行してみたところ、3つの中では最も遅いという結果になりました。
https://github.com/unasuke/rubykaigi-2022/commit/1e4470d55217d6c8 (これ、experimentalの警告を消す段階で hello_world_upcase_io_buffer のWarming up、Calculatingの結果が消えていますね……ミスです……)
この結果についても会場でSamuel氏と話したところ、演算する過程で都合上 set_value と get_value をしている部分があるのですが、そこでオブジェクトの正当性のチェック処理が走っている1
若干の燃え尽きだった
ところで、言ってしまえば前回のRubyKaigiからこれまでの間に、もっと多くのコードが書けたはずでした。しかし、昨年の発表の直後に開催されたKaigi on Rails 2021の運営、さらにその後に控えていたCloudNative Days Tokyo 2021での発表と、立て続けにイベントがあったことで若干燃え尽きてしまいました。しばらくプライベートの時間でQUIC関連のコードを書く気持ちになれない期間が続いていました。そもそも趣味プロジェクトだし、差し迫った締め切りというものも存在しないのも大きな要因でしょう。
締め切りを作っていく
なので今後は、もうちょっと自分を追い込んでいこうかなと思っています2 3
こっそりお手伝い
そして、実は今回のRubyKaigi 2022において、会場のインターネット設営の準備をお手伝いしていました4
2018年、2019年とhelperとしてやっていたのが一旦なくなったことで、3年ぶりにケーブルを8の字巻きしたり、ケーブルを這わせに会場を駆け回ったりするのはとても懐かしかったです。
そういう訳で、一般参加者T、登壇者T、スタッフTの三種5
Ruby Music Mixin
本編終了後には、ピクシブさんの主催するアフターパーティーでDJをさせていただけました。これがめちゃくちゃ楽しかったです。
ちなみにこれを聞いたのがこのタイミングだったのですが、クラブイベントの参加も初めてだったようで、それも楽しかったとおっしゃっていただけたのもとても嬉しかったです。
Next Kaigi
来年のRubyKaigiは松本リベンジということですが、実は7月になぜか松本に行っていました。このときは車で行ったので、来年も車で行こうかな？と思ったりしています。
でも実はそれより先にKaigi on Railsがあるので、まずはそれに向けてがんばっていきます。
2022年08月29日
これは自分用備忘録です。
方法
/Library/Input Methods/AquaSKK.app/Contents/Resource/kana-rule.conf を ~/Library/Application Support/AquaSKK/kana-rule.conf にコピーする
~/Library/Application Support/AquaSKK/kana-rule.conf の末尾に以下を追記する (EUC-JPである1
参考
余談 歴史を紐解く
元記事で書かれている ~/Library/AquaSKK/kana-rule-list とは何で、現在はどうなっているのでしょうか。調べてみました。
※ 以下記述はインターネット上の記述から僕が理解した内容で、憶測を含むため間違いが含まれている可能性が大です。当時を知っていて間違いに気付いた方は正しい歴史を教えてください……
まず当初、AquaSKKはText Services Manager2 ~/Library/AquaSKK に置く3
後にMac OS X 10.5 (Leopard)で導入されたInputMethodKit4 ~/Library/Application Support/AquaSKK/ に置く5
冒頭で言及した記事が書かれたのは2008年11月12日ですが、AquaSKKのIMK対応が開始されたのが2007年12月15日、IMK対応のコードがSVNリポジトリにコミットされたのが2008年6月26日です。(以下ChangeLogより)
https://ja.osdn.net/projects/aquaskk/scm/svn/blobs/head/aquaskk/trunk/ChangeLog
そして、IMK版対応の中で、2008年8月3日に移行スクリプトが作成され、この内容から ~/Library/AquaSKK/kana-rule-list に書いていた内容は ~/Library/Application Support/AquaSKK/kana-rule.conf に書くようになったことが推測できます。
https://ja.osdn.net/projects/aquaskk/scm/svn/commits/15
この移行スクリプトは2015年に削除されました。
https://github.com/codefirst/aquaskk/commit/da2ad5c264e7d9b91c4c9c4e015cb2db8a2a87c5
https://ja.osdn.net/projects/sourceforge/wiki/potm_0811_AquaSKK
更新履歴
2023-11-13 kana-rule.conf の文字コードについて注釈を追加
2022年07月04日
Itamaeとは
Itamaeというのは、構成管理ツールです。Ruby DSLで構成を定義することができます。Rubyで書けるAnsible1
local_ruby_block が実行ディレクトリの指定を考慮していなかった、という問題
さて、タイトルにもある「非互換な挙動」について説明します。
まず、Itamaeにはresourceというものがあります。これはdirectory resourceであればディレクトリの存在を定義でき、execute resourceであれば与えられたコマンドが実行されることを定義できます。resourceの一覧は以下Wikiにまとまっています。
https://github.com/itamae-kitchen/itamae/wiki/Resources
それらresourceのなかに local_ruby_block というものがあります。これは与えられたRubyのコードブロックを実行するものです。これにより、単にfile resourceでファイルを作成する場合と比較して、より柔軟にファイルの中身を制御するなどの様々なことが可能になります。
そしてresourceは、いくつかの属性を設定することができ、そのひとつに cwd という、そのresourceがどこで実行されるか(current working directory)というものがあります。
この cwd が、 local_ruby_block で機能していない、というのがissueとして報告されました。
cwd does not work in local_ruby_block · Issue #353 · itamae-kitchen/itamae
この問題の原因は、local_ruby_block を実行するItamaeのプロセスのworking directoryが cwd で指定されたものに移動していないからだ、と自分は考えました。
よって、この挙動を修正し、 cwd に移動した状態で local_ruby_block を実行するようにしたItamaeが、v1.14.0としてリリースされる予定です。mitamae側も、itamae側とタイミングを合わせてリリースします。
この挙動は2015年から存在していた
さて、このような挙動になっていたのはいつからでしょうか。これは、調べてみると cwd の属性が全てのresource typeで使用できるようになった、 2015年にリリースされた v1.4.0 からであることがわかりました。
Make cwd a common attribute. (idea by @tacahilo ) by ryotarai · Pull Request #146 · itamae-kitchen/itamae
2015年から今までの間にこの問題が報告されなかったということは、local_ruby_block を cwd つきで使用する人が今まで居なかったのか、それとも現在の挙動で問題無いと考える人しかいなかったのか……どちらなのかはわかりません。しかし、GitHubに存在するコードを検索した結果、 local_ruby_block と cwd の組み合わせが使われているコードは見当たりませんでした。
https://github.com/search?q=language%3Aruby+local_ruby_block&type=code
よってこの挙動の変更による影響はそこまで大きくないと見積もることができます。
問題はあなたの手元にある公開されていないコード
さて、Itamaeは構成管理ツールです。そのことを考えると、公開されていないItamaeのrecipe(構成を定義したコードのことをItamaeではこう呼びます)のほうが、遥かに多いはずです。それなりに長い歴史のある挙動を変更するので、既存のrecipeがこの挙動に依存しているかもしれません。
そのため、お手元のrecipeが以前の挙動に依存していて、かつ変更されると困る場合は、Itamae側に報告してください。この記事がその周知となれば幸いです。
2022年06月30日
TechFeed Conference 2022とは何か
株式会社テックフィードが運営しているITエンジニア向け情報サービス “TechFeed” が2022年5月14日に開催した、LTを主コンテンツとしたイベントです。
前代未聞、日本を代表するテックエキスパート50名による大LT大会、全セッション書き起こし！
コロナ禍でもエンジニアコミュニティを元気にすべく、TechFeedが総力を上げて実現する「エンジニアの祭典」、ここに開催！
https://techfeed.io/events/techfeed-conference-2022
このたび僕の発表「Ruby最新動向」の文字起こしが公開されたので、これを書いています。
経緯
TechFeedというサービスは知っていましたが、リリースされたくらいのときにアカウントを作ったきりで特に使用してはいませんでした。
そんなときある方から「TechFeed ConferenceでRubyについてのLTをしてくれないか」という打診がありました。その時点でイベントページを見ると、確かにRubyの枠は2つとも未定でした。
そしてそもそも、Rubyの公認エキスパートがMatzしかいないという状況にも気づきました。
同じく打診を受けた大倉さんとの雑談もとい打ち合わせのなかで、もし公認エキスパートへのお誘いが来たら受けよう、来なくてもさせてもらえないか聞いてみようということになりました。
そしたらTechFeed側の担当の方とのやりとりのなかで、公認エキスパートどうですかという打診があったので、二つ返事で承諾し、Rubyの公認エキスパートになることができました。
意気込み
という訳でRuby公認エキスパートとなりました。今後は、Ruby及びRailsに関する情報をシェアできていければと思っています。あまり積極的に(例えば毎日)活動できてはいませんが、何か面白い、興味深い記事があればシェアしていきます。
あと、自分のほうがRubyの最新情報に詳しいんだが？という自負のある方、是非とも認定エキスパートになってください。荷が買ちすぎてる気がしているので……何らかの手段で僕に声をかけてくれればTechFeedさんに繋ぎます。
2022年05月09日
Herokuの移行先を考える
今運用しているアプリ達をすぐにHeroku以外に移すということはしないまでも、競合となるプロダクトの調査をしておくことは(特に後発のものについては)機能面で実はこんなに便利なものがあったのか、と気づくことにもなったりするので、やっておいて損はないかと思いました。
比較対象について
比較する対象としては、インターネットで最近見かけるPaaSを選定しました。同様のことができるIaaSのコンポーネントとして、AWS FargateやGoogle Cloud Runがありますが、そのようなIaaSの一部として提供されるものについては今回は比較対象とはしません。
今回の比較対象は以下3つです。
deployするRailsアプリについて
HerokuにdeployするようなRailsアプリに必要な要素とは何かを考えたとき、まずDBが必要なのは当たり前として、Active Job(Sidekiq)やAction Cableを使いたいからRedisも使えてほしいです。もともとHeroku上にファイルはアップロードできないのでオブジェクトストレージは不要としました。
そこで、簡単なチャット(？)アプリを作りました。GitHubアカウントでログインすると100文字以内の文字列を投稿できます。ログイン状態に関わらず、投稿は自動的に更新されます。この仕組みは勉強も兼ねてTurbo Streamsで構築しました。
Render
公式にもHeroku対抗を謳っているだけあり、とてもHerokuに似たサービスです。僕自身、以前の記事で採用したことがあります。
Migrate from Heroku to Render | Render
実際、使い勝手としても、DBを作成すると環境変数 DATABASE_URL が自動的に追加されたりなどの挙動がHerokuと似ていて、新しく流儀を覚えなおす手間が少なくてよかったです。ただ、リソースは全てが一覧に出てきてアプリごとに管理するようなものではなかったです。deployはGitHubにpushすると自動で行われる感じでした。
Herokuにおける app.json と似たようなものとして、Blueprintという仕組みがあります。これによって、アプリで使用するリソース、接続情報などの環境変数、さらには接続を許可するIPアドレスなどをコードで管理できる(かつ、更新されたら自動で適用してくれる)のが便利でした。欲を言えばこのrender.yamlの書式が間違っている場合のエラーメッセージの親切さがもうちょっと欲しい1
価格ですが、DBにHeroku Postgresのような無料プランがなく、自動的に3ヶ月後から月$7になってしまいます。RailsとRedisは稼動している時間が制限内であれば無料のまま動かせるようなので、HerokuのHobbyプランを使っていると考えれば、まあ……というところでしょうか。
また、今回deployしたアプリでは使いませんでしたが、Diskとminioを組み合わせたオブジェクトストレージを用意できるのは便利そうです。
Railway
サービスとしてはコンテナやbuildpackによってビルドしたサービスをdeployできるPaaSです。
Herokuみたいな"Deploy on Railway"ボタンが作れるのもいいですね。
https://railway.app/button
また、公式及びコミュニティから提供されているStarterがかなり豊富です。
https://railway.app/starters
使い勝手としては、UIはすごくよくできてて操作が快適なのはよかったです。様々な言語、フレームワークに対応しているというか汎用的で、反面Herokuと比較すると自分で設定しないといけないことが多いように感じました。リソースもprojectごとにまとめて管理できるのがHerokuっぽくて良いです。deployはGitHubにpushすると自動で行われる感じでした。regionは現時点で選択できず、US-Westのみです。"We plan to add additional regions.“ と公式FAQ にはあります。
公式CLIが、npmやyarn経由でインストールしても実行可能なバイナリが配置されず、GitHub releaseからダウンロードしないといけなかったりちょっと不安ですが……
UIがすごくよくできている、というかよくできすぎていて、DBの中身が見れちゃうのは凄いと思います、がそんなに気軽に見れちゃていいの……？
価格体系がpricingページからはちょっとわかりづらいです。
https://railway.app/pricing
dashboradのbilingを見るとどのくらいのコストになるかが予測で表示されるのが嬉しいです。
サービスの使い勝手とは関係ないですが、内部の実装はJob descriptionを見るとBorgとMesosの論文から独自に開発しているようでアツいです。
上記ツイートにぶら下げられているJob descriptionは今は見れません、以下に移動したようです。
https://www.notion.so/Open-Jobs-bdc641c4b72947f2ab1e09bea5362363
Fly.io
mizchiさんのこのブログ記事で聞いたことのあるという方は多いんじゃないでしょうか。僕もそのうちの一人です。
Edge Worker PaaS の fly.io が面白い - mizchi’s blog
現在は公式サイトに "Run your full stack apps (and databases!) all over the world. No ops required.” とあるように、マネージドなPostgreSQLも使えるようになっています。公式ドキュメントにもRailsをdeployする方法についての記載があります。
https://fly.io/docs/getting-started/rails/
感想としては、CLI (flyctl) から操作するのがメインだなという印象です。環境変数の追加も閲覧もWebからではできず、CLIからしか行うことができません。DBとしてPostgreSQLを追加するのはそんなに苦労しませんでしたが、Redisを追加するのに結構手間取りました(接続情報を自分でRails側に渡してあげないといけない)。deployも手元で flyctl deploy をするフローです。
Herokuと比較した場合、東京リージョン(nrt)があるのが嬉しさでしょうか。
価格はこのようになっています。Herokuと比較してどうなるのかというのは一見ではわかりません。Usageを見ると現時点でのリソース消費量がわかります。
https://fly.io/docs/about/pricing/
また、これはサービスの使い勝手とは関係ありませんが、アプリケーションがFirecracker上で動くのはアツいですね。メトリクスにもFirecrackerの状態が出ています。
https://fly.io/docs/reference/architecture/
総評
自分がHerokuに慣れているというのもあるせいか、どうしても、どれもHerokuより多少なりとも複雑だなあという印象です。これらで、僕が移行するなら以下の順で検討すると思います。
Railway
サービス毎にリソースをまとめて見られる、UIが快適なのが1番として選んだ理由
Render
Fly.io
また今回、Herokuから移行するなら、という点でサービスを選定しましたが、これは複数人で管理していく2
個人開発のサービスをVPSからVercelとCloud Runに移行した話
今回deployしたアプリは今後数ヶ月ほどはそのまま動かしておいて価格がどうなるかを見たいと思います。その後は落とすかもしれませんし、データもバックアップはしません。
参考URL
2022年04月30日
msh3 as the third h3 backend……って何？
プログラマーの皆さんなら一度は使ったことのあるであろうcurlは、HTTP/3でリクエストを送ることができます。しかし、一般的に手に入るcurl、いわゆるOSのパッケージマネージャーから入手できるものでは不可能で、独自にビルドする必要があります。
(もし必要であれば、ここからHTTP/3が使えるcurl入りのdocker imageを入手できます https://github.com/unasuke/curl-http3 )
そのとき、外部のライブラリを組み込む必要があるのですが、これまではcloudflare/quiche か、nghttp3 のどちらかを選ぶことができました。
2022年4月11日、その選択肢にMicrosoftの開発しているQUICプロトコル実装であるMsQuic が加わりました。
このツイートをしたNickさんはMsQuicの主要コントリビューターで、それを使いやすくするための薄いラッパーライブラリであるmsh3 の作者であり、引用されているDanielさんはcurlの作者です。
じゃあビルドしてみよう
発表されたタイミングで、公式サイトのHTTP/3対応版のビルド方法についての記載が更新され、"msh3 (msquic) version" が追加されていました。
https://curl.se/docs/http3.html#msh3-msquic-version
それに従い、このようなDockerfileでビルドに成功しました。
FROM ubuntu:22.04 as base-fetch
RUN apt-get update && apt-get install -y git
FROM ubuntu:22.04 as base-build
RUN apt-get update && DEBIAN_FRONTEND="noninteractive" apt-get install -y build-essential pkg-config tzdata cmake
FROM base-fetch as fetch-msh3
WORKDIR /root
RUN git clone --recursive --depth 1 https://github.com/nibanks/msh3
FROM base-build as build-msh3
WORKDIR /root
COPY --from=fetch-msh3 /root/msh3 /root/msh3
WORKDIR /root/msh3/build
RUN cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=RelWithDebInfo .. \
&& cmake --build . \
&& cmake --install .
FROM base-fetch as fetch-curl
WORKDIR /root
RUN git clone --depth 1 https://github.com/curl/curl
FROM base-build as build-curl
RUN apt-get update && DEBIAN_FRONTEND="noninteractive" apt-get install -y autoconf libtool libssl-dev
COPY --from=build-msh3 /usr/local /usr/local
COPY --from=fetch-curl /root/curl /root/curl
WORKDIR /root/curl
RUN autoreconf -fi
RUN ./configure LDFLAGS="-Wl,-rpath,/usr/local/lib" --with-msh3=/usr/local --with-openssl
RUN make -j`nproc`
RUN make install
FROM ubuntu:22.04 as executor
RUN apt update && apt install -y --no-install-recommends ca-certificates && rm -rf /var/lib/apt/lists/*
COPY --from=build-curl /etc/ld.so.conf.d/libc.conf /etc/ld.so.conf.d/libcurl.conf
COPY --from=build-curl /usr/local/lib/libcurl.so.4 /usr/local/lib/libcurl.so.4
COPY --from=build-curl /usr/local/lib/libmsh3.so /usr/local/lib/libmsh3.so
COPY --from=build-curl /usr/local/lib/libmsquic.so /usr/local/lib/libmsquic.so
COPY --from=build-curl /usr/local/bin/curl /usr/local/bin/curl
RUN ldconfig
CMD ["bash"]
https://github.com/unasuke/curl-http3/blob/53287f3b1f08b41b11067a27d787272ce566c2a7/msh3/Dockerfile
さて、出来上がったcurlでHTTP/3なサーバーに対してリクエストをしてみると、なんだかうまくいきません。具体的には、www.google.com にはHTTP/3でアクセスできるのですが、nghttp2.org:4433 にはアクセスできません。他にも、msh3のREADMEに記載のある outlook.office.com や www.cloudflare.com にはアクセスできるものの、quic.tech:8443 や quic.rocks:4433にはアクセスできません。
きいてみよう
よくわからなかったので、msh3の作者であるNickさんに聞いてみました(というか、Nickさんが僕のツイートに反応してくれました。大感謝です)
うーん、nghttp2.org:4433がHTTP/3をサポートしていないなんてことがあるのでしょうか？quiche版やnghttp3版ではリクエストができるので、調べてみることにしました。
切り分けてみよう
問題がどこにあるのか切り分けることにします。READMEによると、msh3には msh3app という試しにリクエストを送るためのプログラムがあります。これで nghttp2.org:4433へのリクエストができれば、僕がcurlを正しくビルドできていないことになります。
msh3appをビルドするには、以下のようなコマンドを実行します。
$ # msh3/build 以下で実行
$ cmake -G 'Unix Makefiles' -DMSH3_TOOL = on ..
$ cmake --build .
これで build/tool/msh3appが生成されます。試しにwww.google.comと nghttp2.org:4433にリクエストを送ってみると、やはりnghttp2.org:4433へのリクエストは失敗しました。
では次に、MsQuicではどうでしょうか？MsQuicは、APIを使ったサンプルを用意してくれています。
https://github.com/microsoft/msquic/blob/main/src/tools/sample/sample.c
これをビルドする方法ですが、公式ドキュメントとしてビルドガイドがありました。
https://github.com/microsoft/msquic/blob/main/docs/BUILD.md
ここで、"Building with CMake" にあるような camke --build . ではこのサンプルコードはビルドされませんでした。恐らくCMakeの設定をいじらなければならないようですが、僕にはできそうにありません。なので、ビルドに使っていたUbuntu上にPowerShellをインストールし、 ./scripts/build.ps1 を実行することでビルドすることにしました。
さて、結果ですが、www.google.comと nghttp2.org:4433 のどちらもHTTP/3でのリクエストは成功しました！ということは、msh3のどこかに何かの問題がありそうです。
msh3を探索してみよう
全部で87行と小さいので、msh3appの元となる tool/msh3_app.cpp の処理を追いかけてみることにします。
https://github.com/nibanks/msh3/blob/v0.2.0/tool/msh3_app.cpp
コマンドラインから受け取ったHostを使用してConnectionを作成している、という処理をしていそうな72行目、 MsH3ConnectionOpen の実装はどうなっているでしょうか。
auto Connection = MsH3ConnectionOpen ( Api , Host , Unsecure );
MsH3ConnectionOpen の定義は lib/msh3.cpp の65行目からです。
https://github.com/nibanks/msh3/blob/v0.2.0/lib/msh3.cpp#L65-L81
extern "C"
MSH3_CONNECTION *
MSH3_CALL
MsH3ConnectionOpen (
MSH3_API * Handle ,
const char * ServerName ,
bool Unsecure
)
{
auto Reg = ( MsQuicRegistration * ) Handle ;
auto H3 = new ( std :: nothrow ) MsH3Connection ( * Reg , ServerName , 443 , Unsecure );
if ( ! H3 || QUIC_FAILED ( H3 -> GetInitStatus ())) {
delete H3 ;
return nullptr ;
}
return ( MSH3_CONNECTION * ) H3 ;
}
ここで、 MsH3Connectionの引数として443を渡しています。ここが怪しいです。
さらに追いかけていくと、MsH3Connection は uint16_t でPortを受け取り、それを174行目でStartに渡しています。このStartの実体はわかりませんが、ともかくPortとして443を決め打ちで渡しているために、443番ポート以外でHTTP/3をホストしているアドレスにはリクエストできなかったのでしょう。
msh3を直してみよう
では、直してみることにします。
lib/msh3.cppのほうは簡単で、MsH3ConnectionOpenがPortを引数として受け取れるようにし、それをMsH3Connectionに渡すだけです。
問題は/tool/msh3_app.cpp のほうで、コマンドライン引数として受け取ったアドレスからhostとportを分離、portがなければ443として扱う、という処理を行う必要があります。Rubyであれば String#splitやString#rpartitionで簡単にできるのですが、C言語となるとそうはいきません。
まず、以下のように sscanf を用いて分割しようとしましたが、ホストとポートの区切りである : が %sの対象になってしまいうまく分割できません。
https://wandbox.org/permlink/2PC5Qqsesd6avigW
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main ( void )
{
char * str = "nghttp2.org:4433" ;
char * givenHost = NULL ;
int Port = 443 ;
int len = strlen ( str );
givenHost = ( char * ) calloc ( len + sizeof ( char ), sizeof ( char ));
if ( givenHost == NULL ) {
printf ( "failed to allocate memory! \n " );
return - 1 ;
}
int count = sscanf ( str , "%s:%d" , givenHost , & Port );
printf ( "givenHost :%s, port: %d, count: %d \n " , givenHost , Port , count );
return 0 ;
}
悩んでいたところ、@castanea さんに以下のStack Overflowを教えていただき、 %[^:] を使うことでhostとportを分割することができました。
scanf - C - sscanf not working - Stack Overflow https://stackoverflow.com/questions/7887003
https://wandbox.org/permlink/q16ugMxasUhgzdWJ
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main ( void )
{
char * str = "nghttp2.org:4433" ;
char * givenHost = NULL ;
int Port = 443 ;
int len = strlen ( str );
givenHost = ( char * ) calloc ( len + sizeof ( char ), sizeof ( char ));
if ( givenHost == NULL ) {
printf ( "failed to allocate memory! \n " );
return - 1 ;
}
int count = sscanf ( str , "%[^:]:%d" , givenHost , & Port );
printf ( "givenHost :%s, port: %d, count: %d \n " , givenHost , Port , count );
return 0 ;
}
しかし、これでは不十分でした。というのも、MSVCでは安全性の観点からsscanfの使用は推奨されておらず、sscanf_s を使用しないと警告でWindows環境向けのコンパイルが失敗してしまいます。
よって、さらに #ifdef _WIN32 などしてWindows上とそれ以外の環境でsscanf_sかsscanfかを使い分けるようにしないといけません。
上記の過程を経て、msh3に対して作成したpull requestがこちらです。
Enable to connect to the host that hosting on non 443 port by unasuke · Pull Request #37 · nibanks/msh3
curl側を直してみよう
先ほどmsh3のAPIを変更したので、curl側にも修正が必要になります。
(実際には上で行ったmsh3への変更と同時並行で進めていました)
curl側でmsh3のAPIを使用しているのはlib/vquic/msh3.cになります。
https://github.com/curl/curl/blob/curl-7_83_0/lib/vquic/msh3.c
ここで、APIに変更を加えた MsH3ConnectionOpen を呼び出しているのは124行目です。
qs -> conn = MsH3ConnectionOpen ( qs -> api , conn -> host . name , unsecure );
なので、ここでport番号を渡してやればいいのですが……どこにリクエスト先のport番号があるのでしょうか？
これは #define DEBUG_HTTP3 1 などで色々な値を試し、conn->remote_port がそれだということがわかりました。なので、それを渡すだけでよさそうです！
- qs->conn = MsH3ConnectionOpen(qs->api, conn->host.name, unsecure);
+ qs->conn = MsH3ConnectionOpen(qs->api, conn->host.name, (uint16_t)conn->remote_port, unsecure);
Pass remote_port to MsH3ConnectionOpen by unasuke · Pull Request #8762 · curl/curl
という訳で、これもmergeされたことにより、msh3(MsQuic)版のcurlに任意のポート番号を渡してHTTP/3による通信ができるようになりました。
おわりに
C言語って難しいですね……
2022年03月30日
日本語版はこちら
tl;dr
I made this gem.
https://github.com/unasuke/omniauth-twitter2
This gem is one of the OmniAuth strategies for Twitter, using OAuth 2.0 for the authentication protocol.
We have omniauth-twitter gem. Why this gem?
Yes, the omniauth-twitter gem is a well-maintained, widely-used gem.
https://github.com/arunagw/omniauth-twitter
But, omniauth-twitter uses OAuth 1.0a.
Twitter OAuth 2.0 GA from 2021-12-15
When 2021-12-15, Twitter announced OAuth 2.0 General Availability.
And we can use “new fine-grained permission scopes” at the release.
We could choose those three kinds of scopes in the older permission scope. That’s too rough.
Read
Read and Write
Read and write and Direct message
But now, We can choose enough permissions from the list on OAuth 2.0 (through Twitter API V2)
https://developer.twitter.com/en/docs/authentication/oauth-2-0/authorization-code
tweet.read, tweet.write, tweet.moderate.write, users.read, follows.read, follows.write, offline.access, space.read, mute.read, mute.write, like.read, like.write, list.read, list.write, block.read, block.write
OK, how to use twitter with OAuth 2.0 with my rails app?
I created a gem, “omniauth-twitter2”.
https://github.com/unasuke/omniauth-twitter2
This is one of the omniauth strategies, so it’s easy to integrate your rails app if you use omniauth (or devise?)
(“2” means OAuth 2.0, not means successor of “omniauth-twitter” gem. because the gem still working everywhare!)
And I have created a sample application that uses omniauth and omniauth-twitter2.
This app only signs in with twitter, but it’s enough to show how to implement “sign in with Twitter”.
Attention
If you want to use OAuth 2.0 API in your twitter app, you should move your app to under “Project”. You can’t use OAuth 2.0 in your app if the app is still a “Standalone app”.
…And I’m not a specialist in the authentication. Please give me a pull request or issue if you found a bug.
