AutoMuteUs のサポート Discord や DM で聴かれたこと、日本語での情報が少ないことなどをまとめています。思いつきでほどほどに更新します。
Docker や Docker Compose それ自体の使い方というよりは、維持や運用の仕方とかそっちの方面が中心です。
その他の Tips 系は別エントリ Among Us 用ボット AutoMuteUs のあまり知られていない便利な機能 でも紹介しています。
カテゴリー: プログラミング
Game Update Notifier： ゲームのアップデートを監視して Discord で通知する（Steam / Epic Games / Microsoft Store 対応）
概要
あるゲームのアップデートの配信をいちはやく検知したい要件が発生したので、そういうツールを作りました。
現時点で、Steam と Epic Games と Microsoft Store に対応しています。事前に指定したゲームのアップデート有無を一定の間隔で監視し、アップデートがあった場合に Discord でメンションを飛ばして通知してくれます。
このツールは、詳細なパッケージやバージョンの生の情報を取得して監視 するため、既存のツールと違って、リリースノートの更新などを伴わない小さなアップデートでも検知できる のが大きな特徴です。
AWX を AWX Operator でシングルノード K3s にホストする
やりたかったこと
AWX の 18.0 から、インストールには AWX Operator の利用、すなわち Kubernetes や OpenShift 上へのデプロイが推奨されるようになりました。それ以前のバージョンでは Docker Compose ベースのデプロイも選択肢として用意されていましたが、現在では（開発やテスト目的を除いて）非推奨になっています。
とはいえ、気軽に使いたいだけ、シングルノードの可用性で充分、などの軽めのユースケースに対しては、すでに Kubernetes を使っている環境でない限り、AWX のためだけに Kubernetes 環境を作る（そして運用していく）のも少々大袈裟で大変です。かといって、公式のインストール手順 で気軽に試せる手段として紹介されている minikube は、プロダクション用途が想定されていない開発や学習用のツールのため、AWX をもう一歩踏み込んで日常的に使っていきたい場合には、逆に少し心許ないところがあります。
そんなわけで、ふたつの選択肢の間でほどよく使えるように、
- シングルノード で
- 外部からもアクセス できて
- データも永続化 できて
- それなりに手堅く 使っていける
感じのを、K3s で作ることにしました。
続きを読む
AmongUsOverlay： OBS で Among Us のゲーム状況をリアルタイムにオーバレイ表示する
概要
様々な興味と関心が脱線し続けた結果、OBS で Among Us を生配信するときに便利かもしれないオーバレイ表示を実現するツール、AmongUsOverlay ができました。例えばこんなことができます。
- ロビーにいるときだけ、部屋コードを隠す画像を自動で表示 する（ロビー以外では自動で非表示になる）
- プレイヤの色と名前 を表示し、死亡したプレイヤは死亡した画像に自動で切り替える（ネタバレにならないよう、緊急会議に入ったときに更新される）
- 選択した ステージに応じたマップを自動で表示 する。ディスカッション中だけは大きなマップに切り替える
- ゲームの終了後に、その ゲームのまとめ（勝者や時系列のイベント）を表示する
動作イメージは次のとおりです。
また、簡単な HTML と CSSで、上記のような画面を自分で簡単に作れるようになっています。例えば、上記のうち、ロビーでだけ表示される画像 は、次のたった一行の HTML で実現できます。
<img class="per_state only_lobby" src="<path/to/image>">
すぐに使えるデモ兼実装例も併せて配布しています。
続きを読む
Among Us 用ボット AutoMuteUs のあまり知られていない便利な機能
Among Us でゲームの状況に応じて自動でミュート・アンミュートしてくれる便利なボットこと AutoMuteUs、ほんとうに便利ですよね。
簡単な使い方であればインタネットの各所に解説記事がたくさんありますが、実は AutoMuteUs には、さらに便利に活用できるいろいろな機能 が用意されています。
本エントリでは、他の解説記事ではあまり触れられていない機能 を中心に、AutoMuteUs をさらに活用するための情報 を紹介します。
なお、文中で 公式サービス と記載していますが、これは AutoMuteUs 開発者が直々に運営しているサービス というだけの意味であり、Among Us の公式サービス ではない ことは念のため明記しておきます。
続きを読む
Caddy の Azure DNS 連携用モジュールをリリースした
作ったもの
Caddy の Automatic HTTPS で、DNS-01 チャレンジ に Azure DNS を利用するためのモジュールをリリースしました。
- Module dns.providers.azure – Caddy Documentation
- Download Caddy
- caddy-dns/azure: Caddy module: dns.providers.azure
OpenShift 4.6 のベアメタル IPI インストールを試す
はじめに
OpenShift 4 では、そのクラスタの構成方法に IPI（Installer-Provisioned Infrastructure）と UPI（User-Provisioned Infrastructure） の二種類があります。
これまで、IPI をサポートするプラットフォームは AWS や Azure、GCP、RHV、vSphere などのパブリッククラウドやオンプレミスの仮想化基盤に限定されていましたが、どうやら先月末にリリースされた OpenShift 4.6 で、ベアメタル環境への IPI インストールが公式にサポートされたようです。
In 4.6, the full stack automation installation of OpenShift on bare metal is generally available.
Red Hat OpenShift 4.6 Is Now Available
これまでも、GitHub 上では ベアメタル IPI の情報は公開 されており、以前も VirtualBMC for vSphere のユースケースとしても実際に 4.5 で動作を確認済み でした。
とはいえ、せっかく公式手順に仲間入りしたので、このエントリでは、OpenShift 4.6 で公式にサポートされたベアメタル IPI インストールの方法を、改めて紹介します。ただし、BMC を積んだ物理サーバが潤沢にあるわけではないので、物理サーバは VirtualBMC for vSphere を使った vSphere 環境の仮想マシンで代替します。
なお、今回紹介する手順は OKD でなく OpenShift のものです。インストールすると Red Hat OpenShift Cluster Manager に登録され、60 日間の評価期間 が始まります。
続きを読む
vSphere 上の仮想マシンを IPMI で操作する： VirtualBMC for vSphere (vbmc4vsphere)
ざっくり紹介
いろいろあって作りました。
これを使うと、vSphere 環境上の仮想マシンを、IPMI （ipmitool など）で制御できます。
物理サーバとまったく同じプロトコルが（もちろん全部ではないですが）仮想マシンに対して使えるようになるため、単に ipmitool による手動操作だけでなく、バックエンドで IPMI を必要とする、または IPMI があれば動かせる物理サーバ向け機能も仮想環境で動作させられる 可能性がある点が大きなメリットです。
具体的には、
ipmitoolでの手動操作（電源制御、起動デバイスの変更）- vCenter Server からの ESXi のパワーオン
- vSphere DPM（Distributed Power Management）による自動電源制御
- oVirt など他の仮想環境管理ツールの自動電源制御
- OpenShift の Baremetal IPI など、物理サーバに対する自動プロビジョニング機構
が、vSphere の仮想環境内で実際に動作させられる可能性があります。
もちろん、物理環境を完全にエミュレートできるわけではないため、完全な代替とは言えず種々の注意は要しますが、前述のものはいずれも動作確認済みです。
本エントリでは、仕組みと簡単な使い方を紹介します。
続きを読む
vCenter Server 7.0.0c で CPU 使用率が高騰する
追記： 7.0.0d で修正済み
本件の修正を含んだ 7.0.0d がリリースされました。
Resolved Issues にも本件と思われる問題が記載されています。
After an upgrade to vCenter Server 7.0.0c, you see high CPU usage
VMware vCenter Server 7.0.0d Release Notes
After you upgrade your vCenter Server system to vCenter Server 7.0.0c, CPU usage continuously stays high. On a single core, CPU usage might spike up to 100% for hours. The Workload Control Plane service causes the issue, even if you do not have Workload Management enabled in your environment.
This issue is resolved in this release.
手元の環境でも、ワークアラウンドを元に戻して事象を再現させた状態で 7.0.0d にアップデートし、事象が再現しなくなったことが確認できました。