この記事はteam411 Advent Calendar 2025の14日目の記事です。
昨日(13日目)の記事は、古いバージョンのMinecraftを新しいバージョンのJavaで動かす試みに関する、みおずねさんの記事でした。私も過去、何度かMC1.7.10で様々なMODを入れて遊んだものですが、あれってもう11年前のバージョンなんですね...。レガシーな環境を愛するからこそ生まれた｢黒魔術｣、とても興味深いです。
はじめに
team411の部室には、なぜか1Uのラックマウントサーバーが3台あります。しかし、今年の夏まではそのうち1台だけが稼働していて、どのように運用していたのかも明確ではない、という課題がありました。当記事では、そんなサーバー群を部員が自由に使えるように再始動させるまでに私がしていたこと、今サーバーで何が動いているのかを紹介するとともに、引き継ぎ資料の一部も兼ねます。
大まかな整備の流れ
夏休み前
細かいことは覚えていませんが、「サーバーでVMを動かしたいんだよなぁ…でも何がどうなってるんだろうなぁ…」という声を聞くようになりました。そこで、たまたま暇人だった私に白羽の矢が立ち、インフラ管理部門の偉い人に突然昇格しました。
かといって私が住んでいるのは「一般のご家庭」なので自宅にラックマウントサーバーなんてものはなく、あるのはRaspberry Pi 4B(4GB)上のUbuntu Server程度。別組織でもインフラ管理を軽くやっていたので何とか耐えるだろうと思いながら引き受けることになりました。
夏休み
現状調査と再整備
環境を変えるには現在の動作状況を確認し、影響範囲を調査する必要があります。といっても、動作中のVMとその持ち主、あとは動いていない2台のサーバーに何が不足しているのか、等々を軽く確認した程度です。ストレージが存在していなかったのでそれを買い足しました。管理のしやすさを考慮して、動作中のサーバーについても同様の構成でストレージのセットアップおよびクリーンインストールを行うことにしました。あとはサーバーがラック内に平積みされていたのでレールを買ったりもしました。
ストレージ
ストレージですが、汎用品でいいのかを調べていたところ、サーバー機との相性の関係で「特定のSSDを挿さないと温度データが取れなくてReady to take offだよ」なんて書いてある海外サイトにたどり着きました。ファンが全力で回転している様子が「離陸直前」の飛行機のように聞こえる、という比喩ですが、英語圏でもそうなんだなぁと思った記憶があります。この説明にビビりながら、「とりあえず1枚だけ買って接続して相性を確認しておこう」ということで一般向けのSSDを適当に買って挿してみましたが、別に問題は起きませんでした。
ストレージについては、OS用の128GB SSDに加えて、VM等のデータ保存用として1TBのSSDを取り付けています。1TBのほうは、Cephクラスターとして運用しています。
ラック取り付け
team411のサーバー機にはレールがついていなかったのになぜかサーバーラックはあったため(棚板に積まれていた記憶)、専用レールの中古品を買い足して取り付けました。当日は自分含めて3人〜4人程度で作業していましたが、「ただ取り付けるだけ」と舐めていた作業に時間と体力を一気に持っていかれました。なんでただちょっと用途が特殊なだけのコンピューターに20kg近くの質量があるんでしょうね…
ネットワーク設定
ソフトウェア面の再構築に先立ってネットワーク設定も一部変更しました。具体的には、
- 管理系(ルーターやサーバーの管理画面やリモート接続用)
- ストレージ系(Cephクラスター用)
- VM系
- ユーザー系
の4系統でVLANを新たに振り分けました。
OSのインストール
動作中のサーバーから引き続き、OSにはProxmox Virtual Environmentを採用しています。再構築のタイミングでProxmox 9系がリリースされたので、少し導入には早いような気もしましたがこれをインストールしました。他のOSも検討しましたが、部内でVMをたくさん立てて使う用途で無料に済ませるにはやはりProxmoxが最適のような気がしました。様々な記事を読んでみても、学内外の多くの部内サーバーで利用されているようです。
夏休み明け
夏休み中に整備を終わらせて一般利用できるようにするつもりだったのですが、個人的な多忙だったりもあって気づいたら後期が始まってました。
ハード面の追加整備
後期になって前期とは別枠で予算が取れるようになったので、Cephのスペック要求に合わせてストレージ用に10Gbpsのネットワークを配線するなどの追加をしました。
ソフト面の整備
次章で詳しく述べます。
ソフトウェア面の特徴
認証基盤
従来のサーバーではユーザーおよび権限管理があいまいになっていたという点で、今回は認証基盤をしっかりと整えておくことを目標としました。
基本的には、以前の記事にも書いたようなLDAPサーバー + Keycloakの構成がベースになっているのですが、今回はディレクトリサーバーを自分で構築する必要がありました。(厳密には、Keycloakに直接ユーザーアカウントを持たせて単独で認証することもできますが、Keycloak側がLDAPサーバーから認証情報を読み出せても、Keycloak上の認証情報をLDAPで読み出す機能が存在しないため汎用性が低くなります。)
結論として、FreeIPAを基幹のアカウント・グループ管理システムとして採用しました。389 Directory Serverを中心としながら、様々なアクセスコントロール機能が付帯しています。1か所で認証・認可を、またホストベースのアクセス制御もできるという点が、個々のユーザーに対してVMを払い出して権限を付与するという今回の要件に合っているとこの時点では感じていました。
技術検証をしていくなかで、SSSDを使うと「1つのユーザーアカウントで複数のVMにログインできる」ということを知っていた点も決め手の1つになりました。電通大生向けに言うと、UECアカウント1つでsolにもCEDにもIEDにもログインできるのと同じ感覚です。同一ID・パスワードで、しかもSSH公開鍵も1回登録すればいい。複数台VMを運用するときでも嬉しいですよね。
さて、このSSSDを用いた認証ですが、FreeIPAのクライアントパッケージを用いることで特に複雑な設定なしに利用することができます。これは素晴らしい！と思いながらVM内でいろいろ試していたのですが、VM内で管理権限(sudo)を持っている場合に、それを経由してLDAP上の他ユーザーのパスワードを変更できてしまう、という点に気づきました。かなりの致命傷です。おそらく、前提としてIPAクライアントをインストールしたマシンは組織が管理するものであり、ユーザーにも管理権限を与えて自由に扱わせる、という使い方を想定されていなかったのだと思われます。しかしながら、今回払い出すVMではユーザーが自分の好きな使い方をできるようにするため、ユーザーに対して管理権限を与える必要があります。そこで、今回はFreeIPAクライアントを利用せず、SSSDがシンプルバインドでLDAPサーバーに接続するような構成をとりました。これにより、FreeIPAによる権限の集中管理の枠組みからは外れるものの、安全に運用できることになりました。また、ログイン権限の管理をローカルのファイル操作でできるため、ユーザー側で他のユーザーの追加や削除が簡単にできるというメリットも加わりました。プロジェクトで共同作業をするような場合にも対応できます。
(...ファイルを編集するだけで権限がいじれてしまうため、操作ミスにより誰もsudoできないVMを生み出してしまうことがあったりもしたんですが...。)
VM以外の様々なサービスのWebUI等のログインは、LDAPバインドやKeycloakを通じたOpenID Connect等、使用可能なプロトコルを使い分けて設定しています。
セットアップの自動化
今回は、IaC(Infrastructure as Code)の考え方も部分的に採用しています。具体的には、AnsibleによってユーザーアカウントやVMのセットアップを自動化しています。また、AnsibleのフロントエンドとしてAWXを導入してみました。これは、Ansible Automation Platform(Ansible Tower)のOSS版にあたるもので、AnsibleのプレイブックをGUI経由で実行できるだけでなく、その引数をフォーム形式(Survey機能)で要求したりプレイブック同士をつないでワークフロージョブとして定義したり、権限を持つユーザーからの承認を実行前に要求したりすることができます。
OSそのものに関わるネットワーク等のセットアップはProxmoxの標準機能と組み合わせてcloud-initを用いて、その上に乗るソフトウェアはAnsibleを用いて複数段階でセットアップすることで、要求に合ったVMを自動的にセットアップすることができます。また、Proxmoxの権限操作もプレイブック内に定義しておくことで、ProxmoxのWebフロントエンド上の権限も自動で設定されます。Proxmox自体のテンプレート機能だけを利用するような場合には実現ができない柔軟性が得られます。セットアップ時にパッケージ更新を走らせたり、定期的にOSイメージを更新したりすることで、常に作成時点で最新の環境をユーザーに払い出すことができます。
また、前述したFreeIPA + Keycloakの設定もAnsibleによって定義しています。そのため、テスト環境が欲しいような場合でも自動でそれを構築することができ、再現性も高まります。
再現性という点では、私が行ったインストールやファイル編集などの操作を逐一手順書として記録する手間も省けて、コードを読めば何をしていたかがわかるという点で属人性が解消されるように感じます(ProxmoxやAWXそのものの設定についてはコード管理になっていないのですが)。
Ansibleだけでなく、TerraformやPulumiといったツールの利用も検討していました。しかし、ユーザーが動的にVMやその権限を操作できるようにするという要件を踏まえると、今回は宣言的なツールとは少し相性が悪いように感じました。全VMの情報をGitHub上でコード管理し、ユーザーは該当リポジトリにプルリクエストを提出する、といった形で宣言的なVM定義が実現可能ですが、ユーザー・管理者ともに手間がかなり増大します。また、そのようなコードベースの定義では個人利用を含めたすべてのVMの存在がすべてのユーザーに示されてしまうという点にも潜在的なリスクを感じました。
対外接続の確保
部室にサーバーを設置するということは、サーバーは学内ネットワークの配下に接続されるということです。すなわち、グローバルIPを(特殊な手続きなしに)取得できず、いわゆる「ポート開放」の設定ができない、ということになります。VMに対するSSH接続を可能にするため、学内LANに向けて踏み台SSHサーバーを用意しています。これにより、学外 → 学内踏み台サーバー → 部内踏み台サーバー → 各VM のような経路で学外からアクセスすることができるようになりました。ssh_configのProxyJumpの設定は多重に適用することができるため、VMの情報をconfigに設定しておけば何も考えずにSSH接続ができるようになります。VSCodeのリモート開発拡張機能を使うユーザーにも優しい仕様です。
おわりに - 現状と今後について
以上がサーバーの再構築に関わるパートでした。再構築されたサーバーでは、基幹系の6台のVMに加えて、すでに何台か個人用・部内プロジェクト用のVMが動作しています。今後も、様々な技術検証や学習、また趣味やプロジェクト等で様々な用途でサーバーを活用してもらいたいと思います。また、技術系サークルだからこそ運用できるようなサービスがあっても面白いと思うので、今後も様々な用途を検討したいと思います。温度とか使用率とかちゃんと監視したいな。
team411の部員の皆様は、Notionのインフラ管理部門のページから説明を見ることができますので、ぜひ気軽にご利用ください!
Discussion