この記事は エーピーコミュニケーションズ Advent Calendar 2023 の1日目の投稿です。

今年の 4 月に株式会社エーピーコミュニケーションズ (以降、APC) に入社して半年経ちました。 今はがっつり Azure をやっている感じですが、前職では Azure だけでなく色々なことにチャレンジさせてもらいました。

その中でも一番最初にチャレンジ（通常業務とは別で取り組んだ業務改善）したのは Ansible の導入でした。 そもそも Ansible とはなんぞや？って状態だったので Ansible を実際に触ってみようと、まずは Ansible もくもく会に参加しました。

当時はまだコロナ禍前の世界ということもあり Ansible コミュニティが開催していたもくもく会は数少ないオンライン参加が可能な勉強会で、これが自分にとって初めての技術コミュニティへの接触でした。

それから度々 Ansible コミュニティのイベントに参加していき、その中で某金魚の方を始めとした APC 所属の方をよくお見かけして APC という会社を知りました。 自分の興味が Ansible に加えて Kubernetes や Azure に広がっていった際も APC の名前を見ることが多く、Ansible に限らずアウトプット活動が盛んでとても楽しそうな会社という印象を持っていました。

アドベントカレンダーもその楽しそうな活動一つで、APC のアドカレ（組織のアドカレと言ったほうが正しいかも）に参加することは一種の憧れでもありました。 そんな APC に入社できたのも、自宅で自由に検証ができる環境「自宅ラボ」を導入してスキルアップできたのが大きいです。

というわけで、アドカレの初日にポエムっぽい投稿になってしまいますが「自宅ラボ ジャーニー 2023」と銘打って自分の過去ツイートを引用しながら自宅ラボの遍歴を紹介します。

ちなみに見出しは有名どころのサブタイトルを引用していますが特に意味はないです。

【序章】自宅ラボは出ているか?

はじめに自宅ラボを導入するに至った動機ですが、理由は単純で「自由に使える環境が欲しい」と思ったからです。

冒頭で話したとおり、前職で自動化やサーバ管理を推進するために Ansible を触り始めたのですが、検証環境を用意するのもなかなか難しいものがありました。 特にプロキシに阻まれまくった。 最初の頃は Ansible もくもく会で使える環境で十分満足していたのですが、そのうちもっと色々な検証をしたくなって自由に使える プロキシに阻まれない 自宅ラボを導入することにしました。

おそらく自宅ラボを構築している方の多くが同じ動機なんではないでしょうか。 あと、ロマンとか探究心みたいな気持ちも少しはありましたね。

クラウドサービスを利用するのもよかったんですが、インフラの勉強をするにあたってやっぱり物理で触れるものが欲しいという理由でクラウドは除外しました。 とは言っても一部のサービスは自宅ラボと連携する形で利用しています。

そういうわけで自宅ラボを導入することを決意したのですが、この時期に Ansible と並行して OpenShift にも興味を持ち始めていて、まずは OpenShift の導入を目標に自宅ラボを構築していきました（そもそも最初に自宅ラボとして OpenShift を選択することの無謀さをまだ知らなかった）。

初めて「自宅ラボ」という単語を使った記念ツイート。

【第一章】自宅ラボ大地に立つ！！

記念すべき自宅ラボ一号機として DeskMini A300 を導入しました。 界隈には自宅にラックサーバを設置する猛者もいることも知ってはいたのですが、さすがにハードルが高くて断念しました。

構成はこちらにまとめています。 今も対して変わっていません。

