luftgarden

熊本のWebアプリケーション開発

手順そのものは 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 に以下を書いておきます。

ServerAliveInterval 60
TCPKeepAlive yes

また、リモートサーバ側の /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...

それに加えて、ターミナルの操作ログを保存しておくとより安心だと思います。

ターミナルの出力を自動保存する方法 5 選

アップグレード完了後の動作確認は十分に行う

サービスの正常稼働を確認しただけで終わりにせず、普段の業務で発生し得る操作を網羅的に確認しておかないと、時間差で不具合に直面する可能性があるため注意したいところです。

例えば、「デプロイが問題なく行えるか」といった運用面の確認があります。
（ubuntu のアップグレードに伴い、サーバ上の node 環境が消えてデプロイに失敗してしまうケースとか）