さくらのクラウドの導入・移行・24時間運用をプロが解説するテックメディア

無料相談・お問い合わせ
  • TOP
  • コンピューティング
  • 作成したWebアプリをDockerイメージ化してAppRunで動かしてみよう(第3回) ～セッション維持編～

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

コンピューティング # AppRun # Redis

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

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

第1回～第2回では「AppRun共用型」を用いてWebUIコンテナ + DBアプライアンスの構成を構築して、Apache Webサーバー + php-fpm + RDB (PostgreSQL) の構成を実現しました。

フルスクラッチで作成したWebアプリをDockerイメージ化してAppRunで動かしてみよう(第1回)
フルスクラッチで作成したWebアプリをDockerイメージ化してAppRunで動かしてみよう(第2回)

では、WebUIのコンテナを複数起動したい場合などはどうすればよいでしょうか。単純にWebUIのコンテナを複数とした場合、それぞれのサーバー上でPHPがセッション管理されてしまいます。今回はそんな複数コンテナ環境での「セッション維持」について掘り下げてみたいと思います。

これに対応する方法はいくつか考えられ、例えばWebアプリケーションフレームワーク側の機能でセッション管理をRDB側とすれば、前回の構成のままでも実現可能です。

ただ、RDBでのセッション管理はレスポンスの面での難点も有り、可能であればキーバリュー型のインメモリ型・高速DBである「Redis」や、そのフォークである「Valkey」を用いたセッション管理がベターになってくるでしょう。

今回は複数WebUIコンテナでセッションを共通管理する為の、Redisサーバーもコンテナで起動してみよう、という所に挑戦していきます。

Redisコンテナを起動するには「AppRun専有型」が必要

今回は前回までとは異なり、「AppRun（専有型）」を利用します。「AppRun（専有型）」では共用型とは違い、ユーザー専用の実行ノードでコンテナを起動させるサービスになります。今回は以下の違いから専有型が必要になります。

  • AppRun共用型
    • 対応プロトコルが HTTPS のみ。
    • 起動した際のIPアドレスが不明なのでWeb-Redis間での通信許可がやりづらい。
  • AppRun専有型
    • 対応プロトコルが HTTP / HTTPS / TCP なのでRedisの使うポートもコンテナで起動できる。
    • コンテナのIPアドレスが分かり、他のユーザーとの共用IPでもないので、IPアドレス制限が適用出来る。

RedisはHTTPSではなく独自のプロトコル(TCP: 6379)での通信が必要な為、AppRunでコンテナを起動するには専有型が必要になります。

また、今回は取り上げない部分ですが、より大容量でセキュアな通信を行うために以下の違いも有ります。こちらもまた、専有型を利用するメリットになります。

  • AppRun専有型
    • 共有セグメントでの起動だけでなく、必要に応じてルータ+スイッチやスイッチなどに接続する事も可能。
      その為プライベートなネットワークでのコンテナ利用が可能になる。
    • Let's Encryptの利用設定が可能。

ではさっそく「AppRun(専有型)」でRedisを起動していきます。

サービスプリンシパルの設定

AppRun専有型を利用するうえで必要になるサービスプリンシパルを作成します。サービスプリンシパルはざっくり言うとどこまでの権限を持つかのセットのようなものです。

さくらのクラウドホームから「サービスプリンシパル」画面に移動し、作成していきます。

サービスプリンシパルの設定

設定するのは名前程度なので任意で名前を設定します。

サービスプリンシパルの設定

IAMの設定

「IAMポリシー」の設定画面から、先程作成したサービスプリンシパルに必要な権限（ロール）を付与します。

今回追加が必要なロールは「作成・削除」です。

IAMポリシー設定
IAMポリシー設定

クラスタの作成

いよいよAppRun専有型の設定を進めていきます。共用型のシンプルさに比べると設定項目が増えていますが。順番に設定していきます。

AppRun専有型を利用するうえで、まずは大枠である「クラスタ」を作成します。Redis起動用のクラスタを作成します。

AppRun専有型
クラスタの作成

Redis用クラスタは以下のように設定していきます。セッション維持用Redisは1台のみを起動する構成とする為、ロードバランサは利用しません。

サービスプリンシパル先程作成した物
クラスタ名redis-03
Let’s Encrypt利用設定利用しない
ロードバランサ利用設定しない
クラスタの作成

この段階では大枠のみが作られた状態で、まだコンテナは起動しません。

パケットフィルタの作成

ここで一旦、さくらのクラウド画面の目的のゾーン内に移動し、起動したコンテナやロードバランサに適用する為のパケットフィルタを作成しておきます。今回は「石狩第3ゾーン」を利用します。

パケットフィルタの設定
パケットフィルタの設定

ここで設定するのは名前のみです。

ルールのコピー元なし
名前app-run-03-filter

パケットフィルタを作成したら「詳細」ページに移動し、「ルール」タブからルールを作成します。ルールは上の物から適用されますので順番に注意してください。

今回は検証ですので、自分自身のクライアントIP + いくつかの必須の項目だけを許可するパケットフィルタを作成します。