仮想化基盤のパーツ購入&構築
仮想化基盤のパーツ購入&構築
先月の投稿で自宅ラボの機器選定をしました。結論を言うと、DeskMini A300 を買いました。 仮想化基盤のハードウェア選定 つよつよエンジニアには「自宅ラボ」という検証環境をお持ちの方が多いようです。 「自宅ラボある⇒つよつよエンジニアになる」ではないですが、自宅ラボあれば勉強する機会が増えるのではということで、自宅ラボ構築を目指します。 「逸般の誤家庭」と呼ばれる常軌を逸した環境（褒め言葉）を構築されている方もいらっしゃるようですが、お財布のほうも常軌を逸してしまいそうなのでコスパ重視で自宅ラボを構築を検討します。 今回は、仮想化基盤用マシンのハードウェア選定をしていきます。ネットワークについては別途検討予定。 目的（なぜ仮想化基盤用のマシンを用意するのか） 自宅でも快適にKubernetesクラスタを検証するためです。 現在は自宅PC(Win10)にVMware Workstation Playerを入れ、その上にESXiを入れてしてネスト仮想化基盤を構築しています。 しかし、PCのスペックがそこまで高くうえにネスト構成にしたためESXiのVMは激重になってしまいました。 当初はOpenShift4を動かしてみるつもりでしたが、インストール作業が終わりませんでした。OpenShiftは要求スペックが高いですね…。 Chapter 1. Installing on bare metal OpenShift Container Platform 4.3 | Red Hat Customer Portal Access Red Hat’s knowledge, guidance, and support through your subscription. 代わりにkubeadmでK8sクラスタ（master3台, worker3台）を組んでみたのですが、クラスタできたもののPrometheus-Operatorを入れてみたら無事に死亡しました。 そのようなこともあり、快適にK8sクラスタを動かすことができる自宅ラボを構築することが目的となっています。 機器選定 マザーボードと電源が一体となった「ベアボーン」 or パーツをそれぞれ自分で選ぶ「自作PC」の2通りから考えます。 （ベアボーンも自作PCに含まれると思いますが、適切な表現が不明なので分けて記載します。） 本当はラックサーバが欲しかったのですが、自宅の要件（電力だったり騒音だったり）に合いそうにないため除外しています。また、タワーサーバは中古市場であれば比較的安価なものが出回っているようですが、十分に調べきれていないためこちらも除外しています。 ストレージ ストレージは各候補ともに共通の製品を選択予定です。 パーツ 型番 特徴 価格.comの最安値 ストレージ WD Blue SN550 NVMe WDS500G2B0C m.2 NVMe 8,448 ASRock Deskmini A300 パーツ 型番 特徴 価格.

このマシンに仮想化基盤として VMware ESXi を入れて、その上で OpenShift を動かそうとしました。 その際の奮闘ぶりを投稿していますが、結論から言うと動きませんでした。 完全にスペック不足です。

OpenShift 構築奮闘記 #0
OpenShift 構築奮闘記 #0
OpenShift の構築に試行錯誤した記録を残すため「OpenShift構築奮闘記」というタイトルで連載を始めます。 手始めに OpenShift を構築することにした経緯と、インストールする構成を残しておきます。 どのような課題が発生している/していたかは #1 以降で記載します。 なお、執筆時点で構築完了していないため連載回数は未定です。 事の始まり 弊社（弊部署）には毎月hh時間は技術向上のために遊んでよい（業務外のことをしてよい）、という取り組みがあります。 その一環で、自分は Kubernetes や Ansible といった技術の検証（勉強）を進めていました。 検証のためのVMは用意してもらっていましたが、1台しかないため色々試したいことが試せず悶々とした日々を過ごしていました。 e.g. 1サーバに GitLab(omnibus) と Kubernetesクラスタ を同居させて、 GitLab から Kubernetes に連携しようとしても「同じサーバ上にあるからダメー」と怒られたり…。 そんな折の今年１月末に突如、「保守期限切れになったサーバ（正確にはワークステーションらしい）を廃棄する前に自由に使っていいよ」とボスから声を掛けていただきました。 ↓その日の定時後の様子 なんか知らんけど保守切れ物理サーバ5台を自由に使っていいことになった！なんのご褒美だ？何して遊ぼうかな、やっぱりKubernetesかなー — ののし (@nnstt1) January 31, 2020 5台も使えることになったのですが、前職を含めても物理サーバを直接触ったこともないド初心者です。 とりあえず1台分だけ VMware ESXi を導入してVMの作っては壊しをできるようにして、その VMware 上に当初から考えていた Kubernetes クラスタを構築を目指しました。 社内ネットワークということもありプロキシやら認証やらで手こずりながらも、なんとか kubeadm を使った Kubernetes クラスタを構築することができました。（この内容もいずれ記事に残したいです） そんなこんなして遊んでいたら、Red HatのウェビナーやSoftware Design 3月号で紹介されていた OpenShift の詳細を知る機会があり、興味が湧いてきました。 OpenShift、いいですよね（説明を見聞きしただけで触ったことはない）。 使うだけならARO（Azure Red Hat OpenShift）が楽だと思いますが、せっかくなので VMware 上に OpenShift を構築することを次の目標にしました。 構築にあたり以下の記事を参考にさせていただいてます、ありがとうございます。 failed to fetch remote resource: Forbidden OpenShift 4.

