前回のエントリ “Ansible Runner と Ansible Builder で Execution Environment を作って使う” では、AWX で Execution Environment を使うための前段として、Ansible Runner と Ansible Builder の動作を確認しました。
このエントリでは、その続きとして、作成した Execution Environment を実際に AWX から利用する流れを確認します。また、Container Group を作成して、Pod の構成をカスタマイズします。
続きを読む
Ansible Automation Platform 2.0 がアーリーアクセスで提供されはじめ、次期メジャリリースの情報が出てきました。
目立つところでは、Ansible Tower が Ansible Automation Controller に改名されていますが、アーキテクチャ面でも、制御プレーンと実行プレーンを疎結合にするために Execution Environment（EE）の概念が新たに登場しています。
従来、プレイブックに応じて Python のモジュールや Collection を使い分けたい場合、典型的には Python の仮想環境を用いた環境の分離を行っていました。Execution Environment（EE）は、平たくいえばこれを コンテナに置き換えるもの であり、Ansible のランタイムをコンテナ化したもの と言えそうです。必ずしも Tower（AWX）と組み合わせなくても使えますが、Tower（AWX）目線でも、本体のインスタンスと実行環境が分離されるので、スケールもしやすくなりそうです。
本エントリでは、AWX での Execution Environment（EE）の動きを確かめるための準備として、Ansible Runner と Ansible Builder の動作を確認します。次のエントリ では、本エントリで作成した自前の Execution Environment（EE）を実際に AWX から利用します。
続きを読む
AutoMuteUs のサポート Discord や DM で聴かれたこと、日本語での情報が少ないことなどをまとめています。思いつきでほどほどに更新します。
Docker や Docker Compose それ自体の使い方というよりは、維持や運用の仕方とかそっちの方面が中心です。
その他の Tips 系は別エントリ Among Us 用ボット AutoMuteUs のあまり知られていない便利な機能 でも紹介しています。
あるゲームのアップデートの配信をいちはやく検知したい要件が発生したので、そういうツールを作りました。
現時点で、Steam と Epic Games と Microsoft Store に対応しています。事前に指定したゲームのアップデート有無を一定の間隔で監視し、アップデートがあった場合に Discord でメンションを飛ばして通知してくれます。
このツールは、詳細なパッケージやバージョンの生の情報を取得して監視 するため、既存のツールと違って、リリースノートの更新などを伴わない小さなアップデートでも検知できる のが大きな特徴です。
様々な興味と関心が脱線し続けた結果、OBS で Among Us を生配信するときに便利かもしれないオーバレイ表示を実現するツール、AmongUsOverlay ができました。例えばこんなことができます。
動作イメージは次のとおりです。
また、簡単な HTML と CSSで、上記のような画面を自分で簡単に作れるようになっています。例えば、上記のうち、ロビーでだけ表示される画像 は、次のたった一行の HTML で実現できます。
<img class="per_state only_lobby" src="<path/to/image>">
すぐに使えるデモ兼実装例も併せて配布しています。
続きを読む
Among Us でゲームの状況に応じて自動でミュート・アンミュートしてくれる便利なボットこと AutoMuteUs、ほんとうに便利ですよね。
簡単な使い方であればインタネットの各所に解説記事がたくさんありますが、実は AutoMuteUs には、さらに便利に活用できるいろいろな機能 が用意されています。
本エントリでは、他の解説記事ではあまり触れられていない機能 を中心に、AutoMuteUs をさらに活用するための情報 を紹介します。
なお、文中で 公式サービス と記載していますが、これは AutoMuteUs 開発者が直々に運営しているサービス というだけの意味であり、Among Us の公式サービス ではない ことは念のため明記しておきます。
続きを読む
NUC 8 のオンボード NIC は、ESXi 7.0 U1 から、組み込みのドライバではうまく認識されなくなっています。このため、NUC 8 の ESXi を 7.0U1 以降にアップグレードするには、これまでは対象のドライバ ne1000 だけ旧バージョン（7.0b 世代）にダウングレードする必要がありました。この目的で、以前のエントリ では、特定のドライバだけダウングレードしたカスタムイメージプロファイルの作成と、それを利用したアップグレードを紹介しています。
が、先日、VMware Flings でこの問題を解決できる新しいドライバがリリースされました。
このドライバは、ne1000 ではなく別の新しい e1000-community（と igc-community）として認識されるため、組み込みの ne1000 ドライバと一切競合せず、共存できる 点がポイントです。NIC は ne1000 でなく e1000-community を使って動作するようになるため、ne1000 のバージョンは気にする必要がなくなり、ダウングレードが不要 になります。
プライベート CA が ACME プロトコルを喋れれば、ACME クライアントを使った証明書の発行や更新を気軽に試せて便利です。
もちろん正規の証明書は得られませんが、その代わり、インタネットにポートを露出することなく HTTP-01 チャレンジや TLS-ALPN-01 チャレンジが行えます。公開認証局のリソース負荷やレート制限、CT ログなども気にする必要はなくなりますし、上位の DNS で応答をコントロールすれば、実在しない TLD の証明書も発行できます。
このエントリでは、気軽に実現できる方法のうち、実際に試した次の三パタンを紹介します。
ACME クライアントを試す目的では、ふたつめの Caddy 案が個人的にはいちばん手軽で小回りが効く印象でした。
続きを読む
Among Us のゲームの進行に応じて Discord 上の各参加者のミュート・アンミュートを自動制御してくれるとても便利なボット、AutoMuteUs を初めて触りました。
動作にはボットのインスタンスを立てる必要があり、公開インスタンスが満員だったため、その場で自前サーバでのセルフホスト構成を作ったのですが、Docker でホストできることもあって、動かすだけならとても簡単です。Discord でのボット操作を一手に引き受けられるのであれば、インタネット上で公開する必要すらなく、LAN 内に配置するだけで済みます。
が、自分が居ないときでも仲間内で共同利用できるようにしたい場合、どうしてもボットのインスタンスはインタネット上でホストする必要があり、であれば少しでもセキュアにしたい感触があります。
そんなわけで、平文で行われている一部の HTTP や WebSocket の通信を、Let’s Encrypt の SSL 証明書とリバースプロキシ（Nginx）で暗号化したので、実装例の紹介です。
追記： Caddy でも実装 しました。エントリ末尾の追記部分 で紹介しています。
続きを読む
前回のエントリ で、AfterShokz のフラグシップモデルである Aeropex の音質を紹介しました。その中では、骨伝導であることそれ自体や防水・防塵のメリットは非常に大きい一方で、特に マイクの音質については厳しさがある 旨の記載をしていました。
根本的には Bluetooth のプロファイル（HFP）の仕様の限界があるので、有線のマイクと同等の高音質にはどうやってもできない（サンプリングレートが 16 kHz なので波形は 8 kHz で頭打ちする）のは仕方がないのですが、それにしても常用は厳しいと言わざるを得ない音質でした。
マイクの性能を重視するのであれば、Aeropex ではなく通話に特化した OpenComm の発売を待った方が良さそうです。
AfterShokz Aeropex の快適さと、音質の正直なところ | kurokobo.com
今回、この中でも言及している、通話に特化したモデルであるところの AfterShokz OpenComm を入手したので、主にマイクの性能の観点で、Aeropex と比較しました。
結果として、OpenComm のマイクは、Bluetooth 自体の仕様上の音質の限界はあるものの、Aeropex のそれとは比較にならないくらい充分常用できるレベルで音がよく、総じて満足できそうでした。
続きを読む