イベントサイトの更新版を公開する

はじめに

Common Ground は、デモ用のコミュニティサイトです。訪問者は Linux Evening を探し、詳細ページを開いて申し込み方法を確認します。次のリリースでは、会場を Room A から Community Hall に変更します。現在のバージョンを失わずに、用意された更新を公開するのがあなたの役目です。

インストール済みのリリースと稼働中のリリースを区別し、更新版を選択して実際のサイトをテストします。アプリケーションと公開用の補助スクリプトは用意されています。コードの作成や Nginx の設定は不要で、ターミナルの基本操作ができれば取り組めます。イベントやアドレスはすべて架空のものです。

各ラボは、それぞれ独立した準備済み環境で始まります。各タブはすぐに使えます。

サイトを確認して更新版を準備する

このステップでは、サイトの正常な動作を確認し、訪問者に見える内容を変えずに新しいリリースをインストールします。まず Website タブを開いてください。

正常な利用の流れを確認する

ホームページには Common Ground の紹介があり、On the horizon の下に Linux Evening が表示されています。現在の会場表示は Location: Room A です。一番下までスクロールすると、小さなフッターに Release: event-v1 とあります。リリースとは、サイトのファイルを特定の状態で保存したひとまとまりのバージョンです。

Website で Linux Evening の行をクリックします。詳細ページには火曜日 18:00、Room A と表示されます。ページ内の Registration instructions を開くと、デモ用のメール申し込み手順を確認できます。実際の申し込みは不要です。上部の COMMON GROUND ロゴをクリックすると、同じタブ内でホームページに戻ります。

これらが維持すべきユーザーの利用経路です。ホームページだけでサービス全体を確認したことにはなりません。

別のコピーを準備する

Workstation に切り替えます。ターミナルは、公開作業用の /home/labex/project/website-release に移動済みです。ls は現在のディレクトリ内の名前を一覧表示します。

ls

packages、releases、current、release.sh が見つかります。packages はインストール前の配布バージョン、releases はインストール済みバージョンの置き場所です。current は訪問者に提供するバージョンを選びます。次のステップで詳しく確認します。

release.sh は、用意された小さな補助スクリプトです。bash で実行し、ファイル名の後ろに続く語で操作と、必要に応じてリリースを指定します。ここではスクリプトを操作するだけで、Bash のコードを書く必要はありません。

bash release.sh help

短いヘルプを読んでください。install はパッケージを専用ディレクトリにコピーし、deploy はサイトに使うバージョンを選び、rollback はインストール済みのバージョンを選びます。どの操作も、業務上必要なページが動くかどうかは判断しません。

配布バージョンを一覧表示します。

bash release.sh list

名前は event-v1 と event-v2 です。更新版をインストールします。

bash release.sh install event-v2

想定される出力：

Installed event-v2. The current website was not changed.

インストール済みの両ディレクトリが存在することを確認します。releases を付けると、ls が一覧表示するディレクトリを指定できます。

ls releases

event-v1 と event-v2 があるはずです。別のコピーとしてインストールすることで旧版を保存できます。この操作では、まだ更新版を公開していません。

Website に戻ってページを再読み込みします。会場はまだ Room A で、フッターも event-v1 のままです。これは意図した結果です。次のステップで更新版を選択します。

更新版を選択して公開する

このステップでは、復旧用のバージョンを残したまま、サイトで選択するリリースを変更します。Workstation から始めます。

選択の仕組みを理解する

シンボリックリンクは、ファイルシステム内の別の場所を参照する仕組みです。ここでは current が、インストール済みリリースのディレクトリを参照しています。用意された Web サーバー Nginx は、このリンク経由でサイトのファイルを読み込みます。

readlink はシンボリックリンクの参照先を表示します。

readlink current

想定される出力：

releases/event-v1

この相対パスは、作業ディレクトリの releases 内にある event-v1 ディレクトリを意味します。各ディレクトリには HTML ページ、ローカルの CSS、ローカルのイラスト、小さなバージョンファイルが含まれます。これら全体が、完全なサイトのリリースです。