OpenShift を動かすことは断念し、マシンはそのまま VMware ESXi を使った仮想化基盤として第二の人生を歩み始めました。 この ESXi 上で Ansible Tower（今で言う Ansible Automation Controller）や Zabbix、Kubernetes などを動かして遊んで勉強していました。 しばらくはこのマシン一台体制のままでした。

同じ頃、Ansible を使うなら管理対象のネットワーク機器がいるよね、ということで Cisco 891fj をヤフオクで購入しました。

X (Twitter) で当時の様子を振り返ってみるとこんな感じ↓でした。

謎の試行錯誤を経て Cisco の機器を購入する決意をした模様。 機器選定は前職のネットワーク担当の同僚に相談して 891fj がいいんじゃない？ということで決めました。

なぜこんな状況になったかというと、ヤフオクで最初にポチった 891fj に AC アダプタが付属されていなかったから。 哀しい哉、この 1 台目は未だ電源が入らない状態で鎮座していて永遠のコールドスタンバイ状態です。 ヤフオクでポチる際はちゃんと説明欄を読みましょうね……。

ネットワークに関してはズブの素人だったので前職の同僚に色々教えてもらいながら運用していったのですが、仕事でも Ansible の自動化対象はサーバメインだったこともあり自宅ラボでネットワークを勉強する機会はありませんでした。 891fj は今も自宅ラボのネットワークを司ってはいますが、完全にアンタッチャブルな存在となってしまっています。

整理すると、初期の自宅ラボは以下のような感じでした。

  • Cisco 891fj で自宅ネットワークとは別のラボ用ネットワークを構成
  • DeskMini A300 に VMware ESXi を入れて仮想化基盤として運用

architecture1

この頃に Azure Arc やってみたけど、そういえばこれ以来触ってないかも。

【第二章】私のラズパイは凶暴です

自宅ラボに仮想化基盤を構築していた頃、ラズパイを使った Kubernetes クラスタというものをよく見かけるようになっていました。 いつかラズパイ Kubernetes をやってみたいなぁと思っていた私はラズパイ導入に向けて動き始めていました。

ちょうどラズパイ 4 が販売されたので最終的にラズパイ 4 を 3 台導入したのですが、既に仮想化基盤上に Kubernetes クラスタを作っていたこともあってラズパイは Kubernetes 用には使わず、当時興味を持っていた分散ストレージの Ceph を構築するために使いました。

ラズパイを使って Ceph クラスタを構築できるという情報はネットで見かけていたので着手したものの、実際に手を動かして見ると ARM 未対応の箇所があったり、ラズパイと SSD を繋ぐケーブルの相性問題が発生したり、とめちゃくちゃ大変でした。

このときにラズパイが届いたようです。 計画を立ててから実際に導入するまでかなり時間が掛けてしまいました。

それから一年以上、ラズパイ Ceph クラスタと格闘していました。 そんな中で PoE+ HAT を追加するなどのパワーアップがなされていました。

