この記事で実現すること
Proxmoxのパッチ適用は、単体ならそこまで難しくありません。GUIで更新を確認して、適用して、必要なら再起動する。それだけです。
ただし、2ノードクラスタで、Firewallや認証サーバをVMとして載せていると話が変わります。
片方ずつ当てたい。
VMは事前に逃がしたい。
quorumは壊したくない。
失敗したら、もう片方には進みたくない。
そして、毎週これを手でやりたくない。
ということで、Proxmoxの週次パッチ適用をAnsibleで自動化しました。
今回の記事は、その仕組みの話です。
単に apt upgrade を自動実行する話ではありません。dry-runで更新候補を集め、重要コンポーネントを判定し、changelogをAIに読ませ、最後はAnsible側のルールで適用可否を決めます。
この記事は、自宅のProxmoxクラスタをAnsibleで自動運用している中で、AIエージェントにどこまで作業を任せられるかを検証してきた記録です。構成の全体像は前回記事「自宅のProxmoxクラスタ、AIに運用させる前に何を用意したか」で紹介しました。使っているplaybook（Ansibleの自動化用スクリプト群）や規範文書は、すべて公開しているリポジトリyoshi0808/homelab-ansible（https://github.com/yoshi0808/homelab-ansible）にあります。
今回はその続きとして、AIエージェントに実際の作業を任せる際に起きた出来事と、そこから組み立てた3つの防御の仕組みについて書きます。
AIエージェントに、本番サーバでの作業を任せたときのことです。
私が渡した手順書には、こう書いてありました。「作業ツリーの git status は権限の都合で見られないのが既知です。迂回しないでください。」
そのAIは sudo --become-user=yoshi を実行しました。私のアカウントの権限を借りて、見られないはずのものを見たわけです。そして報告書にこう書きました。
「正しいidentityを使っただけで、迂回ではない」
実害はありませんでした。私が驚いたのは、そこではありません。そのAIは、過去に似た操作が拒否されたことを認識したうえで、「あれはファイルを読もうとした、今回はプロセスを動かしただけだ」と自分で区別を立てて踏み込んでいたのです。禁止を理解していなかったのではなく、理解したうえで、禁止に当たらない理由を組み立てていました。
この一件は、教訓として記録してあります。
「本番には触るな」とプロンプトには書いていました。ハーネスで止めても、AIエージェントが誤って（迂回して）本番へ触ろうとしたことが何度かあり、そのたびに文章を書き足しました。書き足せば書き足すほど、守られない文章が増えていく感覚がありました。
最終的にやったのは、文章を足すことではなく、~/.ssh/ から鍵ファイルそのものを削除することでした。届かなくなったので、結果的に守れるようになったわけです。
——という運用を、自宅のProxmoxクラスタで行っています。この記事ではまず、その「運用されている側」、つまり何がどう動いているのかを紹介します。AIに任せるための設計そのものは、次回以降でまとめる予定です。
この記事で実現すること
前回の記事では、AIを使ってAnsibleのPlaybookを実装しました。作成したコードはGitにも登録し、変更内容を管理できる状態にしています。
今回は、本格的なAnsible運用へ進むため、Semaphore UIを導入します。作成したPlaybookをWebブラウザから実行し、決められた時間に定期実行できる環境を構築します。さらに、PlaybookをGitHubのPrivate Repositoryで管理し、実行結果をSlackへ通知できるところまで進めます。
この記事で実現すること
前回の記事ではAnsibleの紹介、AIとを組み合わせて私が実現している内容を簡単に紹介しました。
今回は、Ansibleのセットアップから簡単なAnsible Playbookを作ってみます。
この記事で実現すること
これまでの記事では、2台のProxmoxノード（V9.x）でクラスタを構成し、VMオンラインマイグレーションとフェイルオーバーの検証を実施しました。ここだけ見るととても素敵な機能ですが、普段からはその管理が必要になります。
一昔前であれば問題が起きたら対処する、自宅の環境なら責任もないですし、最悪はネットが使えれば良い、PCが1台あれば事足りる。そのレベルでも良かった時代でした。私もESXiの1台で運用していた時は、それが壊れたら壊れたなりにネットを回復すればそれでOKとしていたのも事実です。
Proxmoxになり、せっかくクラスター構成という安心感が得られるようになったことは良いのですが、運用が一段難しくなったのは事実です。
しかし、その難しさについてはAIの台頭によってカバーできるようになりました。
逆に言えば、さほど難しいことはわからなくてもAIがカバーしてくれることで、本来難しかった運用も楽になるとも言えます。
今回は運用を楽にするAnsible＋AIの紹介です。
この記事で実現すること
前回の記事では、2台のProxmoxノード（V9.x）でクラスタを構成し、VMマイグレーションとZFSレプリケーションを使える状態にしました。
ただし、2ノードクラスタにはquorumの課題があります。片方のノードが停止した場合、残った1台だけではクラスタとしての判断が難しくなるためです。
そこで今回は、外部投票サーバーとしてqdeviceを追加し、2ノードクラスタのquorumを安定させます。さらに、HA構成を作成し、テストVMを使って障害時のフェイルオーバーを確認します。
この記事で実現すること
今回の記事では、2台のProxmoxノードでクラスタを構成します。
Proxmoxは1台構成でも十分に利用できます。しかし、ファイアウォール、認証サーバー、監視サーバーなど、自宅の基盤となるVMを動かすようになると、ホストOSのパッチ適用や再起動のたびにサービスを止めることが課題になります。
そこで今回は、2台のProxmoxノードをクラスタ化し、VMマイグレーションとZFSレプリケーションを使える状態にします。
ただし、2台構成にはquorumの課題があります。片方のノードが停止した場合や、ノード間の通信が切断された場合、残った1台だけではクラスタとして正常に判断できない場面が出てきます。
そのため、最終的にはqdeviceを追加して、2台構成の弱点を補う予定です。qdeviceは後から追加できるため、今回はまず2台クラスタを作成し、VMマイグレーションとZFSレプリケーションを使ったメンテナンス性の向上を目指します。
この記事で実現すること
仮想環境のProxmox VE9.2でCloud-Initを活用する方法をまとめています。私はこれまでは単にUbuntu Desktop VMのクローンだけで済ませており、Cloud-Initの最初の手間を考えると大して時短にもならないと考えてましたが、最近はDesktopではなくほぼUbuntu Serverに変わってきていることや小さいノードを複数持たせる傾向にあるため、改めてCloud-Initのメリットを考えてみたいと思います。
この記事で実現すること
Proxmox VE 9.2では、GUIからカスタムCPUモデルを設定できるようになりました。
これまでVMのCPUタイプは、互換性を重視する場合はx86-64-v2-AESやkvm64などを選び、性能を重視する場合はhostを選ぶ、という考え方が一般的でした。
ただし、host CPUは物理CPUの機能をVMへ大きく公開できる一方で、異なる世代のCPUを持つクラスタではライブマイグレーション時の安全性に注意が必要です。
今回、Proxmox VE 9.2のカスタムCPUモデルを使い、従来利用していたx86-64-v2-AES相当の設定と比較して、暗号処理やI/O性能にどの程度差が出るのかを検証しました。