前回のエントリ “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 でメンションを飛ばして通知してくれます。
このツールは、詳細なパッケージやバージョンの生の情報を取得して監視 するため、既存のツールと違って、リリースノートの更新などを伴わない小さなアップデートでも検知できる のが大きな特徴です。
AWX の 18.0 から、インストールには AWX Operator の利用、すなわち Kubernetes や OpenShift 上へのデプロイが推奨されるようになりました。それ以前のバージョンでは Docker Compose ベースのデプロイも選択肢として用意されていましたが、現在では（開発やテスト目的を除いて）非推奨になっています。
とはいえ、気軽に使いたいだけ、シングルノードの可用性で充分、などの軽めのユースケースに対しては、すでに Kubernetes を使っている環境でない限り、AWX のためだけに Kubernetes 環境を作る（そして運用していく）のも少々大袈裟で大変です。かといって、公式のインストール手順 で気軽に試せる手段として紹介されている minikube は、プロダクション用途が想定されていない開発や学習用のツールのため、AWX をもう一歩踏み込んで日常的に使っていきたい場合には、逆に少し心許ないところがあります。
そんなわけで、ふたつの選択肢の間でほどよく使えるように、
感じのを、K3s で作ることにしました。
続きを読む
様々な興味と関心が脱線し続けた結果、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 案が個人的にはいちばん手軽で小回りが効く印象でした。
続きを読む