シリーズ
モチベーション
現在の実装*1 ではアプリケーションサーバー側のセッションIDがプログラム終了後に揮発してしまう。
// https://github.com/tokizuoh/statice/blob/v0.1/front/main.go#L12 var mapSessionID = map[string]string{}
プログラムが終了した後でもセッションIDを揮発させないために永続化する。
セッション管理のDBについては初学者のため良し悪しが分からないのでスタンダードっぽいRedisを使ってみる。
リポジトリ
Redis
GoからRedisを使う前に素振り。
コード
FROM redis:6.2-alpine
version: '3.8' services: redis: build: context: ./redis dockerfile: Dockerfile container_name: {CONTAINER_NAME} ports: - 6379:6379 volumes: - ./redis/data:/data
操作
# コンテナ生成 > docker-compose up --build -d # コンテナ内でshの実行 > docker exec -it ${CONTAINER_NAME} sh /data # redis-cli 127.0.0.1:6379> set hoge-key fuga-value OK 127.0.0.1:6379> get hoge-key "fuga-value" 127.0.0.1:6379> del hoge-key (integer) 1 127.0.0.1:6379> get hoge-key (nil)
GoからRedisを利用
上記を利用。README読めば使い方は分かる。
所感
- エラーハンドリングについて考えることが多くなった
- ユーザーからのリクエスト時に、RedisにセッションIDが含まれてるか確認する時
- Redisに目的の値が無い
- ログインページにリダイレクト?
- エラーページに遷移?
- アプリケーションサーバー側からRedisへの接続時にエラー
- ここでも上の二択を迫られる
- Redisに目的の値が無い
- ユーザーからのリクエスト時に、RedisにセッションIDが含まれてるか確認する時
- 真の意味でのRedisの永続化はどうする?
- 現在はdocker-composeを起動する役のローカル環境にDockerのボリュームをマウントしているため、ローカル環境に依存してしまっている
- Amazon ElastiCacheなどを使って完全に切り離す?
- 現在はdocker-composeを起動する役のローカル環境にDockerのボリュームをマウントしているため、ローカル環境に依存してしまっている
上記の悩みも追々解決していく。