その後、ケーブルの相性問題に辿り着きました。

ラズパイが参戦した結果、自宅ラボも賑わいを見せ始めました（ファンの音が地味にうるさい）。

architecture2

【第三章】Proxmox VE、襲来

しばらくマシン一台で仮想化基盤を運用していると、こんなことを思うことがよくありました。

「メンテしやすくするために冗長化してぇ……」

ごく自然な流れだと思います。

マシンとしてのメンテナンスは言うほど多くなくて、部屋の掃除とか模様替えとか、電源を落として物理的に移動させたい要件がそこそこ発生してました。 仮想化基盤が物理的に冗長化されていてフェイルオーバーしながら掃除できたらとても嬉しいですよね？ 早速、仮想化基盤の冗長化に向けて検討を始めました。

2 台目のマシンにはみんな大好き NUC を選定しました。 冗長化を目的としてはいたものの、最初は 1 台マシンで OpenShift を動かせるという Single Node OpenShift を入れるために使っていました。

NUC で Single Node OpenShift を触ってみよう
NUC で Single Node OpenShift を触ってみよう
Red Hat が提供するエンタープライズなコンテナ・プラットフォーム「OpenShift」がシングルノードに対応したようです。 Meet single node OpenShift: Our newest small OpenShift footprint for edge architectures The cloud native approach to developing and deploying applications is increasingly being adopted in the context of edge computing. However, edge workloads and use cases span a myriad of locations, technical requirements, and physical footprints. そうとなれば試してみたい欲求が抑えられませんよね？ というわけで要件を満たす機器を選定するところから SNO (Single Node OpenShift) を導入してみました。 ハードウェア要件 SNO をインストールするには以下のスペックが必要です。 プロファイル CPU メモリ ストレージ 最低限 8 vCPU コア 32 GB 120 GB 普通(?

一方、ソフトウェア面では大きな課題が発生しました。 それは、当時使っていた VMware ESXi を冗長化するためには vCenter が必要で、vCenter を使うためにはライセンスを支払う必要があったのです。 とてもじゃないけど個人で払えるようなものではありません。

そんなユーザのために VMUG というコミュニティの有償オプション「VMUG Advantage」というものがあり、こちらに登録することで検証用ライセンスを使うことができるのですが、それでも VMUG Advantage の登録には年額 $200 掛かります。

マシンを物理的に購入するならまだしも検証用ライセンスで $200 かぁ、と普段ガバガバな財布の紐を引き締めていると、Proxmox VE というオープンソースの仮想化プラットフォームの存在を知りました。

Proxmox VE を使えば無償で仮想化基盤の冗長化が実現できそうだったので、VMware ESXi から Proxmox VE に移行することを決めました。 当時の仕事で VMware 製品に関われるチャンスが無さそうだったのも Proxmox VE への移行を後押ししました。

仮想化基盤の Proxmox VE への移行
仮想化基盤の Proxmox VE への移行
自宅ラボの仮想化基盤を VMware ESXi から Proxmox VE に移行した。 動機 自宅ラボでは2台の物理マシンに VMware ESXi をインストールして仮想化基盤を構築しているが、VMUG Advantage 会員になることをケチっていたため vMotion を使えない状態だった。 仮想ホストのメンテナンスをしようと思っても VM の停止を許容するしかなかった。 そんな折、オープンソースの Proxmox VE という仮想化プラットフォームの存在を知った。 Proxmox VE であれば無償で仮想化基盤の HA クラスタを組むことができるとのことで、ESXi から Proxmox VE に切り替えることにした。 AWS SAA の勉強をしないといけない現実から目を逸しているだけ。 Proxmox VE とは Proxmox VE (Virtual Environment) は、Debian ベースの仮想化プラットフォームで、KVM による仮想マシン環境と LXC によるコンテナ環境が提供されるらしい。 KVM も LXC も使ったことがないので実際どんなものかは分からない。 複数の物理マシンを用意すれば無償でクラスタを組むことができる（大事になことなので2度言う）点が VMware 製品とは異なり、個人的に大きなメリットと感じた。 また、試せてはないけど Proxmox VE のストレージとして Ceph を構築できるらしい。 物理マシンがもう1台欲しくなっちゃうけど時期が悪すぎる。 Proxmox VE 導入 ESXi から Proxmox VE に VM を移行する。 手順は Proxmox 公式 Wiki の Migration of servers to Proxmox VE を参考にした。

NUC に入れていた Single Node OpenShift も消して Proxmox VE をインストールし、無事に Proxmox VE への移行と 2 台目マシンの導入も完了し、自宅ラボに冗長構成となった仮想化基盤が爆誕しました。

この時点で↓のような見た目になっていました。 小さいながらも立派な自宅ラボになりましたね。

参考程度の構成図。

architecture3

【第四章】自宅ラボ！きみにきめた！

Proxmox VE を使った仮想化基盤とは別に、ラズパイに Ceph を入れて Kubernetes から利用できるストレージを作っていたので、その内容を K8s@home というイベントで LT で発表しました。

このイベントで登壇されていた @yuanying さんがクラスタ構成の基本方針として「できるだけ Kubernetes に載せる」と発表されていて、これを聞いた自分はそのやり方にとても痺れしまい「自分も Kubernetes に載せられるものは載せたい！」という衝動に駆られました。


流されやすい。

当然 Kubernetes クラスタを新しく生やすだけの潤沢な物理資源は自宅ラボには存在しておらず、冗長化したばかりの仮想化基盤を潰して空いたマシンを Kubernetes クラスタの物理ノードとして転生させることにしました。 ちなみにこのタイミングで 3 台目のマシンをお迎えしています。

同時に Kubernetes 用ストレージとして働いていたラズパイ Ceph クラスタも解体し、Kubernetes クラスタのコントロールプレーンとして転生させました。 Ceph はとても好きなのですが、ラズパイを使うとどうしても不安定になってしまうのと、スキル不足故のトラシュー時間の増大に疲弊してしまったので、ラズパイ Ceph クラスタの廃止は必然の流れだったのかも知れません。

仮想化基盤には作業用 VM だったり DNS サーバだったりが載っていたのですが、新しく導入した Mac Mini や NAS の DNS 機能を使ったりと代用先があったため併せて移行しました。

architecture4

というわけで、自宅ラボから仮想化基盤は無くなって、現在は物理マシンのみを使った Kubernetes クラスタが鎮座するのみとなりました。 このクラスタを「盆栽」と呼んで、時間を見つけては選定と言う名の検証やメンテナンスをしている日々です。

3 台目のマシンをお迎えしてワーカー 3 台構成を考えていたのですが、現在の構成はワーカーが 2 台になっています。 一番最初に導入した DeskMini はクラスタに組み込んでおらず遊ばせている状態です。 これは 2 台構成でも十分リソースが足りている使い方をしているのと、DeskMini を録画サーバとして使うことを考えているからです。

録画サーバは最近よくフリーズして録画失敗しちゃってるので、そろそろ腰を据えて環境を整えないと。

2023-11-30 時点でこんな様子。 ケーブル周りがゴチャゴチャしているのはご愛嬌と言うことで……。

homelab

【終章】俺たちの戦いはこれからだ

というわけで、自宅ラボの遍歴について紹介してみました。 本当は Azure や Kubernetes のネタをしたかったんですが、まったくネタが思い浮かばなかったのでアドベントカレンダー初日にも関わらずこんな内容になってしまいました。

自宅ラボは本当によいものです。 実質無料（※1 電気代除く）（※2 導入費用除く）（※3 運用コスト除く）で好きなことを好きなだけできる環境です。

これからも盆栽のように手入れをして、そしてたまに拡張して、大切に扱っていきます。 少しでも興味を持った方は今すぐ自宅ラボを構築してくださいね。