ネットアシスト開発チームの yu-kinjo です。
本記事は、フルスクラッチで作成したWebアプリをDockerイメージ化して、さくらのクラウドのDockerコンテナ実行サービスである AppRun で実行してみようという趣旨の連載の第3回です。
第1回~第2回では「AppRun共用型」を用いてWebUIコンテナ + DBアプライアンスの構成を構築して、Apache Webサーバー + php-fpm + RDB (PostgreSQL) の構成を実現しました。

では、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ポリシー」の設定画面から、先程作成したサービスプリンシパルに必要な権限(ロール)を付与します。
今回追加が必要なロールは「作成・削除」です。


クラスタの作成
いよいよAppRun専有型の設定を進めていきます。共用型のシンプルさに比べると設定項目が増えていますが。順番に設定していきます。
AppRun専有型を利用するうえで、まずは大枠である「クラスタ」を作成します。Redis起動用のクラスタを作成します。


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」で接続を行いました。

問題なくキーの追加や、キーに対する値の設定が出来る事が確認出来ました。問題無さそうですね。
次回へ続く
次回はWeb側となる、Redisをセッション保管場所として利用するようにしたフルスクラッチWebアプリケーションDockerイメージを作成していきます。実はここも結構ハマり場所が有ります。ではまた次回お会いしましょう。


