山岸和利 @ykzts@ykzts.technology

#因幡はねる さん関連のウェブアプリやウェブサービスの開発をしています。

わたしが作ったものは以下のページにまとめています。気に入ってもらえたらうれしいです。

Haneru Developers https://haneru.dev/

ykzts.technology で使われているKubernetesのマニフェストファイルはある程度汎用的に書いているつもりなので、ドメイン指定などの ykzts.technology 固有の記述を書き換えるだけでGKEでMastodonのサーバーを動かせるかと思います。

ykzts/mastodon-infra: A manifest of Kubernetes for ykzts.technology. https://github.com/ykzts/mastodon-infra

Kubernetesクラスタにアプリケーションのデプロイを行うようにしておくとGitHubへのPushをトリガーとするデプロイが容易に行えるようになりますね。GitHubへのPushをトリガーとすることによって人間によるオペレーションを排すことができて無用な事故が減らせるのではないでしょうか。

graph/deploy.yml at db70efdf07e200fe1e148597b018610d65c309b5 · inabagumi/graph https://github.com/inabagumi/graph/blob/db70efd/.github/workflows/deploy.yml

New Relicの導入はDockerfileで bundle add newrelic_rpm を実行して config/newrelic.yml を追加するだけで簡単に導入できます。Elastic APMも同様な手順で簡単に導入できますし、こういったものはコードの改修が不要で簡単に導入できるものであるほうが嬉しいですね。

mastodon-infra/Dockerfile at bf9a4ef39c3b18fac26dbade45d1cafc85fb23d5 · ykzts/mastodon-infra https://github.com/ykzts/mastodon-infra/blob/bf9a4ef/mastodon/Dockerfile

パフォーマンス改善のため、ykzts.technology にNew Relicを導入してみました。

初めはElastic CloudのAPMを使ったのですがすぐにストレージ容量がいっぱいになってしまったため断念しました。New Relicは無料版ではログの記録保持期間が一日しかないので継続的な監視は難しいのですが今回はパフォーマンスの確認の用途にしか使うつもりがないので良しとします。

最近はGitHub Actionsを用いたワークフローの作成とKubernetesを用いたインフラの構築にハマっています。どちらもコードベースでの丁寧な管理ができるのが良いですね。

GitHub Actionsを用いてmasterブランチにpushされたタイミングでGoogle Kubernetes Engineにデプロイを行うワークフローを作成しました。Skaffoldを使っているおかげで簡単な記述で期待通りの成果を得られるのが良いですね。

今回は手を抜いて記述の正当性の検証を行っていませんがPull Requestが作られたタイミングである程度の検証は行うようにしていきたいですね。

mastodon-infra/deploy.yml at aa47ee9cf305d38d21205c6620f54d244e522363 · ykzts/mastodon-infra https://github.com/ykzts/mastodon-infra/blob/aa47ee9/.github/workflows/deploy.yml

誤ってKubernetesのIngressを削除してしまい割り当てていたIPアドレスが揮発してしまいました。そのためしばらくの間、 https://ykzts.technology/ への接続ができなくなっていました。

設定を変更したので今はもう大丈夫なのではないかと思われます。

GitHub ActionsでKubernetesのデプロイが成功するかを確認するワークフローを作ってみました。

Skaffoldのdeployコマンドには --status-check というオプションがあり、ステータスが完了するまで待ってくれるのでCIから実行する際には便利ですね。またk3sもDocker Composeで簡単に動かせるのでCI用途には最適ですね。

chore: move dir (#6) · ykzts/graph@43fe811 https://github.com/ykzts/graph/runs/312010860

仕事ではGKEかEKSのようなマネージドのKubernetesを使うことになるとは思いますが、ホビーユースでは数台のノードでk3sで充分なケースも多いでしょうね。Azureの場合でもAKSのようなサービスがあり、便利な時代になっていますね。

参考までにマニフェストファイルはこちらです。マニフェストの管理にはKustomizeを使い、デプロイにはSkaffoldを使っています。

Goで書かれたクライアントを使ってInfluxDBに情報の書き込みを行っています。

inabagumi/graph: Stats of AniMare, HoneyStrap, and VApArt https://github.com/inabagumi/graph

勉強がてらにMicrosoft Azureの仮想マシーンでk3sを動かしGrafanaを動かしてみました。

k3sは簡単に環境の構築ができて良いですね。今はシングルノードで動かしていますが、ノードを増やすのも簡単にできそうなので負荷が増えても心配は薄そうですね。

Stats of AniMare, HoneyStrap, and VApArt - Grafana https://graph.haneru.dev/d/HiOd6l1Zz/stats-of-animare-honeystrap-and-vapart?orgId=1

2019年10月の収支報告 https://www.patreon.com/posts/2019nian-10yue-31635932

WebBundle によるコンテンツの結合と WebPackaging | blog.jxck.io https://blog.jxck.io/entries/2019-11-12/webbundle.html

いつの間にかGitHub Actionsでもキャッシュができるようになっていますね。これでGitHub Actionsが実用的に使えるようになった人も多いのではないでしょうか。

actions/cache: Cache dependencies and build outputs in GitHub Actions https://github.com/actions/cache

Google Developers Japan: 以前の TLS バージョンのサポート終了に伴う Chrome UI の変更点 https://developers-jp.googleblog.com/2019/10/tls-chrome-ui.html

最近は原宿でジェラートを度々食べていますね。

Grafanaをデフォルトの構成で動かしている場合、アラートの通知に画像を含めるようにすると通知が飛ばなくなります。

Grafanaはグラフを画像化する際に標準ではPhantomJSを使っています。これはリクエストがある度にPhantomJSのプロセスをつど起こしているのでとても遅い。なのでよほどのスペックがない場合はタイムアウトしてしまいます。これはGrafanaが提供するプラグイン、Grafana Image Rendererを導入することによって解決します。

ただGrafanaの公式DockerイメージがAlpineをベースにしているのでそのままgrafana-cliでGrafana Image Rendererを導入しようとするとリンクされている共有ライブラリが存在しない為に正常に動作しません。なのでGrafana Image RendererもGrafanaと同様にDockerイメージを使ってサーバーとして動かす必要があります。

grafana/grafana-image-renderer https://github.com/grafana/grafana-image-renderer

DenoがJSXに対応した - No Regrets in Bathing http://hashrock.hatenablog.com/entry/2019/10/09/235615