作成したWebアプリをDockerイメージ化してAppRunで動かしてみよう(第5回) ～セッション維持編～

ネットアシスト開発チームの yu-kinjo です。

本記事は、フルスクラッチで作成したWebアプリをDockerイメージ化して、さくらのクラウドのDockerコンテナ実行サービスである AppRun で実行してみようという趣旨の連載の第5回です。

第3回からは「AppRun専有型」を用いて複数のWebUIコンテナ間でセッションを維持する方法を模索していきます。第3回ではセッション維持用Redisコンテナを作成、第4回ではそのRedisコンテナを利用しセッション連携するようにWebアプリを作成し、Dockerイメージ化しました。

第5回となる今回は、作成したイメージから実際にWebUIコンテナを複数起動していきます。

作成したWebアプリをDockerイメージ化してAppRunで動かしてみよう(第3回) ～セッション維持編～
作成したWebアプリをDockerイメージ化してAppRunで動かしてみよう(第4回) ～セッション維持編～

クラスタの作成

第3回～第4回にて、Dockerイメージのコンテナレジストリへのアップロード、サービスプリンシパルやIAMの設定は済んでいるはずですので、早速WebUI用のクラスタを作成します。

「AppRun(専有型)」の管理画面から、クラスタを作成します。

サービスプリンシパル: 作成した物
クラスタ名: web-03
Let’s Encrypt利用設定: 利用しない
ロードバランサ利用設定: 利用する
- ポート設定1:
  - ポート: 80
  - プロトコル: http

Redis用に作成したクラスタとは違い、複数のWebUIコンテナを利用しますので、ロードラバランサ利用設定を「利用する」を選択します。

オートスケーリンググループの作成

次に「オートスケーリンググループ」を作成します。

オートスケーリンググループ名: web-as
ゾーン: 石狩第3ゾーン
ワーカプラン: 1vCPU / 2GB
最小ノード数: 1
最大ノード数: 3
NIC設定: 共有セグメント
パケットフィルタ: app-run-03-filter
ロードバランサに接続する: 有効
ネームサーバ設定: 推奨ネームサーバ（自動設定）を利用する

Redis用とは違い最大ノード数を3に増やしています（※）。
作成完了まで数分の待ち時間が有ります。

※: 今回の構成では、IPアドレスを固定しやすくするためにも、最小2の最大2とした方がよかったかもしれません。

ロードバランサの作成

Redisコンテナの際には無かった手順になります。ワーカノードとは別で、ロードバランサを作成する必要が有ります。

以下のように設定します。

ロードバランサについても課金対象となりますのでご注意ください。

ロードバランサ名: web-lb
ロードバランサプラン: 1vCPU / 2GBメモリ (非冗長構成)
NIC設定: 共有セグメント
パケットフィルタ: app-run-03-filter
ネームサーバ設定: 推奨ネームサーバ（自動設定）を利用する

こちらも数分の待ち時間が有ります。

アプリケーションの作成

「クラスタ」の画面に戻り、「アプリケーション」タブからアプリケーションを追加します。

アプリケーション名: web03

バージョンの追加

「バージョン」を追加し、WebUIコンテナを起動の為の設定を行います。

コンテナイメージには、コンテナレジストリにアップしたイメージを指定します。また、ロードバランサポート http/80 で受けた通信を、コンテナ側の 8080 ポートに流すように設定しています。

環境変数ではRedisに接続するための環境変数 REDIS_HOST を渡していしますが、ここではRedisが起動しているワーカノードのIPアドレスを値に指定します。

ホスト名の入力は必須ですので、任意のホスト名を設定してください。

コンテナイメージ: <コンテナレジストリURL>/sakura_app_run_session:latest
コンテナレジストリアクセス設定: 利用する　※IDとPWを入力
リソース設定:
- mCPU: 250 ms
- メモリ: 400 MiB
オートスケーリング設定: 固定数のノードを維持する
- ノード数: 2
ポート設定:
- ターゲットポート: 8080
- ロードバランサ: 利用する
- ロードバランサポート: http/80
- ホスト名: <任意のホスト名を設定>
- ヘルスチェック: 利用しない
環境変数: REDIS_HOST <RedisワーカノードのIPアドレスを設定>

バージョン追加後は「...」ボタンからバージョンをアクティブに変更します。変更後しばらく待つとコンテナが2つ起動します。

パケットフィルタの再調整

ワーカやロードバランサなどにパケットフィルタが適用されており、今のままではお互いに通信が行えません。

パケットフィルタにWeb側ワーカノードのIPアドレス、RedisワーカノードのIPアドレス、ロードバランサのIPアドレスを Allow で追加しておきます。

Webブラウザから動作確認

「バージョン」作成時に設定したホスト名を、自分のPCのhostsファイルに設定しておきます。管理者権限で起動した「メモ帳」等の適当なテキストエディタで、適宜hostsファイルで名前解決を行えるようにしておいてください。

IPアドレスにはロードバランサのIPを指定

ホスト名には先程指定したホスト名を指定

では、Webブラウザからアクセスしてみます。

問題なくページが表示できる事、セッションが維持され、Webブラウザをリロードするたびに閲覧回数が増えていく事や、初回アクセスの日時は変わらない事が確認出来ました。

セッションをリセットしてみたい場合は、ご利用のWebブラウザの開発者ツールからCookie「PHPSESSID」を削除する事でセッションをリセットできます。

ただ、今回どちらのWebUIコンテナで処理されても、どちらもコンテナ名が「ubuntu」となっているようで、振り分けられている事が分かりづらいです。本当に振り分けられている事をログファイルから確認してみます。

AppRun専有型管理画面トップの「ログ・メトリクス設定」から「コンテナログ」を有効化する事で、コンテナのログが確認可能です。また、保存先に選択肢が無い場合は、「さくらのクラウド」管理画面内の「モニタリングスイート」→「ログストレージ」から追加します。

設定すると、「アプリケーション」詳細画面内の「ランタイムログ」から各コンテナの生成するログが確認出来るようになります。

※反映されない場合は、バージョンを無効化→有効化を再度試してみてください。
※作成したイメージからコンテナが起動できない場合も、この画面に出るログが有用です。

複数のコンテナでリクエストが処理されていそうなことが確認出来ました。

まとめ

AppRun専有型特有の細かく増えた設定項目について、まだ追い切れていない部分は有りますが、ひとまず複数WebUIコンテナ + Redisコンテナでのセッション維持が実現できました。ここから、さらに共有セグメントを使わないようにするなど、より実案件に即した構成にしていく事も可能そうです。

若干難しいと感じた点としては、コンテナイメージを作成する際に制限事項が増える（第4回記事にて解決済み）点と、ワーカノードが提供するリソース量とコンテナの使用リソースの関係が若干分かりづらい点でしょうか。後者については検証の段階ではワーカノードが不足している旨のエラーメッセージを何度か目にすることになりましたので、この辺りについて、今後公式のマニュアルや画面上のメッセージがより分かりやすくなると嬉しいですね。

ではまた、AppRunについてご紹介できることが出てきましたら、ご紹介したいと思います。