西川和久の不定期コラム

10年以上前に契約したVPSから全サイトをNUCに引っ越し!Ubuntu 20.04 LTS + Hestia@Hyper-Vに新サーバー構築

 筆者が個人的に管理しているサイトは5つ。アクセスもほとんどないため長年放置していたが、契約しているVPS上のLinuxがCentOS 5と古過ぎることもあり、正月休み+αを使って全サイトをHyper-V上に構築した新サーバーに引越した。今回はその内容をご紹介したい。

もともとのサーバーはServersMan@VPSでCentOS 5

 長年放置していたサーバーは、ServersMan@VPS上のCentOS 5。確か昔記事を書いたような…と、本連載のバックナンバーを探したところ発見!2010年8月の「個人/小規模用のネットサーバーにPCはもう不要!?」。詳細はここにあるので興味のある人は見てほしいが、環境的には

1)ServersMan@VPS Standardプラン(当初メモリ512MB、ストレージ30GB、980円/月)
2)CentOS 5.4/32bit + BlueOnyx(コンパネ)

という感じだ。現在はメモリ2GB、ストレージ100GBになっている(934円/月+税)。リソース的には小規模ならOKだが、問題はOS。CentOS 5/32bitはさすがに古過ぎる(笑)。

 余談になるがコンパネ(Webサイトやメール設定などをWebベースで行なえるツール)のBlueOnyxは、その昔、Sun CobaltというサーバーPC(RaQ 550やQubeが有名。Qubeは所有していたこともある)に搭載していたものを切り出しCentOSベースで公開したものだ。

BlueOnyx / ネットワークサービス
BlueOnyx / サイトの管理

 この手の設定はやればできるが、sshで手作業だと何かと面倒なので、コンパネがあれば便利。有名どころだとPleskだろうか(ただし商用)。当時はこのBlueOnyxを好んで使っていたという経緯もある。

 OSが古いのは契約した時期が関係しており、現在はCentOS 7(64bit)または8(32bit/64bit)をインストール可能になっている。ただ少し前にご紹介したMIRACLE LINUX 8.4で書いたが8系はすでに終了しているため、実際はCentOS 7の一択となる。

 いずれにしてもOSをアップデートするには、VPSのOSをいったん削除、再インストールすればCentOS 7(64bit)になるので、それでもよかったが、どのみち一旦バックアップして、ローカル環境で確認、VPSのOSをCentOS 5から7へ、環境再設定……となるため「それならローカル環境をそのまま外部に出してしまえば」と思ったのが今回の発想だ。

 幸い、仕事場の光回線は固定IPアドレスなので、ルーターのDMZを使えば簡単にサーバーを外へ出すことができる(一般的な可変IPアドレスの場合はDDNSを使う手もある)。

 そうなるとマシン選びだ。いくらアクセスがほとんどないとは言え、できれば24時間365日動作している方がいいし、省電力なものが望ましい。手元で使っているマシンを見渡すと該当するのは以前ご紹介した「NUC10i5FNH」が良さそう。現在Windows 10で使用中だが、メモリ32GB、SSD 512GBなのでリソース的にも余裕があり、加えてM1 Mac miniへメインの座を奪われサブマシンになっており(接続もRemote Desktop)、これを活用することにした。

その1 - VMware Workstation PlayerにUbuntu 18.04 LTS + Vesta Control Panelをインストール

 Windows上でLinuxを動かす方法は、WSLかHyper-VやVMware Workstation Playerなど仮想マシンなどが挙げられる。今回は何も考えずにVMware Workstation Playerを使うことにした。

 先に結論を書いておくと、これは失敗。と言うのも、Windowsから見ればVMware Workstation Playerはアプリの一種なので、Windowsを再起動した場合、手動で起動する必要がある(batファイルでスタートアップに登録すればできるにはできるが)。対してHyper-Vはサービス。Windowsが起動すれば自動的に起動するため、こっちにしておけば良かった……と後悔。後述する2度引越したのもこれが原因の1つだ。もし、同様の環境を構築するならHyper-Vへインストールすることをおすすめしたい。

 Hyper-Vだと、仮想マシン名の上で右クリック > 設定で“自動開始アクション”を選択、「常にこの仮想マシンを自動的に起動する」とするとWindows起動時に仮想マシンも自動起動する(シャットダウンも自動)。

 OSは先に書いたように、もともとがCent OSなので、Cent OSとなるところだが、今回はUbuntu 18.04 LTSとした。ちょっと古いがこれには理由があり、後述するコンパネ=Vesta Control Panelが対応しているバージョンの関係だ。

 EOLはCentOS 7が2024年6月末、Ubuntu 18.04 LTSは2023年4月(延長メンテナンス2028年4月)までと、延長メンテナンスを含めるとしばらくは大丈夫。あまり長過ぎるとまた長期間放置しそうなので、ちょうどいいという話もある。

 コンパネは色々試したところVesta Control Panelが一番イメージに近かったのでこれを使用した。対応OSは、RHEL/CentOS 5/6/7、Debian 7/8/9、Ubuntu 12.04-18.04。この関係でUbuntu 18.04 LTSとなっている。インストールは