パケットフィルタの設定
  • ルールの追加
    • プロトコル: ip
    • 送信元ネットワーク: 自分自身のIPアドレスを指定
    • 送信元ポート: 空
    • 宛先ポート: 空
    • アクション: allow
  • ルールの追加
    • プロトコル: ip
    • 送信元ネットワーク: 210.188.224.14
    • 送信元ポート: 空
    • 宛先ポート: 空
    • アクション: allow
  • ルールの追加
    • プロトコル: tcp
    • 送信元ネットワーク: 210.188.224.14
    • 送信元ポート: 空
    • 宛先ポート: 空
    • アクション: allow
  • ルールの追加
    • プロトコル: udp
    • 送信元ネットワーク: 空
    • 送信元ポート: 空
    • 宛先ポート: 32768-61000
    • アクション: allow
  • ルールの追加
    • プロトコル: fragment
    • 送信元ネットワーク: 空
    • 送信元ポート: 空
    • 宛先ポート: 空
    • アクション: allow
  • ルールの追加
    • プロトコル: icmp
    • 送信元ネットワーク: 空
    • 送信元ポート: 空
    • 宛先ポート: 空
    • アクション: allow
  • ルールの追加
    • プロトコル: ip
    • 送信元ネットワーク: 空
    • 送信元ポート: 空
    • 宛先ポート: 空
    • アクション: deny

自分自身のIP許可を主目的としている割にはルールの追加数が多いかと思いますが、こちらはAppRun専有型でパケットフィルタを利用するうえで許可が必要な項目になります。例えば、210.188.224.14 はさくらのNTPサーバーになっています。

許可している項目の詳細はこちらをご確認ください。
コントロールパネル操作ガイド | さくらのクラウド マニュアル

ルール追加後は「反映」ボタンで反映します。

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

Redis用クラスタ redis-03 内で「オートスケーリンググループ」を作成します。オートスケーリンググループを作成すると併せてワーカノードが起動されます。このノード上で実際のコンテナやロードバランサなどが起動します。また、このワーカノードが課金対象となります。

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

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

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

今回は共有セグメントを利用していますが、ここをルータ+スイッチやスイッチとすることが可能です。

オートスケーリンググループを作成するとワーカノードの起動が始まります。起動完了には数分程度待ち時間が有ります。

ワーカノードの起動

なお、パケットフィルタの設定が不適切な場合、この画面でいつまでもワーカノードの起動が完了しない状態となります。その場合は先程紹介した必須の許可項目の見直しを行ってください。

アプリケーションの作成

「クラスタ」の画面に戻り、「アプリケーション」タブからアプリケーションを追加します。ここで入力するのは名前だけです。

アプリケーションの作成
アプリケーション名redis

バージョンの追加

アプリケーションに対して「バージョン」を追加します。これが実際に起動するコンテナの設定になります。コンテナイメージにはDockerHubの物が利用できますので、そこで広く公開されているRedisのイメージを指定します。

バージョンの作成
バージョンの作成
  • コンテナイメージ: redis:8.8-alpine
  • コンテナレジストリアクセス設定: 利用しない
  • リソース設定:
    • mCPU: 500 ms
    • メモリ: 512 MiB
  • オートスケーリング設定: 固定数のノードを維持する
  • ノード数: 1
  • ポート設定:
    • ターゲットポート: 6379
    • ロードバランサ: 利用しない
    • ヘルスチェック: 利用しない
  • コマンド: --save "", --stop-writes-on-bgsave-error no

ここで指定している「コマンド」について説明します。これはRedisコンテナを起動する際にデータの永続化を行わないための調整となります。この指定を行わなかった場合、RedisはインメモリDBの内容を定期的に永続化しようとしますが、AppRun環境ではそれに失敗する為、起動後しばらくするとインメモリDB部分含め読み込み専用モードに切り替わってしまいます。そのため、最初から永続化を行わない設定に調整するための引数を追加してあげています。

作成した「バージョン」をアクティブに変更します。バージョンの横にある「…」メニューから「アクティブに変更」を実行します。

バージョンをアクティブに変更

しばらくするとコンテナの起動に成功するかと思います。

バージョンをアクティブに変更

Redisの動作確認

これでついにセッション維持用のRedisコンテナがAppRun専有型で起動した状態になりました。

パケットフィルタで自分自身のIPアドレスを許可済みですので、デスクトップ上のRedisクライアントから接続確認を行ってみます。今回はGUIのRedisクライアントである「Another Redis Desktop Manager」で接続を行いました。

Redisの動作確認

問題なくキーの追加や、キーに対する値の設定が出来る事が確認出来ました。問題無さそうですね。

次回へ続く

次回はWeb側となる、Redisをセッション保管場所として利用するようにしたフルスクラッチWebアプリケーションDockerイメージを作成していきます。実はここも結構ハマり場所が有ります。ではまた次回お会いしましょう。

参考: AppRun | さくらのクラウド マニュアル

この記事を書いた人

yu-kinjo

ネットアシスト開発部の yu-kinjo です。 【取得資格】 ・さくらのクラウド検定 ・AWS Certified Solutions Architect - Associate ・AWS Certified AI Practitioner ・Oracle 認定Javaプログラマ SE6 ・JSTQB テスト技術者資格 ファンデーションレベル ・CIW (Certified Internet Webprofessional) ファンデーション ・XML技術者育成推進委員会　XMLマスター ベーシックV2 ・基本情報処理技術者 ・初級システムアドミニストレータ

関連記事