MacBookをLinuxサーバ化

Date:

Share post:

個人持ちPCとしてMacBook Proを使用していますが、現在使用している物は2代目です。1号機は悪名高き「バタフライキーボード」で、ネット情報にある「キーが反応しない」「キーが多重に入力されてしまう」がまんま発生して、耐え切れず昨年(2020年)秋に買い替えました。
1号機もあくまで一部キーの反応に問題があるだけなので外付けキーボードを繋いで使う方法もあるのですが(と言うか実際使う時はそのようにして使ってますが)、ノートPCとしての機動性は失われており、据え置き機としては画面(文字)が小さく老眼には厳しい環境なので今一つ使い続けるメリットを見出せないでいました。ただ、相応の費用を掛けて購入していますし、このまま放置するのは何とももったいない。
と言うことで、Linuxサーバマシンとして使ってみることにしました。

もともと弊社はLinux環境で動作するシステムの開発を生業としており、私のようなバックエンドのエンジニアとしてはVirtualbox/Vagrantを使用してMac上にLinux環境を構築し使用することは日常です。当然ながら開発用PC上には複数の仮想Linuxマシンが載っていますが、相応にメモリを使うため必要に応じて起動停止を行っています。しかし、中には開発チーム共有検証環境として使用している物もあり、このような仮想マシンは簡単に落とせません。こう言った仮想マシンを載せておく専用ハードとして先のMacBookを使用したいと思います。

Virtualbox/Vagrant自体のインストールに関しては「Virtualbox / vagrant のすゝめ」を参照してください。
仮想サーバ環境の構築は適宜。標準的なWebサーバ環境であれば「Webmin / Virtualmin のすヽめ」辺りを参考にしてもらえればと思います。
ここではあくまで個人用開発環境として構築したMacBook上の仮想マシンを共用サーバとして使用するために考慮すべきポイントのみ記述します。

public_network設定

Virtualbox/Vagrantで仮想マシン環境を構築する場合、特に必要がなければ「public_network」の設定は行わないと思います。
ホスト・仮想マシン間および複数の仮想マシン間での通信を検証したい場合でも、同一ホストマシン上に該当する仮想マシン環境を構築し、それらが共通の「private_network」上に存在するように定義すれば相互の通信は確認できます。
しかし今回はホストマシン外からホストマシン上の仮想マシンへのアクセスを可能にしたいので「public_network」の設定が必要になります。

まずは「private_network」の設定と同様にVagrantfileファイル内に以下のような設定を行ってみます。

config.vm.network "public_network", ip: "<IPアドレス>"

IPアドレスに関しては「private_network」ではホストマシン上で独自に決定することができましたが、「public_network」ではLAN上で有効なアドレスを設定する必要があります。既存アドレスと重複しないことは当然ながら、DHCPを使用して動的にIPの割り振りをしている環境ではDHCPが将来的に使用する可能性があるIPも除外すべきです。おそらくは大半のLAN環境で固定IPと動的(DHCP用)IPの使い分けは管理されていると思いますので、未使用固定IPから本用途で使用するIPを割り振ってもらう形になるかと思います。

上記設定を行った上で仮想マシンを起動すると、以下のような表示で入力を求められるかと思います。

==> default: Available bridged network interfaces:
1) en0: Wi-Fi (Wireless)
2) en5: USB Ethernet(?)
3) p2p0
4) awdl0
5) llw0
6) en1: Thunderbolt 1
7) en2: Thunderbolt 2
8) en3: Thunderbolt 3
9) en4: Thunderbolt 4
10) bridge0
==> default: When choosing an interface, it is usually the one that is
==> default: being used to connect to the internet.
==> default: 
    default: Which interface should the network bridge to? 

仮想マシンがホストマシン外のマシンと通信するためにはホストマシンが持つネットワークインタフェースを経由する必要がありますが、どのインタフェースを使用するか聞かれている訳です。MacBookの場合、無線通信に該当する「en0: Wi-Fi (Wireless)」を選択すれば良いので上記問いに対しては「1」と入力すれば良いです。ただ、毎回上記入力を行うのは面倒なので、先のVagrantfile内の「public_network」の設定内容に以下のように追記します。

config.vm.network "public_network", ip: "<IPアドレス>", bridge: "en0: Wi-Fi (Wireless)"

上記のように記述することで次回以降はネットワークインタフェースの入力を必要とせずに仮想マシンが起動するようになります。

仮想マシンが起動したら、sshで指定したIPアドレスに対してログインしてみます。
仮想マシンにはデフォルトでユーザー「vagrant」が生成されており、パスワードも「vagrant」です。

環境によってはそのままアクセスできるかもしれませんが、少なくともCentOS7では以下のように怒られます。

vagrant@<IPアドレス>: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

CentOS7ではデフォルトではパスワードによるsshアクセスを許容しないように設定されているためです。よって、設定を変更してパスワードでのアクセスを可能にします。
ファイル「/etc/ssh/sshd_config」を開いて「PasswordAuthentication」なる項目を探します。デフォルト値は「no」になっていると思いますので、これを「yes」に変更し、以下のコマンドでsshdの再起動を行います。

