はじめに
Common Ground の別の候補リリースを評価します。公開コマンドが成功しても、訪問者が重要な操作を完了できないことがあります。その違いを見分け、必要なら正常動作が確認済みのリリースへ戻すのが役目です。
この使い捨ての練習サイトに実際の訪問者はいません。復旧を意図的に練習します。実際の提供プロセスでは、公開前の検査で候補を却下し、訪問者に届く前に止めることもできます。
これは新しい環境です。前のラボでの操作に関係なく、Room A の event-v1 が稼働しています。event-v3 を準備し、実際の利用経路を調べ、配布されたサイトのファイルを編集せずに元のサービスへ復旧します。Workstation、Website、Topology の各タブは使用可能です。
復旧先を準備する
サイトを変更する前に、正常なバージョンを特定し、候補を別にインストールします。Website から始めます。
復旧で戻すべき状態を知る
ホームページでは Linux Evening が Room A で開催され、フッターは event-v1 です。行をクリックして詳細が開くことを確認し、Registration instructions も開きます。復旧では、これらの正常な機能を取り戻す必要があります。Website の COMMON GROUND でホームに戻ります。
Workstation に切り替えます。ターミナルは /home/labex/project/website-release に移動済みです。現在のシンボリックリンクを確認します。
readlink current
releases/event-v1 と表示されます。保存されているバージョンファイルを確認します。
cat releases/event-v1/version.txt
event-v1 と表示されます。ここでは、このディレクトリが明確な復旧先です。どのシステムでも「直前の版」が正しいとは限りません。このラボでは、必要なページが正しく提供されることを確認したうえで選んでいます。
候補を準備する
配布パッケージを一覧表示します。
bash release.sh list
この環境には event-v1 と event-v3 があります。候補は会場を Community Hall に変更します。名前が新しいことやインストールの成功は、品質の証明ではありません。
選択せずにインストールします。
bash release.sh install event-v3
メッセージは現在のサイトを変更していないことを示します。インストール済みのリリースを一覧表示します。
ls releases
event-v1 と event-v3 の両方があるはずです。どちらも変更せずに残してください。候補は評価対象で、基準となる版は復旧先です。
リリースの失敗を見分ける
候補を公開し、選択の成功とユーザー向け機能の正常動作を区別します。Workstation から始めます。
選択の成功を確認する
候補を選択します。
bash release.sh deploy event-v3
スクリプトは event-v3 を報告し、ページの検査を促します。コマンドが完了したのは選択処理であり、業務要件の評価ではありません。
最初のラボで使った curl のオプションでホームページのステータスを調べます。
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/
200 が返ります。バージョンのエンドポイントも動作します。
curl -sS http://127.0.0.1:8081/version.txt
event-v3 と表示されます。どちらもセッションへのリンクが動く証拠ではありません。
ユーザーに見える失敗を探す
Website に切り替え、COMMON GROUND でホームに戻って再読み込みします。ホームページは整って見え、Community Hall と表示されています。Linux Evening をクリックします。
詳細の代わりに Let's get you back on track. と 404 / A SMALL DETOUR が表示されます。これはサイトのページ未検出画面です。洗練された見た目でも、要求したセッションに対する HTTP 結果は失敗です。
候補のリンク先は /events/container-evening.html です。Workstation に戻って、そのパスを正確に要求します。
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/events/container-evening.html
想定結果は 404 です。意図した証拠であり、修正したり飛ばしたりするコマンドではありません。HTTP エラーで失敗させる curl のオプションを使っていないので、404 を受け取っても curl は正常終了できます。サーバーから応答が届くことと、接続できないことは別です。
Topology に切り替えます。限定的な検査は成功するため、Homepage reachable のままでも不思議ではありません。しかし、必要なセッションのパスは失敗しています。このリリースを却下し、正常動作が確認済みの版へ戻してください。サイトの停止や候補の書き換えは行いません。
正常動作が確認済みの版へ復旧して検証する
元のサイトへ復旧し、訪問者が再び利用できることを確認します。Workstation から始めます。
保存したリリースを選択する
rollback はインストール済みのバージョンを選びます。失敗した候補を修正したり再構築したりはしません。確認済みの復旧先を選択します。
bash release.sh rollback event-v1
想定される出力：
Selected event-v1. The server reports:
event-v1
Selection finished. Check the required pages before accepting this release.
シンボリックリンクを確認します。
readlink current
releases/event-v1 が選択されています。event-v3 ディレクトリも保存されています。後の調査用に残すことは、訪問者への提供が続いているという意味ではありません。
復旧後の利用経路を確認する
Website に切り替えます。ブラウザーにはまだ候補の存在しない URL が残っているかもしれません。COMMON GROUND でホームに戻って再読み込みします。Room A と event-v1 が表示されるはずです。再び Linux Evening を開くと、復旧したリンクは /events/linux-evening.html を開きます。そこで Registration instructions を開き、参加手順を確認します。
候補だけが使っていた古い URL は、再試行しても 404 のままです。復旧は正常なサイトの実際のリンクを戻すもので、存在しない URL をすべて作るものではありません。
Workstation に戻り、復旧したパスを確認します。
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/events/linux-evening.html
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/registration.html
すべて 200 を返します。ブラウザーでの確認により、内容も正しいことが分かっています。
インストール済みの両バージョンを残します。
ls releases
event-v1 と event-v3 が引き続き見つかるはずです。サービスは復旧しましたが、候補の不具合は後の開発作業に残ります。この演習が復旧するのは静的なサイトのファイルだけです。データベースの変更、ユーザーの送信内容、ブラウザーのセッション全体を原子的に元へ戻すものではありません。
まとめ
実際の公開コマンドが成功しても利用経路が失敗することを確認し、候補を却下して、正常動作が確認済みの完全なサイトへ復旧しました。ページの実際の内容と HTTP 応答の両方で復旧を検証しました。候補は調査用に残っています。復旧によって候補がひそかに修正されたわけではありません。
