このサーバのOSをstretchからbusterにアップグレードした

2019.08.15

Debianのアップグレードをしたい

1年半以上ブログを放置してて、何を話題にすべきかすら忘れかけちゃってるけど、本来はサーバ運用記録的であるべきとは思ってるので、少なくとも大きな変更を行った時は書いておかねば。
このサーバはさくらのVPS上にホストされていて、Debian 9 ‘stretch’で動いていました。主要なサービスとしては、Apache+PHP-FPMによるWordPressと、Postfix+Dovecotによる自家用メールの運用。
で、この度Debian 10 ‘buster’がリリースされました。stretchのままでもLTSは2022年6月まであるので、適切にアップデートしていれば（パッケージもWordPressもちゃんと適宜アップデートだけは続けてますけど）そのままでもいいんですが、いくつかの動機づけがありOSのアップグレードを行うことにしました。具体的には

  • TLS 1.3への対応
  • Apacheを捨ててnginxへ移行

という2点。元々自己満足のサーバではあるのと、仕事上の個人的な検証という側面もあるので、最新のテクノロジーは追っておきたいというのもあるし、WordPressのサイト運用もいくつかしてるんですが、もうApacheで動かしてるのがなくなっちゃってるのでこれもnginxにしておいた方が何かと面白みがあるかなというわけです。

さてどうやってアップグレードするか

公式の手順をまず参照します。sources.listを書き換えるだけでサクッとアップグレードできちゃうのはDebianのいいところではあります。ただ今回は少なくとも主要なミドルウェアを入れ替えるという野望もあり、変な残骸が残らない方がいいかなと思ったので、新規インストールのアプローチを採ります。
シンプルに行けば

  • 新環境（新規のさくらのVPSとか）にDebian 10をセットアップ
  • 各種ミドルウェアの環境を構築
  • WordPressのコンテンツやDB、メールのデータなどを移植
  • DNSを切り替えて、Webのリクエストやメールが新環境に流れるようになる
  • 完全に新環境に流れるようになったら現環境を停止・解約

という流れでいけます。ただしこのさくらのVPSが年払いの契約になっていて、運悪く6月に更新されたばっかりなのでいくらなんでも1万円近くを無駄にするのはもったいない。なのでちょっと軌道修正して

  • 仮環境（さくらのクラウド）にDebian 10をセットアップ
  • 各種ミドルウェアの環境を構築
  • WordPressのコンテンツやDB、メールのデータなどを移植
  • DNSを切り替えて、Webのリクエストやメールが仮環境に流れるようになる
  • 仮環境に流れるようになったら、現環境の初期化とDebian 10のセットアップ
  • 仮環境の設定を移植
  • 改めてWordPressのコンテンツやDB、メールのデータなどを移植
  • DNSを切り替えるというか元に戻して、Webのリクエストやメールが仮環境から新環境に流れるようになる
  • 完全に新環境に流れるようになったら、仮環境を停止

という一時的な仮設サーバを用意して、その隙にOSを入れ替えるという方向性に定めます。
仮環境をさくらのVPSの体験版枠で頑張ってもいいんですが、メールを出せないという制限があるので動作確認にやや支障があるのと、さくらインターネットさんに忍びないというのがあったので、わずかな金額ではありますがさくらのクラウドに課金することにします。

いざアップグレード作業

といってもそんなにややこしいことはしていなくて、手元の仮想環境などで検証をしたところ

  • Postfix：設定ファイルそのまま
  • Dovecot：ほぼそのまま、一部修正（ssl_client_ca_dirを指定しないとダメだった）
  • MySQL(MariaDB)：デフォルトのままいじってなかった
  • PHP：デフォルトのままいじってなかった
  • nginx：これだけApacheの設定を読み替えながら設定しないとダメ
  • nftables：今までのiptablesの設定を変換

という具合でした。nginxの設定も特段特別なことはしていなくて、「nginxでWordPressを動かす」的なリファレンスほぼそのままです。何かの折に気が向いたら書こう。
で、これらの設定やOSの基礎的な設定部分を一気に設定するAnsibleスクリプトを書きます。仮環境も新環境も同じAnsibleのスクリプトを流すことになるので、その2つに差は出ません。自ホストのIPアドレスが設定される箇所くらいですね。

ホームディレクトリにいくつかスクリプトと、ある意味最も重要な資産であるMaildirの中身がありますが、これはSSHの鍵を通してrsyncしてしまうだけです。他にMySQLの中身は一応ダンプ＆リストアで移植、SSL証明書周りは/etc/letsencryptと/etc/ssl以下のcerts以外のディレクトリをまるごと移植してしまいます。さらにcron.dの下など必要な箇所を移植していく感じ。

で、DNSのAレコードを一時的に仮サーバの方に向けてTTLに設定してある程度の時間待ちます。間違えて元々のサーバの方に着弾したメールは個別にSCPして処置します。ユーザ多かったりすれば気を使った処置をしないといけないんですが、まあ実質ユーザ一人なんであまり細かい気遣いはしてません。徐々に自然とメールが仮サーバの方に流れてくるようになりますので、完全に切り替わったと判断できれば元々のサーバの方を初期化してDebian 10で再インストールします。さくらのVPSさんは光の速さでDebian 10のイメージが提供されているので、インストール自体に難しいことは何もありませんでした。
新環境にOSがインストールされたら同じAnsibleのスクリプトを流して環境を整えます。さらにさっきコピーしたホームディレクトリやMySQLのダンプなどを新サーバに持ってきてサービスを起動すればほぼ完了。DNSの設定を元に戻して、再び新サーバの方にメールやWebのトラフィックが流れてきます。
改めて流れが完全に切り替わったら仮サーバの方は停止してしまいます。ちょっと気合いは必要ですが、仮サーバの稼働時間は4時間ほどでした。

何か変わったことあるのか

うーん、どうなんでしょ？
Webのレスポンスはちょっと早くなったような気はしますが、正確なベンチマークを取ったわけではないのでなんとも言えないところです。パフォーマンス面もセキュリティ面も含めてまだあまりチューニングしてなくて、とりあえず動くレベルではあるので、もうちょっとなんとかしたいところ。
TLS1.3も見た目上の違いはないかなぁ、当たり前だけど。主要なブラウザはTLS1.3に対応しているはずなんでそれでアクセスしてくれるクライアントはそこそこ多いはずなんですが、バージョンをログに出すようにしてなかったからわからんし。メールの方はログに出たりヘッダに出たりするけど、TLS1.3で送ってきてくれるのってGoogleくらいしかなくて、主要なメルマガ系サービスとかAmazonですらTLS1.2だもんなぁ。まあ今回これでDebianが対応して、来年春にはUbuntuが対応して、さらにRedHat(CentOS)とAmazon Linuxが対応すれば普及率としては大きく増えるのかも。

あとは個人的で何の利害もないサーバだからこそ勢いで作業に着手しないといつまでたってもやらないって問題はありつつ、勢いでやると細かい突貫調整が出たりするのはよくなかったかなぁ。仕事だったらちゃんとチェック体制とか敷くけどそうもいかんし、かといって手間と時間をかけすぎるのもねぇという悩ましいところ。

コメント

タイトルとURLをコピーしました