手順そのものは Ubuntu 20.04 LTS を 22.04 LTS にアップグレードする と同じなのでこちらを参照。
とても分かりやすい記事で非常に助かりました。
本当にざっくり手順だけ書いておくと以下。
# アップグレード可能なバージョンの確認
$ sudo do-release-upgrade -c
# 利用可能な apt パッケージの一覧を更新
$ sudo apt update
# apt パッケージの更新
$ sudo apt upgrade
# 不要パッケージとキャッシュの削除
$ sudo apt autoremove -y
$ sudo apt autoclean -y
# Ubuntu のアップグレード
$ do-release-upgrade以降はアップグレード前後でやっておくと良いことのメモ。
ssh接続セッションのタイムアウトを伸ばす
本来であれば各種ホスティングサービスが提供している（であろう）コンソールから、直接サーバに接続してアップグレード作業をするのが望ましい。しかし、コンソールが使えないタイプのEC2インスタンスとかだと ssh せざるを得ない。
その場合、mac のターミナルは ssh 接続中に放置していると割と早い段階でセッションが切れてしまうので、ローカルの ~/.ssh/config に以下を書いておく。
~.ssh/config
ServerAliveInterval 60
TCPKeepAlive yesまた、リモートサーバ側の /etc/ssh/sshd_config には以下を書いておく。
/etc/ssh/sshd_config
ClientAliveInterval 60
ClientAliveCountMax 120- 60秒毎に接続確認のパケットを投げる
- 120回接続確認に失敗したらセッションを終了（60秒 * 120回 = 2時間セッション維持）
設定後は /usr/sbin/sshd -t で設定ファイルの不備が無いことを確認する（何も出力されなければOK）。問題なければ service sshd restart しておく。
Ubuntu アップグレード中にセッションが切れると復旧不可能になることがあるので、この設定は確実に入れておいたほうがよい。
アップグレード中はこういう画面や Yes / No の対話待ちが頻発するので、このタイミングでググったりしているとセッションを放置することが結構ある。
実際に、複数のサーバでアップグレード作業をしていてセッション切れが原因で壊れたケースがあった（壊れた EBS をデタッチ後、事前にバックアップしておいた EBS のスナップショットをアタッチすれば復旧はできた）。
開発環境でのアップグレード検証時の流れをメモしておく
いきなり本番環境でアップグレードするのはさすがに厳しいので、開発環境で事前にアップグレードの検証を行う。当然のことではあるが忘れずにやっておきたい。各手順ごとに発生したエラーをメモしておいたり、ミドルウェア関連のバージョンとかも必ずメモしておく。例えば以下のような感じ。
# 更新前／更新後バージョン
Ubuntu: 18.04.3 LTS / 20.04.6 LTS
mysql: 8.0.17 / 8.0.33
nginx: 1.15.8 / 1.18.0
php: 8.2.3 / 8.2.6
# apt update 時のメモ
- mysql の GPG エラー
- 参考記事: https://example.com/
- 実行コマンド: apt-key adv --keyserver keyserver.ubuntu.com --recv-keys...それに加えて、ターミナルの操作ログを保存しておくとより安心かもしれない。
アップグレード完了後の動作確認は十分に行う
前回 Ubuntuアップグレードで消えたnode環境を再構築する という記事を書いたのだが、これはまさに当記事の作業後に発生した不具合だった。当時はサービスが正常に動作しているかどうかのチェックに囚われており、「デプロイが正しく行えるか」とかまでは確認ができていなかった。
普段の業務で発生し得る操作を網羅的に確認しておかないと、時間差で不具合に直面する可能性があるため注意したい。