$ sudo su
# curl -O http://vestacp.com/pub/vst-install.sh
# bash vst-install.sh

たったこれだけと超簡単だ。

 機能は豊富で、FIREWALL(iptables、fail2ban)、DNS(Named)、WEB(NGINX + Apache、NGINX + php-fpm、Apache)、MAIL(SpamAssasin、ClamAV、Dovecot、Exim)、DATABASE(MySQL + phpMyAdmin、PostgreSQL + phpPgAdmin)、FTP(VsFTPD、ProFTPD)、BACKUP、CRON……これだけのものが先のコマンド一発で入り、Webベースのコンパネが利用できる。SSL接続に必要なLet's Encryptの証明書もチェックすれば自動的にインストール/更新される。対応言語は日本語も含まれるが、英語(en)のまま使った方がスッキリしていて吉。

VESTA / USER
VESTA / WEB
VESTA / DB
VESTA / Graphs

 これでコンパネの準備が整ったので、あとはWebサイトの追加を行ない、該当フォルダへファイルをコピー、WordpresはDBを旧サイトからdumpをexportして新サイトへimportすることになる。

 なお先にDNSを新サイトへ切り替えてしまうと、移行が終わってないサイトが表示されるため、作業するマシンの/etc/hostsに追記して作業を行なうことになる。WindowsはC:\Windows\System32\drivers\etc\hosts、macOSは/private/etc/hosts。いずれも管理者権限での編集が必要だ。例えばこんな感じで追記すれば、Webブラウザにwww.aaa.jpと入れると、この/etc/hostsを触ったマシンだけIPアドレス123.456.789.1を引くようになる(DNSのAレコード相当)。

/etc/hosts
# 新サーバーのIPアドレス ドメイン
123.456.789.1   www.aaa.jp

Wordpress Tips

 管理しているサイト5つ中、3つがWordpress、1つは開発時の外部とのやり取り用、1つが一番古くPerlなどを使ったサイトだ。後者は基本ファイルのコピーだけでいいが、WordpressはDBのコピーも必要となる。標準的な使い方なら全ファイルコピーする必要はなく、/wp-content/ 下のみでよい。筆者のケースでは以下の感じだろうか。新サーバーの該当フォルダへ移動し

