壁ツェーン

オンギャーの思考回路

Sipeed Longan Nano を入手しました

先日秋葉原Sipeed Longan Nano を購入しました*1。最近流行りの RISC-V アーキテクチャMCU を搭載したものですね。アツい。僕が入手したのはラジオデパートの Shigezone なんですが、店頭在庫は秋月も Shigezone も微妙っぽいので通販のほうが入手性は安定しているかもしれません。

所感

キットに 160x80 の RGB LCD (OLED という噂もあるが真偽は定かではない) とケースが付いてます。よくインタネッツで見かける Longan Nano の写真には透明なアクリルケースが写っていることが多いですが、最近のは半透明のケースになっているようです。尤も、あの透明なケースは閉めたら開けるのが意外と大変という声もあるようなので、これでいいのかもしれません。これで 750 円だっていうんだから大したものです。僕は思い切って 2 つ買ってしまいました。

ドキュメントを探していくとまあ中国語の多いこと多いこと。大陸パワーを感じます。公式ドキュメントは英語のものが同量ぐらいにはあるので活用しましょう。みんな Bad Apple! を再生してるけどまさかこれが公式のサンプルだとは思いませんでした。

:+1: ポイント

  • USB Type-C 接続。僕が持っているものだとこれ以外に Type-C で接続できるものは M5Stack ぐらいしかない。
  • Platform IO サポートがある。まああるのは当たり前として、比較的まともなのがいい。
  • 公式の Firmware Library が充実している。リファレンスマニュアルもあるし、サンプルが大量に用意されている。
  • ChaN 氏の FatFs のデバイス側実装が( Apache License 2.0 で)用意されているので、microSD を使うのに困らない(でしょう)。

:thinking_face: ポイント

  • LCD の制御方法が不明というかサンプルからしかわからない。多分何か有名な RGB LCD コントローラー IC と互換性のあるものなんだろうけど……
    • 追記 (Wed Nov 13 00:22:10 2019) 160x80 LCD でググったらそれっぽいのが千石に売ってた。もしこれと同じパーツならST7735Sとして扱ってよいのかな?
    • そういえば GREEN TAB でしたね。
  • というかそもそもサンプルを見ないとわからないことが多い気がする。さすがに多くを求めすぎだと思うのでこれは割り切って使うけどね。
  • プラケースの加工精度が怪しい。フタが完全に閉まらないのさすがに仕様ということはないでしょうし、本来切らない場所も多少切ってしまいました。

感想

今まで買った中で一番使い勝手がいいのでは感がある。性能が低すぎるということはないし(RISC-V 108MHz動作なら中々では?)、全体のサイズもデカすぎない。 Sipeed は他にも RISC-V で色々面白そうなボードを出しているので他に何か入手したいですね。

*1:厳密には ROM 64KB, RAM 20KB のモデルだったので Longan Nano Lite です

Prometheus と Grafana を Vultr VPS に乗せて kb10uy.org の監視をはじめました

f:id:kb10uy:20191103225856p:plain v('ω')v たのしい v('ω')v

経緯

昨日(11/2) @e_ntyo @h1manoa @java_shit の 3 人と一緒に第 n 回煮干しラーメンを食べる会(にぼ助リベンジ編)をやってたんですが、そのあとの駄弁り祭中に java_shit が「ぴゅっぴゅカウンター」をリニューアルした話をしてきました。

xn--y2wx43a.chitoku.jp

元々シンプルな PHP generated HTML だったんですが、記録をひたすら table タグで縦に表示していく仕様だったので(特に Chrome for Android で)描画が重くてまともに見られないという問題が発生していました。っというような事情があって、リポジトリによるとおよそ 3 ヶ月前に Grafana を用いたものに変更したようです。

grafana.com

VPS をエイヤっと

まずは VPS の契約からですね。いくつか候補はあったんですが、今回は Vultr にしました。今回はっていうか他の業者に追加でサインアップするかというと微妙なところなので多分これからずっと Vultr だと思います。 で、今回最大の失敗なんですが、招待リンクを経由せずに普通にサインアップしてしまいました。だいたい $10 ~ $50 ぐらい損しました。みなさん僕みたいにならないようにしてほしいので、ここに僕の招待リンクを貼っておきます:

↑の画像には Staring from $2.5 と書いてあるものの、その最安プラン(v6アドレスしかもらえないのが特徴的)は現在新規契約ができず、 $5 のプランからになるようです。ご注意ください。

OS はなんか便利そうなので Ubuntu 19.10 を選択しました。今回の記事は全体的に意思決定がノリと勘で構成されておりますがご了承ください。 あと手元にマシンがない(自宅鯖は最悪階段を上がれば実機があるが今回はそうではない)ので SSH の設定は慎重にやります。おかげさまで失敗しないですみました。 (文脈: authorized_key の権限設定を間違えた上に公開鍵ではなく秘密鍵を echo していた)

Prometheus を入れる

