aws, ubuntu, wordpress

Amazon EC2のubuntu14.04(WordPress Bitnamiインスタンス)を18.04にアップグレードする

アップグレードするための方法というよりは、試したことのログなので、手順ではありません。最終的にアップグレードできましたが、いろいろ回り道しています。本当は20.04までアップグレードしたかったのですが、諸事情により18.04に落ち着きました。

大まかな手順は最後のまとめに書いておきました。

このブログを動かしているサーバーのPHPが7.0だったから7.4にアップデートしようと思ったときにOSバージョンを確認してみたら、ubuntu14.04になっていてびっくりしたから、まずOSをアップデートすることにしました。
(結局OSアップグレードして終わったので、PHPは7.0のまま、、)

バックアップを取る

まずバックアップを取ります。インススタンスのコピーを作っておくというのでも良いと思いますが、AWS Backupというのを見つけたので使って見ました。

AWS Backupについての詳細な日本語解説(公式)

この記事がわかりやすいです。EC2 のまるごとバックアップを AWS Backup がサポートしたので早速試してみました

バックアッププランの作成

  1. Start with a templateを選ぶ
  2. 一番シンプルそうな”Daily-35day-Retention”を選ぶ
  3. プラン名を適当に設定
  4. バックアップルールはデフォルトでDailyしかなかったから毎週木曜日にバックアップを取るルールを作成
    • Expireを1ヶ月後に設定
    • それ以外はデフォルト設定
  5. これでプラン作成

リソースをアサイン

  1. 名前を適当に設定
  2. IAM Roleはデフォルト
  3. Resource ID -> EC2 -> インスタンスIDを選択
  4. リソースをアサイン

という感じでバックアッププランを作成してインスタンスを紐付けたが、これだと今すぐバックアップはしてくれないことに気づく。。(当たり前ですね)

そこで、上記のQiita記事のようにオンデマンドバックアップもやることに、、
しかも、オンデマンドでもバックアップジョブを作ってから1時間後に開始されることが判明。
結局、即時バックアップはできないみたい。(もしかしたらオンデマンドの設定のどこかに合ったのかな??)即時でやりたいなら、自分でAMIをコピーするとかですかね。

アップグレードする

ubuntuにはdo-release-upgradeというコマンドがあるのでこれでアップグレードします。Descriptionを見ると、

  • GUI環境がないこと
  • リモート接続を通じてアップグレードされる

の場合に推奨される方法のようです。今回はSSH接続でアップグレードするので条件に合っています。

具体的な手順はUbuntuのアップグレードのやり方に丁寧に書いてあります。

実際にやった手順

$ sudo apt install update-manager-core
$ sudo apt update
$ sudo do-release-upgrade

do-release-upgradeを実行すると、以下のような確認メッセージが出てきました。

Continue running under SSH?

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?

コマンド説明に書かれていた “if the machine is to be upgraded over a remote connection” というのは、別に推奨というわけではなく、「このコマンドでアップグレードするしかないよね」的な意味だったようですね。で、上記メッセージによると「失敗したらリカバーできないから辞めた方が良いよ」とのことですが、すでにバックアップを取っているのでこのままやってみます。

yを入力して進めるとさらに以下のメッセージが出てきます。

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running
ssh you can still connect to the additional one.
If you run a firewall, you may need to temporarily open this port. As
this is potentially dangerous it's not done automatically. You can
open the port with e.g.:
'iptables -I INPUT -p tcp --dport 1022 -j ACCEPT'

「何かあったら1022ポートでもSSHできるようにするけど、ファイアウォール開けておいてね」とのことです。macOSの場合は、macOS – ファイアウォールをオン/オフ(有効/無効)にするのようにシステム環境設定でファイアウォール設定ができます。

あとは、インストール中に設定ファイルを更新するかどうか(ユーザーにより変更されていた場合)を聞かれますが、大体yesにして進めたら、アップグレード完了しました。で、再起動したらその後ちゃんとSSH接続できてめでたしめでたしのはずだったのですが、OSバージョンを確認してみたら、16.04でした。。まあ考えてみれば当たり前なのかもしれませんが、なんとなくdo-release-upgradeがうまいこと14.04から20.04(というか現在の最新版)にアップグレードしてくれるのかと思っていたけど違ったみたいです。

というわけでもう1回do-release-upgradeして18.04にアップグレードしました。これだったら初めから、新しいインスタンスを立ててそちらに移行する方が良かったかもしれません。

18.04へのアップグレードの時は、sshd_configファイルの更新について聞かれたから、これは更新前のファイルをそのまま使うようにしました。パスワードログインoffとか、公開鍵ログインonとかの設定が変わってしまうためです。

アップグレード完了して再起動後、SSHが繋がらなくなりました。

ssh: connect to host xx.xx.xx.xx port 22: Connection refused

となってしまいます。ちなみにブログはちゃんと見れるし、AWSのコンソールで見ても正常に動いているので、何かSSH関連で問題が起きているようです。もうこのインスタンスのSSH接続を復旧する術はないんじゃないかと諦めかけましたが、調べてみると対処法はありました。

まずは後者のサイトに書かれているAWS systems managerというのを試してみることにしました。

  1. 必要なポリシーとIAMロールを作成してインスタンスに紐付ける
  2. Systems Manager –> Sesstion Managerを開始

でセッションマネージャー経由で操作できるはずだったのですがやってみても繋がりません。元々このインスタンスを作ったのが2017年ごろだったため、そもそもSSMエージェントがインストールされていないようでした。
Ubuntu Server インスタンスに SSM エージェント を手動でインストールする

仕方ないので、一旦バックアップ(14.04)を復元し、16.04までアップグレードしてこのときに↑の手順に従ってSSMエージェントをインストールしてSession Managerを開始できることを確かめてからまたバックアップを取りました。これで16.04のバックアップが取れました。ちなみに、Session Managerでセッションに入るとBashが使えるのですが、safariではなぜかエンターキーしか入力できませんでした。chromeだとちゃんと入力・実行できました。

その後再度、16.04から18.04へのアップグレードを実行しました。設定ファイル上書き確認については全てyesを選択しました。完了後すぐに再起動せずに、

  • sshd_configの設定を確認して、PubkeyAuthentication yesとなっていることを確認
  • sudo systemctl status sshdでenableになっていることを確認
  • sudo ufw allow sshを念のため実行

をやった後に再起動しました。するとめでたくSSH接続できて、cat /etc/os-releaseでバージョン確認すると18.04になっていました。もう疲れたのでこれで良いことにして終わりました。問題なくアップグレードできれば良かったのですが、結局バックアップ復元で別のインスタンスを立てたので、その後固定IPの設定とSSL証明書発行をやり直さなければいけなくなりました。。

bitnamiインスタンスだったため、以前どういう風にssl設定したか覚えてませんが、letsencryptのcertbotで簡単にセットアップというわけにはいかず、いろいろ調べてたどり着いたのがこのサイトの手順で、ここの通りに手動設定したらようやくできました。

まとめ

一応まとめておくと、

  1. AWS Systems ManagerでSession Managerを使えるようにしておく
  2. バックアップを取る
  3. do-release-upgrade
  4. すぐに再起動せずにssh設定等を確認する
  5. 再起動
  6. めでたしめでたし

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です