cat はファイルの内容を表示します。公開前に、復旧用バージョンが何かを確認します。

cat releases/event-v1/version.txt

event-v1 と表示されます。このディレクトリ全体を保存してください。更新版が検査に通らなければ、これを再選択するのが復旧計画です。作り直したり削除したりすると、その計画が成り立たなくなります。

インストール済みのバージョンを公開する

更新版を選択します。

bash release.sh deploy event-v2

想定される出力：

Selected event-v2. The server reports:
event-v2
Selection finished. Check the required pages before accepting this release.

スクリプトはインストール済みディレクトリを使い、一時リンクと名前変更によって current を切り替え、実際にバージョン情報をリクエストします。旧サイトのファイルを上書きせずに済みます。ただし、全ページの動作を証明するものでも、ブラウザーのセッション全体が一度に同じバージョンへ切り替わる保証でもありません。

選択状態を確認します。

readlink current

今度は releases/event-v2 と表示されます。

Website に切り替えます。別のページが開いている場合は COMMON GROUND をクリックしてホームに戻り、再読み込みしてください。On the horizon の会場が Location: Community Hall になり、フッターには event-v2 と表示されます。

新しい会場とフッターで、サイトが変わったことを確認できました。リリースを受け入れる前に、重要な利用経路の検査が必要です。

サイトを検証し、復旧できる状態を保つ

このステップでは、訪問者として、また HTTP クライアントとして新しいリリースを確認し、旧版も使える状態で残っていることを確かめます。Website から始めます。

ユーザーの利用経路をたどる

Linux Evening の行をクリックします。詳細のサイドバーには Room A ではなく Community Hall と表示されるはずです。Registration instructions を開いてください。参加手順と events@example.test が表示され、ページが見つからない画面にならないことを確認します。

Website 内の COMMON GROUND をクリックしてホームに戻ります。

実際の HTTP 応答を確認する

Workstation に切り替えます。HTTP は、このサイトが使うリクエストとレスポンスの通信規約です。リクエストは /registration.html などのパスを指定し、サーバーはステータスと内容を返します。200 は要求した応答の成功、404 は要求したページが見つからないことを表します。

curl はリクエストを送ります。-sS は進行状況を隠しますが、接続エラーは表示します。-o /dev/null は応答本文を破棄します。/dev/null はシステム上の破棄先です。-w は後続の書式を出力します。単一引用符が書式をひとまとまりに保ち、%{http_code} がステータスを選び、\n が出力行を改行します。

127.0.0.1 はこのラボ環境を指し、ポート 8081 が用意されたサイトの接続先です。このアドレスは自分のパソコンのターミナルではなく、Workstation で使ってください。末尾の / はホームページを要求します。

ホームページを確認します。

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/

結果は 200 です。

詳細ページと申し込みページのパスを個別に確認します。

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 を返す必要があります。Website での内容確認も重要です。間違ったページが返るなら、200 でも成功とはいえません。

本文を破棄せず、小さなバージョン応答を取得することもできます。

curl -sS http://127.0.0.1:8081/version.txt

event-v2 と表示されます。参考になる証拠ですが、バージョン表示はページとリンクの検査の代わりにはなりません。

復旧の選択肢を残す

元のリリースは完全な状態で残す必要があります。

cat releases/event-v1/version.txt

今も event-v1 と表示されます。ページ、スタイル、イラストも保存してください。バージョン表示だけを変えてもサイトを保存したことにはなりません。

Topology に切り替えます。Homepage reachable は、ホームページが応答するという意味に限られます。リリース全体の合格判定ではありません。これで利用経路を個別に検証し、完全な復旧用バージョンも確保できました。

まとめ

リリースを別にインストールし、旧ファイルを上書きせずに選択して、実際のページとリンクを検証しました。また、正常動作が確認済みの完全なバージョンを復旧用に残しました。次のラボでは、ホームページは動いても重要な利用経路が失敗する場面で、この復旧手段を使います。