せっかく Grafana を運用するなら、ということで Prometheus も導入しちゃいましょう。プロミーシアス。プロメテウスって複数人いたらプロメティーなのか……?

prometheus.io

当初は 直接サーバー上にぶち込んで動かそうかと思ったんですが、 RAM 1GB なので Docker Image で運用することにしました。とっちらからないしね。

Grafana を入れる

同じようにして Grafana も Docker Image で導入します。 Prometheus も Grafana も Golang で書かれていて、この言語の新進気鋭ぶりが窺えるというものです。 まあでも Written in Golang 使うのはともかく僕は書きたくないけど……

コンフィグとかデータボリュームをやる

人類そろそろ YAML 使うのやめてくれませんかね? 誰も時刻を指定したくてポートマッピングをする人間なんていないと思うんですよ。そもそもエスケープ・エンクロージングなしで文字列を記述させようとするのがどうかしています。これはまあ INI とかにも言えることなんですが、スペースの削られ方などを毎回エスパーしたりするのが単純に面倒だし微妙に挙動が違って困るので本当にやめてほしいです。もっと TOML を採用しろ (……という話をチョリソー食べながらしていた)

なぜこんな話をしたかというとズバリ prometheus.ymlgrafana.ini を書くハメになったからです。前者はともかく後者については環境変数で渡すこともできるのでそこまで問題ではないだろうという思いもありますが、結局 docker-compose.yml に書いたところで YAML なので諦めて INI に書きました。

Prometheus は HTTP でエンドポイントを定期的に叩いて情報を収集するモデルなので、 prometheus.yml で指定するのはそのエンドポイントが存在するドメインとかです。監視対象のドメインをそれに書いていく……のは多分まれな例で、 Prometheus には auto target detection なる機能が存在するので AWS とかのアクセス権を渡しておけばスケーリングしても勝手にそれらに対して監視を開始・終了してくれるようです。対応サービス幅が広いしそもそも監視したい対象を考えるとこっちがメインなのは妥当でしょう。

あとさっき言ったエンドポイントを提供する exporter を被監視サーバーに配置します。初めてなので node_exporter を入れてみました。ちょうど netdata を他のものに変えようと思っていたので、 機能的にもうまく対応してくれそうです。これはバイナリポンでいいので雑にパケマネで入れちゃっていいと思います。こういうのは Golang のいいところが出てるなあと純粋に感心します。 パケマネで入れるもう一つのメリットは Systemd unit がついてくることでしょう。 Arch は systemd enable --now prometeus-node-exporter で、 Ubuntu はインストールした瞬間から即 enable されて動きはじめました。アグレッシブだな!

僕がコケたので忘れないうちに書いておくと、 Docker で動かす場合忘れてはならないのは同じホストで動いているのは本当に prometheus プロセスだけということです。何を今更という感じがしますが、雑に prometheus.ymllocalhost とか書くと死にます。ホストの exporter を参照したい場合はちゃんとゲートウェイになっているIPアドレスを指定してあげましょう。 docker.internal.host を早くよこせ

grafana.ini は幾分マシで、コメントが豊富なので書く内容で迷うことはそんなにないかと思います。が、実際書き換える内容といったら server 回りぐらいでしょう。 WWW に公開する場合正しい URL が生成されるようになんかいろいろやってください(忘れた)。

Caddy には勝てなかったょ……

どうせここまで Golang で来たなら最近話題の HTTP サーバーであるところの Caddy も使ってみようかと思い立ちました。結果からいうとダメだったのでいつも通り nginx でリバプロすることにしました。Caddy がバインドする 2015 ってあれなんで 2015 なんだ、 2015 年と何か関係があるのかな?

ほぼおわり

あとはもう消化試合みたいなもので、 Cloudflare からオリジン証明書をもらって ssl_cetificate(_key) に指定して ufw でいい感じにポート閉めたら終わりです。疲れたけど楽しかったね。

ダッシュボード

作るのたのしい!!!!

完走した感想(0b1111点の激ウマギャグ)

思ったよりすぐに VPSインスタンスが立ち上がってびっくりしました。あとCPU/RAMともに余裕がまだあるので何か bot でも動かしたいですね。

Laravel の artisan serve で WebAssembly を上手く扱えない件の対処

TL; DR

server.phpPHP: ビルトインウェブサーバー - Manual の例5の要領で追記。

解説

普通に素の状態で php artisan serve して困ることなんてまずないんですが、正しく MIME Type を判定できずに、 Content-Type ヘッダーなしでファイルのレスポンスを返してしまうことがあります。 で、それだと困るファイルの代表が WebAssembly (*.wasm)です。

なんで困るかというと、そのような適切でない Content-Type で配信された JavaScript は (少なくとも Firefox では) ブロックされるからです。

対処

artisan serveserver.phpルータースクリプトとして php -S の引数に渡しているので、ここで分岐すればいいだけですね。

書くことがなくなったのでおわりです