systemctl restart sshd.service

上記結果ログインできるようになれば「public_network」の設定はOKです。

なお、1台のホストマシン上で複数の仮想マシンを同時運用可能であり、上記で指定する「public_network」のIPアドレスを適切に(重複なく)割り振れば、LAN上の複数のサーバを1台のホストマシンで実現することも可能です。ただし、仮想環境としてのオーバーヘッドはありますし、ホストマシンの各種リソースを共存する仮想マシンで共用することになりますので相互に影響を与える状態になっています。それらを考慮した運用が必要です。

スリープの抑止

public_networkの設定ができてしまえば当該仮想マシンへのホストマシン外からのアクセスができるようになりますが、MacBookをホストマシンとしてサーバ運用する場合はもうひと工夫必要です。
MacBookの場合、蓋(ディスプレイ)を閉じると自動的にスリープ状態になりますが、この時仮想マシンも停止されてしまいます。蓋を開けたまま放置でも良いのですが、スペース的には蓋を閉じた「小型&薄型ブレードサーバ」形態として運用できた方が良いです。
この点を解決すべく「システム環境設定」の「省エネルギー」辺りの設定を操作してみましたが、意外にダメでした(少なくとも個人的には成功パターンを発見できていません)。よって、バックエンドエンジニアらしくコマンドで解決します。

Macのターミナルで以下のように実行します。

sudo pmset -a disablesleep 1

これで蓋を閉じてもスリープ状態にならなくなります。他の目的含めて蓋を閉じた状態で何らかのアプリを実行したままの状態にしたい場合には有効です。

ただ、そもそも蓋を閉じただけでスリープ状態になることはノートPCのようにバッテリー駆動を想定したハードの場合は省エネルギー的にかなり有効&重要な機能であり、これを抑止することはバッテリー切れのリスクを増大させることになります。今回はあくまでMacBookを据え置き機として使用することが目的であり、電源つなぎっぱなし前提なので基本的には問題ないですが、他の用途でTypeCのACアダプターが使いたくなった場合などについMacBook用の物をそちらの目的で使用し元に戻すのを忘れてたと言うこともありがちなので、今後はそのようなことがないよう今まで以上に注意が必要だと思ってます。

なお、スリープを再度有効にするためには以下を実行します。

sudo pmset -a disablesleep 0

蛇足ながら

今回はMacBookをLinuxサーバ機として使用することを考えましたが、実は積極的に使用していないMac mini(通称「弁当箱」)も2台あって、最初はそちらの方をサーバ機にと考えました。ただ、OSが古すぎてVirtualboxのインストール自体ができなかったので諦めましたが。
Mac miniであれば蓋を閉じた場合のスリープに関する心配も不要ですし、ハードの形状的にも据え置きサーバ向きです。

ただ、社内サーバの運用を行っていると稀にサーバ自体を直接(ネット経由でなく)操作したい状況が発生したりします。普段は不要と言うことでディスプレイやマウス・キーボードを接続していないと改めてそれらの確保から必要となり、それが面倒だったり、緊急対応が必要な場合の支障になったりします。
その点ノートPCであれば単体で必要なハードが一式揃っているのでそのような心配がありませんし、その上で閉じておけばそれら一式がかなりコンパクトな状態で保持しておけます。

また、サーバの用途によってはUPS(無停電電源装置)などの導入も考える必要が出てきますが、ノートPCであれば当然ながらバッテリー装備なので多少の停電は全く問題になりません。弊社の場合、ビルのメンテナンス等の理由でたまに(平均で年1回くらいか?)1時間程度の停電が発生したりしますが、その際にサーバが再起動できていなかったり、一部アプリが正常に動作していなかったりと言ったトラブルが発生したりします(あくまで社内利用に限定した使用なので被害は限定的ですが)。
ノートPCをサーバに使用することで通電時に安全にサーバが再利用可能になることが高い確率で保証されますが、これはサーバメンテナンス的にはかなり嬉しいことです。

加えて災害時などにはサーバを緊急に(電源ケーブルを取り外すくらいで)持ち出すことも可能です…が、実際の災害時にはそこまで頭が回らないでしょうね。

最初からサーバ運用を目的としてノートPCを購入することはコストパフォーマンス等から有り得ないと思いますが、スペック的な理由でノートPCを買い替えた際などに旧マシンの勇退先としてサーバ(仮想サーバのホストマシン)と言う選択は意外に正解かと思っています。

Related articles

EC-CUBE 4系のプラグイン開発について その...

前回、プラグインを一旦有効化させて管理...

EC-CUBE 4系のプラグイン開発について その...

以前から作成したいと考えていたのですが...

Laravel Filamentを使用した管理画面...

前回Breezeをインストールしたこと...

Laravel Filamentを使用した管理画面...

前回、filamentでのリソース作成...