$ wget https://ja.wordpress.org/latest-ja.tar.gz
$ tar zxvf latest-ja.tar.gz
$ mv wordpress wp
$ cd wp
$ cp wp-config-sample.php wp-config.php
$ vi wp-config.php
※dbの設定などを編集
$ cd ..
$ cp ./wp/index.php ./
$ vi index.php
※/wp-blog-header.phpを/wp/wp-blog-header.phpへ

 そして先にバックアップした/wp/wp-content/*を新しくできた/wp/wp-content/へftpなどを使い転送。DBはmysqlコマンドやphpMyAdminを使い該当DBへimportする。

 これでサイトのurlが例えばhttps://www.aaa.jpのまままったく同じであればhttps://www.aaa.jp/wp/wp-adminでログインパネルが出て、これまで通り操作可能となる。テーマやプラグインの更新もこの時行なう。

 ただ旧サイトがhttp://で、新サイトをhttps://化したり(今回がこれに相当)、https://www.aaa.jp/blog/などパスが変わる時は、ログイン前にDBの内容を更新する必要がある。

 色々方法はあるが、Search-Replace-DBを使うのが楽だ。

 ダウンロードして解凍するとSearch-Replace-DB-4.1.2フォルダができるので、サイトへコピー(例えば/フォルダ)。Webブラウザでサイトurl/Search-Replace-DB-4.1.2へアクセスすると以下のようなパネルが表示される。入力するのは例えばhttp://からhttps://への変更であればこんな感じだ。

replace http://www.aaa.jp with https://www.aaa.jp

 通常、hostはlocalhost、portは3306。DBのDB名、ユーザー名そしてパスワード入力後、[test connection]で接続確認。これで準備ができたので[Do a safe test run]でどのテーブルが該当して何件あるのか確認(DBは更新しない)。Cells changeの数字が置き換わる数となる。これを見ると記事が入っているwp_posts以外にも該当するテーブルがあるのが分かる。

 1件でもあれば(できればDBのバックアップ後)、[Search and Replace]ボタンで更新を行なう。これで作業完了。実際にサイトで表示を確認する。

Search-Replace-DB / SearchReplaceパネルで各項目を設定。http://からhttps://へ
Search-Replace-DB / [Do a safe test run](DBは更新しない)で確認後、[Search and Replace]でDBを更新。今回は計54書き変わる

 仕上げは何度もこのパネルを使うわけでもなく、セキュリティ上の問題もあるので、Search-Replace-DB-4.1.2フォルダごと削除すること。

 もう2つ、Wordpressの古めのVersionから最近のVersionへ移行するとサイドバーのウェジットが編集できなくなる(非互換とのこと)。この時はClassic WidgetsプラグインをインストールすればOKだ(新エディタが使いにくい時はClassic Editorプラグインも)。

 別件として少しマニアックになるが、WordpressはREST APIを持っており、例えばWebブラウザで“サイトurl/wp-json/wp/v2/posts/123”とすると、記事ID:123の内容がjson形式で戻ってくる(セキュリティ上オフにしているサイトもある)。管理している1つのサイトではこれを使っており、Wordpress本来のテーマとは異なったUIで表示している。

 以前から課題だったのが、表示している記事の前後の記事情報を得ること。ここにAPIの仕様があるものの、該当するAPIがない。仕様の範囲で対応するには、事前に全記事データを配列に読み込むことになるが、これは処理や反応が重くて非現実的。どうしたものかと思っていたところ、仕様を拡張するという荒技(?)があった。

 方法は使用中のテーマにあるfunctions.phpに以下のコードを追加。たったこれだけだ。

add_filter('rest_prepare_post', function($res, $post, $req) {
if ($req->get_param('id') == null )
return $res;
global $post;
// 1つ前.
$next = get_adjacent_post(false, '', false);
// 1つ後
$prev = get_adjacent_post(false, '', true);
// 前後のIDとタイトルだけ追加する。ない時はnull
$res->data['next'] = (is_a($next, 'WP_Post')) ? array("id" => $next->ID, "title" => $next->post_title) : null;
$res->data['previous'] = (is_a($prev, 'WP_Post')) ? array("id" => $prev->ID, "title" => $prev->post_title) : null;
return $res;
}, 10, 3);

これにより先の/wp-json/wp/v2/posts/123を呼ぶと

 'next' =>
  array (
    'id' => 125,
    'title' => 'next title',
  ),
  'previous' =>
  array (
    'id' => 111,
    'title' => 'previous title',
  ),

 が追加される。記事IDとタイトルがわかればリンクを貼ることができ、その後の処理も楽。こうしてこの問題は一件落着となった。

その2 - 2回目の引越し / Hyper-V + Ubuntu 20.04 LTS + Hestia Control Panel

 本来であればここで作業完了となるが、やはり惜しむべきはVMware + Ubuntu 18.04 LTSだったこと。Hyper-Vへもう一度入れようか……などと思ってながら色々検索していると、Vesta Control PanelからforkしたHestia Control Panelを発見。こちらはRHEL/CentOSは非対応だが、Ubuntu 20.04 LTSに対応している。これならEOLは2025年4月(延長メンテナンス2030年4月)と安心。気になるとずっと気になっている性分なので、ここは気合を入れて2回目の引越しを行なうことにした。

 Vesta Control Panelからforkしているだけあってよく似ており、インストールもコマンド1発。デモサイトで実際コンパネを使えるので興味のある人は試してほしい。後発だけあってDarkモードでデザインもシンプルになっている。

 インストール手順は、Hyper-Vの“セキュアブートを有効にする”のチェックを外してあらかじめダウンロードしていたUbuntu 20.04 LTS Serverのisoイメージを指定、設定の編集から[仮想スイッチマネージャー]を”外部”にし新しい仮想スイッチを作成、これをOSへ接続するようにする。VMwareのネットワーク/ブリッジと同じ感じの設定と言えば分かりやすいだろうか。

Hyper-V / 新しい仮想スイッチ。外部ネットワークへ
Hyper-V / Ubuntu 20.04 LTS Server起動

 無事インストール後、sudo apt update、sudo apt upgradeを行ない、次にHestia Control Panelのインストール。

$ wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
$ sudo su
# bash hst-install.sh
Hestia / bash hst-install.shを起動したとところ
Hestia / インストール終了。管理画面のurl、Username、Passwordをメモする

 後はメッセージに従って進み、終わると

Congratulations!

You have successfully installed Hestia Control Panel on your server.

Ready to get started? Log in using the following credentials:

    Admin URL:  https://192.168.11.202:8083
    Username:   admin
    Password:   xxxxxxxxxxxxxxxxxx

と出るのでurlとユーザー名/パスワードをメモっておく。OS再起動でHestia Control Panelを搭載したUbuntu 20.04 LTSになっている。ただしWebブラウザでアクセスする時、この状態ではsslがNET::ERR_CERT_INVALIDなので、Chromeの場合はthiisunsafeと入力してアクセスする。

Hestia / ログインパネル
Hestia / USERS
Hestia / WEB(NGINX + Apache)
Hestia / DB(MySQL/MariaDB + phpMyAdmin、PostgreSQL + phpPgAdminが利用できる)

 一通り触ったが、Vesta Control Panelで使っている部分はHestia Control Panelにもあるので、ファイルとDBを移せば行けそうだ。一点、そのままだとphpが8系になっている。8系は色々あるので、出来れば7系にしたいところ。

 これも解決方法があり、右上の歯車アイコン > Configure(Server) > Web Serverで、php-5.6/7.0/7.1/7.2/7.3/7.4/8.0(default)/8.1をインストールできる。必要なのをチェックして[Save]、Webの編集、Advanced Option > Backend Template(PHP-FPM)でサイトで使用するphpを選べば良い。これはVesta Control Panelにはない機能でなかなか便利。開発用としてもバッチリだ。

Hestia / Configure Serverで複数versionのphpをインストールできる
Hestia / WEBの設定でインストールしたphpのversionが選べる
Hestia / Statistics。状態表示。使用中のストレージはたった8GBほど
Hestia / Web Mailも標準装備

 メールサーバー(DKIM、SSL、spamassassin対応)は、アカウントの設定などはもちろん、Web Mailにも対応。送受信を試したところ、Gmail的でなかなかよくできている。画面キャプチャはDarkモードだがLightモードにも切り替え可能だ。

 サイトの動作確認後、DNSを新サーバーへ切り替え、/etc/hostsの記述を外し、ルーターのDMZをセット。これで作業完了だ。以上をすでにネットへ公開済み。執筆時点で数日経っているが、安定して動作しており、Windowsのリソースも余裕がある。ストレージはOS込みで約30GB使用。これまでちょい使いの時はVMwareだったが、この手の環境だとHyper-Vの方が便利そうだ。BIOS/Windows Update時にサイトは止まるが、冒頭に書いたようにアクセスも少ないのでこの点は良しとする。

 最後に余談になるが、Raspberry PiでもUbuntu Server 20.04.3 LTSが動作する 。これにHestia Control Panelを入れるのもおもしろそうだ。Raspberry Pi 4/4GBでそこそこ行けるだろうし、何よりWindows Updateがない(笑)。


 今回はVPSにあるサーバーからWindows上のVMwareを経てHyper-Vに構築したLinuxでWebサーバーなどを上げ引っ越す体験談をご紹介した。

 昨今1,000円未満で結構なサーバーを借りれることもあり、この手の環境をわざわざWindows上に構築するのは実用面としては微妙だが、そこは趣味の世界。一銭もかからない楽しみ方の1つと思っていただければ幸いだ。