【超緊急 拡散希望】
本日(12/01) 10:34頃に、odakyu.app等を運営していたサーバーの全データを復旧不可能な状態で喪失しました
これは人為的なミスであり、サーバーを収容していたCloudGarage等に問題は全くなかったことをお知らせしておきます
大変申し訳ありませんでした

只今より、現存する最新のバックアップデータを利用して復旧を試みますが、復旧までどれほどの時間がかかるか全く想定できない状態です
つきましては、連合していた全サーバーの管理者の皆様にはご迷惑をおかけすることになりますが、どうかこの投稿をできるだけ広く拡散してくださると助かります

また、既存ユーザーの皆様には改めてお詫び申し上げます
早急に復旧を試みますので暫しお待ちいただけると幸いです

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

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

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

graph/deploy.yml at db70efdf07e200fe1e148597b018610d65c309b5 · inabagumi/graph github.com/inabagumi/graph/blo

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

mastodon-infra/Dockerfile at bf9a4ef39c3b18fac26dbade45d1cafc85fb23d5 · ykzts/mastodon-infra github.com/ykzts/mastodon-infr

パフォーマンス改善のため、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 github.com/ykzts/mastodon-infr

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

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

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

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

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

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

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

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

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

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

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

Stats of AniMare, HoneyStrap, and VApArt - Grafana graph.haneru.dev/d/HiOd6l1Zz/s

いつもPawooをご利用いただき、誠にありがとうございます。

ピクシブ株式会社は2019年12月2日を持ちまして、Pawooを株式会社クロスゲートに譲渡し、株式会社ラッセルが運営を引き継ぐ運びとなりました。

今後もPawooは株式会社クロスゲート及び株式会社ラッセルにより独立したサイトとして運営されます。現在お使いのアカウントは引き続きご利用いただけます。(pixiv連携によるログインもご利用いただけます)

ピクシブ株式会社におけるPawooへのこれまでのご愛顧に感謝いたしますとともに、運営会社が変更となりました後も、これまで同様、Pawooをお引き立てくださいますようよろしくお願い申し上げます。

詳細はこちらをご覧ください。
pixiv.co.jp/news/press-release

@mayaeh 一応、/health と /api/v1/streaming/health が死活監視用のエンドポイントになっていますね。

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

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

@lucida3free l10n_masterブランチはCrowdinからpushされているもので、定期的にmasterブランチと同期取られていますね。

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

Show more

山岸和利's choices:

ykzts.technology

ykzts.technologyMastodonのコミッターの一人である山岸和利 (ykzts) が個人で使うために運用しているMastodonサーバーです。