DockerでRedisを使う方法

By /

はい、承知いたしました。DockerでRedisを使う方法について、約5000語の詳細な記事を作成し、ここに直接表示します。

DockerでRedisを使う方法：基礎から実践まで徹底解説

はじめに

現代のウェブアプリケーション開発において、データの高速な読み書きは必須の要件です。リレーショナルデータベースだけでは対応しきれないパフォーマンス要件を満たすために、インメモリデータストアやキャッシュストアが広く利用されています。その中でも特に人気が高く、多機能で高性能なのが Redis です。

一方、アプリケーションの環境構築やデプロイメントを劇的に簡素化する技術として、Docker が広く普及しています。Dockerは、アプリケーションとその実行に必要なライブラリ、依存関係などをコンテナとしてパッケージ化し、どの環境でも同じように動作することを保証します。

この二つの強力なツール、RedisとDockerを組み合わせることで、開発効率の向上、環境間の差異の排除、スケーラビリティの確保など、様々なメリットを享受できます。しかし、「Dockerはなんとなく使ったことはあるけど、本格的にRedisと組み合わせて使うにはどうすればいいの？」「永続化や設定ファイルの適用はどうやるの？」といった疑問を持つ方もいらっしゃるかもしれません。

この記事では、Dockerを使ってRedisを効率的かつ実践的に利用するための方法を、基礎から応用まで詳細に解説します。簡単なコンテナの起動から始まり、データの永続化、設定ファイルの適用、Docker Composeを使った複数サービスの管理、さらにはセキュリティや可用性に関する考慮事項まで、幅広く網羅します。

この記事を読むことで、あなたは以下のことができるようになります。

  • Dockerを使って簡単にRedisコンテナを起動し、操作できるようになる。
  • Redisコンテナのデータを永続化し、データ消失を防ぐ方法を理解し実践できるようになる。
  • カスタム設定を適用してRedisコンテナを起動できるようになる。
  • Docker Composeを使ってRedisを含むアプリケーションスタックを効率的に管理できるようになる。
  • Docker環境におけるRedisの基本的なベストプラクティスやトラブルシューティング方法を理解する。

対象読者は、DockerやRedisの基本的な概念は知っているものの、それらを組み合わせて実用的な環境を構築した経験があまりない開発者や運用担当者を想定しています。

さあ、DockerとRedisの世界へ深く潜り込んでいきましょう。

Dockerの基本（Redisを使うために必要な知識）

Redisコンテナを操作する前に、Dockerの基本的な概念とよく使うコマンドについて簡単に復習しておきましょう。

Dockerのインストール

DockerはWindows, macOS, Linuxなど様々なOSにインストール可能です。Docker Desktop（Windows/macOS）またはDocker Engine（Linux）を公式サイトからダウンロードしてインストールしてください。

インストールが完了したら、以下のコマンドを実行してDockerが正しく動作しているか確認できます。

bash
docker --version
docker compose version # または docker-compose --version (旧バージョン)

主要なDockerコマンド

Dockerでは、コマンドラインインターフェース（CLI）を使って様々な操作を行います。Redisコンテナを扱う上で特によく使うコマンドをいくつか紹介します。

  • docker pull <イメージ名>[:タグ]: Docker Hubなどのコンテナレジストリから指定したイメージをダウンロードします。タグを省略すると最新版（latestタグ）がダウンロードされます。

    • 例: docker pull redis (最新版のRedisイメージをダウンロード)
    • 例: docker pull redis:6.2 (バージョン6.2のRedisイメージをダウンロード)

  • docker images: ローカルに存在するDockerイメージの一覧を表示します。

  • docker run [オプション] <イメージ名>[:タグ] [コマンド] [引数]: 指定したイメージから新しいコンテナを作成し、実行します。様々なオプションを指定することで、コンテナの振る舞いを細かく制御できます。

    • 例: docker run redis (Redisコンテナを起動)
    • 例: docker run -d redis (Redisコンテナをバックグラウンド（デタッチドモード）で起動)
    • 例: docker run -it redis sh (Redisコンテナ内で対話的にシェルを実行)

  • docker ps [-a]: 実行中のコンテナの一覧を表示します。-aオプションを付けると、停止中のコンテナも含めた全ての一覧が表示されます。

  • docker stop <コンテナ名またはID>: 実行中のコンテナを優雅に停止します（SIGTERMシグナルを送信）。

  • docker start <コンテナ名またはID>: 停止中のコンテナを再開します。

  • docker restart <コンテナ名またはID>: 実行中のコンテナを再起動します。

  • docker rm <コンテナ名またはID>: 停止中のコンテナを削除します。実行中のコンテナを削除するには-fオプション（強制削除）が必要です。

  • docker logs <コンテナ名またはID>: コンテナの標準出力（stdout）と標準エラー出力（stderr）に表示されたログを確認します。コンテナ内で発生したエラーや起動時のメッセージを確認するのに役立ちます。

  • docker exec [オプション] <コンテナ名またはID> <コマンド> [引数]: 実行中のコンテナ内でコマンドを実行します。コンテナ内部の状態を確認したり、コンテナ内のツールを使ったりするのに便利です。

    • 例: docker exec my-redis redis-cli (実行中のmy-redisコンテナ内でredis-cliコマンドを実行)

Dockerイメージとコンテナの関係

Dockerイメージは、アプリケーションを実行するために必要なコード、ライブラリ、依存関係、設定ファイルなどが読み取り専用のテンプレートとしてまとめられたものです。例えるなら、OSがインストールされた仮想マシンのディスクイメージのようなものです。

コンテナは、そのイメージを基に実行される独立したプロセスです。イメージを基にメモリ上に展開され、書き込み可能なレイヤーが追加されます。複数のコンテナを同じイメージから起動できます。コンテナは実行状態を持つ「インスタンス」のようなものです。

Docker Hubとは

Docker Hubは、Dockerイメージを公開・共有するための公式なコンテナレジストリサービスです。世界中の開発者が作成した様々な公式イメージ（OS, データベース, アプリケーションなど）や、ユーザーが作成したイメージが公開されています。docker pullコマンドでイメージを取得する際、デフォルトではDocker Hubからダウンロードされます。Redisの公式イメージもDocker Hubで公開されています。

簡単なRedisコンテナの起動

Dockerの基本的な知識を確認したところで、実際にRedisコンテナを起動してみましょう。

Redisイメージの取得

まず、Docker HubからRedisの公式イメージをダウンロードします。タグを指定しない場合は、最新版のlatestタグのイメージがダウンロードされます。

bash
docker pull redis

ダウンロードが完了すると、docker imagesコマンドでローカルにイメージが保存されていることを確認できます。

bash
docker images

出力例：

REPOSITORY TAG IMAGE ID CREATED SIZE
redis latest abcdef123456 2 weeks ago 100MB

基本的なコンテナ起動

ダウンロードしたイメージを使って、Redisコンテナを起動します。開発や簡単なテストであれば、最もシンプルな方法で起動できます。

以下のコマンドは、Redisコンテナをバックグラウンドで実行し、コンテナにmy-redisという名前を付けます。名前を付けることで、その後の操作（停止、削除、接続など）が容易になります。

bash
docker run -d --name my-redis redis

  • -d: デタッチドモード（Detached mode）。コンテナをバックグラウンドで実行し、コマンドを実行したターミナルからコンテナのプロセスを分離します。
  • --name my-redis: コンテナにmy-redisという名前を付けます。名前はDockerホスト内で一意である必要があります。

コンテナの状態確認

コンテナが正しく起動したか確認するには、docker psコマンドを使います。

bash
docker ps

出力例：

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
abcdef123456 redis "docker-entrypoint.s…" 10 seconds ago Up 9 seconds 6379/tcp my-redis

STATUSがUp ... secondsとなっていれば、コンテナは正常に起動し、実行中です。NAMES列で指定したmy-redisという名前が確認できます。PORTS列には6379/tcpと表示されていますが、これはコンテナ内部のポート番号であり、現時点ではホストOSからは直接アクセスできません（ポートマッピングについては後述します）。

Redis CLIへの接続

実行中のRedisコンテナに接続し、Redisコマンドを実行してみましょう。Dockerコンテナ内でコマンドを実行するにはdocker execコマンドを使用します。Redisコンテナには、Redisサーバーと対話するためのクライアントツールであるredis-cliが同梱されています。

bash
docker exec -it my-redis redis-cli

  • -it: iはインタラクティブ（Interactive）、tは擬似TTY割り当て（Allocate a pseudo-TTY）のオプションです。これらを組み合わせることで、コンテナ内のプロセスと対話的にやり取りできるようになります。redis-cliのような対話型ツールを使う際に必要です。
  • my-redis: コマンドを実行したいコンテナの名前です。
  • redis-cli: コンテナ内で実行したいコマンドです。

このコマンドを実行すると、Redis CLIのプロンプトが表示されます。

127.0.0.1:6379>

簡単なコマンド実行

Redis CLIでいくつかの基本的なコマンドを実行してみましょう。

  • 接続確認: PINGコマンドはサーバーへの接続を確認し、PONGと応答します。

    127.0.0.1:6379> PING
    PONG

  • データの書き込み: SETコマンドでキーと値を保存します。

    127.0.0.1:6379> SET mykey "Hello from Docker Redis!"
    OK

  • データの読み出し: GETコマンドでキーに対応する値を取得します。

    127.0.0.1:6379> GET mykey
    "Hello from Docker Redis!"

  • CLIの終了: exitまたはquitコマンドでRedis CLIを終了し、ホストOSのターミナルに戻ります。

    127.0.0.1:6379> exit

これで、Dockerを使ってRedisを起動し、CLIで操作できることを確認しました。

コンテナの停止と削除

使い終わったコンテナは停止・削除するのが一般的です。

コンテナを停止するには、docker stopコマンドを使います。

bash
docker stop my-redis

docker psコマンドで確認すると、my-redisコンテナが表示されなくなります。停止中のコンテナも含めて確認するにはdocker ps -aを使います。STATUSがExited (0) ...となっていれば停止しています。

停止したコンテナを削除するには、docker rmコマンドを使います。

bash
docker rm my-redis

docker ps -aで確認しても、my-redisコンテナが表示されなくなります。

注意点: この方法で起動したコンテナは、削除するとコンテナ内部に保存されていたデータ（SETコマンドで保存したデータなど）も一緒に削除されてしまいます。後述する「永続化」の設定を行わない限り、コンテナはステートレスな使い捨ての状態になります。

永続化（データの保存）

前述の通り、Dockerコンテナはデフォルトでは一時的なストレージを使用するため、コンテナが削除されるとデータは失われます。データベースであるRedisを使う上で、データの永続化は非常に重要です。Dockerでは、コンテナのライフサイクルとは独立してデータを保存する方法がいくつか提供されており、これを利用します。

なぜ永続化が必要か

開発中のテスト環境では、コンテナを気軽に削除して再作成したい場合があります。しかし、本番環境や開発・検証環境でRedisをデータストアとして利用する場合、コンテナの停止、再起動、アップグレード、あるいは何らかの障害でコンテナが再作成された際に、データが消えてしまうのは困ります。データの永続化設定を行うことで、コンテナが削除されてもデータはDockerホスト上に残り、新しいコンテナから同じデータにアクセスできるようになります。

Redisの永続化メカニズムの概要

Redis自身は、データの永続化のために主に以下の2つのメカニズムを提供しています。

  1. RDB (Redis Database): ある時点でのRedisのメモリ上のデータをスナップショットとしてディスクに保存する方法です。設定された間隔（例: 900秒間に1回以上のキーの変更があった場合）で自動的にRDBファイルを生成するか、SAVEまたはBGSAVEコマンドで手動で実行します。.rdbという拡張子のバイナリファイルとして保存されます。復旧が速く、特定の時点への復帰が容易な反面、最後に保存されたスナップショット以降のデータは失われる可能性があります。
  2. AOF (Append Only File): サーバーへの書き込みコマンドをログとして記録する方法です。ファイルにはRedisが実行したコマンドが追記されていきます。サーバー起動時には、AOFファイルに記録されたコマンドを順番に実行することでデータセットを再構築します。すべての書き込みコマンドが記録されるため、RDBよりも高いレベルでデータの耐久性を確保できますが、ファイルサイズが大きくなりやすく、復旧に時間がかかる場合があります。AOFは設定で有効にする必要があります（デフォルトは無効）。

DockerでRedisコンテナを使う場合、これらのRedisの永続化メカニズム自体はコンテナ内部で動作しますが、その保存先（.rdbファイルや.aofファイル）をコンテナ外部の永続的な場所にマッピングする必要があります。

Dockerにおける永続化の方法

Dockerでコンテナのデータを永続化するには、主に以下の2つの方法があります。

  1. Volume Mount (Docker Volumes): Dockerが管理する領域にデータを保存する方法です。最も推奨される方法です。
  2. Bind Mount: ホストOS上の特定のディレクトリにデータを保存する方法です。

Redisの永続化設定においては、コンテナ内部のRedisデータディレクトリ（デフォルトでは/data）を、VolumeまたはBind MountでホストOS上の永続的な場所へマッピングします。

Volume Mount (Docker Volumes)

Volumeは、Dockerが管理する専用の領域にデータを保存する仕組みです。データの所有権や権限などをDockerが適切に管理してくれるため、ほとんどの場合で最も推奨される方法です。Volumeはコンテナのライフサイクルとは独立しており、コンテナが削除されてもVolumeはそのまま残ります。

Volumeの作成と管理:
Volumeはdocker volume createコマンドで事前に作成するか、docker runコマンド実行時にDockerに自動作成させることができます。

事前に作成する場合:
bash
docker volume create redis_data
これでredis_dataという名前のVolumeが作成されました。

作成されたVolumeの一覧を確認するにはdocker volume lsコマンドを使います。
bash
docker volume ls
出力例：
DRIVER VOLUME NAME
local redis_data

Volumeの詳細情報を確認するにはdocker volume inspectコマンドを使います。MountpointにVolumeの実体があるホストOS上のパスが表示されます。
bash
docker volume inspect redis_data
出力例：
json
[
{
"CreatedAt": "2023-10-27T10:00:00Z",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/redis_data/_data", # これはホストOS上のパスであり、直接操作すべきではない
"Name": "redis_data",
"Options": {},
"Scope": "local"
}
]
注意: Mountpointに表示されるパスはDockerが管理する内部パスであり、通常はユーザーが直接このパスを操作したり、ここに手動でファイルを配置したりすることは推奨されません。VolumeへのアクセスはDockerコンテナ経由で行います。

不要になったVolumeはdocker volume rmコマンドで削除できます。ただし、使用中のVolumeは削除できません。
bash
docker volume rm redis_data

Volumeを使ったコンテナ起動:
作成したVolume (redis_data) をRedisコンテナのデータディレクトリ (/data) にマッピングして起動します。docker run -v オプションを使用します。volume_name:container_path の形式で指定します。

bash
docker run -d --name my-redis-volume -v redis_data:/data redis
* -v redis_data:/data: redis_dataという名前のVolumeを、コンテナ内の/dataディレクトリにマッピングします。コンテナ内の/dataディレクトリへの書き込み（RedisによるRDBファイルやAOFファイルの保存）は、ホストOS上のredis_data Volumeに永続的に保存されるようになります。

コンテナが起動したら、以前と同様にRedis CLIでデータ操作が可能です。
bash
docker exec -it my-redis-volume redis-cli
127.0.0.1:6379> SET volume_key "Data is persisted using a volume!"
OK
127.0.0.1:6379> GET volume_key
"Data is persisted using a volume!"
127.0.0.1:6379> exit

コンテナを停止・削除してみましょう。
bash
docker stop my-redis-volume
docker rm my-redis-volume

コンテナは削除されましたが、Volume (redis_data) は残っています (docker volume ls で確認)。

次に、同じVolume (redis_data) を使って新しいRedisコンテナを起動します。
bash
docker run -d --name my-redis-volume-new -v redis_data:/data redis

新しいコンテナでRedis CLIに接続し、先ほど保存したデータが読み出せるか確認します。
bash
docker exec -it my-redis-volume-new redis-cli
127.0.0.1:6379> GET volume_key
"Data is persisted using a volume!" # データが残っている！
127.0.0.1:6379> exit
このように、Volumeを使うことでコンテナが削除されてもデータが永続化されることが確認できました。

データの確認 (RDBファイル):
RedisはデフォルトでRDBによる永続化が有効になっています（いくつかの設定条件があります）。docker execコマンドでコンテナ内部に入り、/dataディレクトリの内容を確認してみましょう。
bash
docker exec -it my-redis-volume-new ls /data
出力例：
dump.rdb # RDBファイルが存在する
dump.rdbファイルが存在し、これがVolumeに保存されていることがわかります。

AOF永続化を有効にしている場合（後述の設定ファイルでappendonly yesを指定）、/dataディレクトリにはappendonly.aofファイルも生成されます。

Bind Mount

Bind Mountは、ホストOS上の特定のディレクトリやファイルを、コンテナ内のパスにマッピングする方法です。Volumeとは異なり、Bind MountのデータはDockerの管理下にありません。ホストOS上のファイルシステムに直接アクセスします。

Bind Mountを使ったコンテナ起動:
ホストOS上のディレクトリ（例: /path/to/host/redis_data）をRedisコンテナのデータディレクトリ (/data) にマッピングします。docker run -v オプションを使用しますが、host_path:container_path の形式で指定します。ホスト側のパスは絶対パスで指定する必要があります。

まず、ホストOS上にデータを保存するためのディレクトリを作成します（既に存在する場合はスキップ）。
bash
mkdir /path/to/host/redis_data # 例: ~/docker-volumes/redis_data など

次に、このディレクトリをコンテナ内の/dataにBind MountしてRedisコンテナを起動します。

bash
docker run -d --name my-redis-bind -v /path/to/host/redis_data:/data redis
* -v /path/to/host/redis_data:/data: ホストOS上の/path/to/host/redis_dataディレクトリを、コンテナ内の/dataディレクトリにBind Mountします。

コンテナが起動したら、Redis CLIでデータ操作を行い、コンテナを停止・削除してみてください。
bash
docker exec -it my-redis-bind redis-cli
127.0.0.1:6379> SET bind_key "Data is persisted using bind mount!"
OK
1227.0.0.1:6379> exit
docker stop my-redis-bind
docker rm my-redis-bind

コンテナは削除されました。ホストOS上のマッピングしたディレクトリ (/path/to/host/redis_data) を確認してみましょう。
bash
ls /path/to/host/redis_data
出力例：
dump.rdb # RDBファイルがホストOS上に保存されている
ホストOS上の指定したディレクトリにRDBファイルが生成されていることが確認できます。

次に、同じBind Mount設定で新しいコンテナを起動し、データが復旧できるか確認します。
bash
docker run -d --name my-redis-bind-new -v /path/to/host/redis_data:/data redis
docker exec -it my-redis-bind-new redis-cli
127.0.0.1:6379> GET bind_key
"Data is persisted using bind mount!" # データが残っている！
127.0.0.1:6379> exit
Bind Mountでも同様にデータが永続化されることが確認できました。

VolumeとBind Mountの使い分け

  • Volume:

    • 推奨: Docker公式が最も推奨する永続化方法です。
    • 管理: Docker CLI (docker volumeコマンド）で作成、管理、検査が容易です。
    • 場所: Dockerが管理するストレージ領域に保存されるため、ホストOS上の具体的なパスを意識する必要は基本的にありません（ただし、inspectで見れます）。
    • 移植性: ホストOS間のパスの差異を気にせず、Composeファイルなどで同じVolume名を指定するだけで済みます。
    • パフォーマンス: ボリュームドライバーによっては、ホストOSのファイルシステムよりも最適なパフォーマンスが得られる場合があります。
    • ユースケース: データベースのデータ、メッセージキューのデータなど、永続化が必須で、コンテナのライフサイクルから独立して管理したいデータに最適です。特に本番環境での利用に適しています。

  • Bind Mount:

    • 管理: ホストOSのファイルシステムに直接アクセスするため、ホストOSのツール（ファイルエクスプローラー、CLIコマンド）で簡単に内容を確認・編集できます。
    • 場所: ホストOS上の任意のパスを指定できます。
    • 移植性: ホストOS上の絶対パスを指定するため、環境が変わるとパスを修正する必要がある場合があります。
    • パフォーマンス: 基本的にはホストOSのファイルシステム性能に依存します。
    • ユースケース:
      • 開発中にコードをコンテナ内部にマウントして、ホスト側でコードを編集したらコンテナ内に即座に反映されるようにする場合。
      • ホストOS上の設定ファイルをコンテナに読み込ませる場合。
      • ホストOS上のログディレクトリをコンテナにマウントしてログを収集する場合。
      • ホストOS上の特定のディレクトリをコンテナからアクセスしたい場合。
    • Redisのデータ永続化にはVolumeが推奨されますが、開発中にホストOS上でRDBやAOFファイルを直接確認したい場合などにはBind Mountも利用可能です。

Redisのデータ永続化には、Volume Mount を使うのが一般的で推奨される方法です。本記事の以降の説明でも、主にVolumeを使った方法を中心に解説します。

ポートマッピング

簡単なRedisコンテナの起動で確認したように、デフォルトではRedisコンテナはコンテナ内部のポート（デフォルト: 6379/tcp）でのみリクエストを受け付けます。ホストOSやホストOSからアクセスできる別のマシンからRedisコンテナに接続するためには、ホストOSのポートとコンテナのポートを紐づける「ポートマッピング」が必要です。

ポートマッピングは、docker runコマンドの-pオプションで行います。書式は ホストOSポート:コンテナポート または ホストOS IPアドレス:ホストOSポート:コンテナポート です。

-p オプションの解説

docker run -p host_port:container_port image_name

このコマンドは、ホストOSのhost_portに来たTCP通信を、コンテナのcontainer_portへ転送するように設定します。

ポートマッピングを使ったコンテナ起動

ホストOSの6379番ポートを、Redisコンテナのデフォルトポートである6379番ポートにマッピングして起動します。永続化のためにVolumeも併せて指定します。

bash
docker run -d --name my-redis-port -p 6379:6379 -v redis_data:/data redis
* -p 6379:6379: ホストOSのTCPポート6379を、コンテナのTCPポート6379にマッピングします。

コンテナが起動したら、docker psコマンドのPORTS列を確認します。
bash
docker ps
出力例：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
abcdef123456 redis "docker-entrypoint.s…" 1 minute ago Up 1 minute 0.0.0.0:6379->6379/tcp my-redis-port
0.0.0.0:6379->6379/tcp と表示されていれば、ホストOSの全てのネットワークインターフェース（0.0.0.0）のポート6379が、コンテナのポート6379にマッピングされていることを示します。

異なるホストポートへのマッピング

ホストOSの6379番ポートが他のサービスで既に使用されている場合や、複数のRedisコンテナを起動したい場合などには、ホストOS側のポートを別の番号に指定できます。例えば、ホストOSの6380番ポートにマッピングする場合。

bash
docker run -d --name my-redis-port-alt -p 6380:6379 -v redis_data_alt:/data redis
* -p 6380:6379: ホストOSのTCPポート6380を、コンテナのTCPポート6379にマッピングします。
* -v redis_data_alt:/data: 別のRedisインスタンスなので、新しいVolume (redis_data_alt) を使用します。

docker psで確認すると、新しいコンテナがホストの6380番ポートにマッピングされて起動しているのがわかります。

bash
docker ps
出力例：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
abcdef123456 redis "docker-entrypoint.s…" 5 minutes ago Up 5 minutes 0.0.0.0:6379->6379/tcp my-redis-port
fedcba654321 redis "docker-entrypoint.s…" 1 minute ago Up 1 minute 0.0.0.0:6380->6379/tcp my-redis-port-alt

ホストOSからRedis CLIで接続

ポートマッピングを設定すれば、ホストOSにRedis CLIがインストールされていれば、直接コンテナ内のRedisに接続できます。

ホストOSのターミナルを開き、以下のコマンドを実行します。

bash
redis-cli -p 6379 # my-redis-port コンテナに接続
または、別のポートにマッピングしたコンテナに接続する場合。

bash
redis-cli -p 6380 # my-redis-port-alt コンテナに接続

Redis CLIのプロンプトが表示されたら、コンテナ内のRedisサーバーと対話できます。

127.0.0.1:6379> PING
PONG
127.0.0.1:6379> exit

ホストOSからアプリケーションがRedisに接続する場合も、このマッピングされたホストOSのポート（例: localhost:6379）を指定すれば接続できるようになります。

設定ファイルの利用

Redisはredis.confという設定ファイルを使って、様々な動作をカスタマイズできます。DockerでRedisを使う場合も、この設定ファイルを適用してコンテナを起動することが可能です。よくある設定としては、パスワード認証の有効化、メモリ制限、AOF永続化の有効化などがあります。

デフォルト設定の確認

Redisイメージにはデフォルトの設定ファイルが含まれています。コンテナ内でその内容を確認してみましょう。

まず、設定ファイルを確認したいコンテナを起動します（永続化とポートマッピングも有効にしておきます）。
bash
docker run -d --name my-redis-config -p 6379:6379 -v redis_data_config:/data redis

起動したコンテナ内でcatコマンドを使って設定ファイルの内容を表示します。公式Redisイメージでは、設定ファイルは通常/usr/local/etc/redis/redis.confに配置されています。

bash
docker exec my-redis-config cat /usr/local/etc/redis/redis.conf
これにより、デフォルトの設定内容が表示されます。このファイルは非常に長く、多くのコメントが含まれています。

カスタム設定ファイルの作成

デフォルト設定を変更したい場合は、ホストOS上に独自のredis.confファイルを作成します。そして、そのファイルをBind Mountを使ってコンテナ内の所定のパスにマッピングすることで、コンテナ起動時にカスタム設定を読み込ませます。

例として、ホストOSのホームディレクトリにmy-redis.confという名前で設定ファイルを作成するとします。

bash
mkdir ~/docker-redis-config
そのディレクトリ内にmy-redis.confファイルを作成し、以下のような設定を記述してみましょう。ここでは、パスワード認証を有効にし、AOF永続化を有効にする設定を追加します。

“`bash

~/docker-redis-config/my-redis.conf の内容例

Redisのデフォルトポート

port 6379

パスワード認証を有効化

requirepass your_strong_password_here

AOF永続化を有効化

appendonly yes

AOFファイル名の指定 (任意)

appendfilename “appendonly.aof” # デフォルトと同じ

永続化ファイルの保存先ディレクトリ (Dockerコンテナ内のパス)

このパスはVolumeまたはBind MountでホストOSにマッピングする必要がある

dir /data

RDB永続化の設定 (デフォルトで有効だが、AOFと併用する場合の挙動に注意)

save 900 1

save 300 10

save 60 10000

メモリ制限 (例: 1GB)

maxmemory 1gb

メモリ制限に達した時の挙動 (例:揮発性キーをLRUで削除)

maxmemory-policy volatile-lru

``
**注意点**:dir /data`の設定はデフォルトでも有効ですが、これがVolumeまたはBind MountでホストOS上のディレクトリにマッピングされていることが重要です。

Bind Mountを使った設定ファイルの適用

作成したカスタム設定ファイル (~/docker-redis-config/my-redis.conf) を、Redisコンテナが設定ファイルを読み込むパス (/usr/local/etc/redis/redis.conf) にBind Mountします。

さらに、Redisコンテナは起動時にどの設定ファイルを使うかを指定する必要があります。公式RedisイメージのEntrypointスクリプトは、引数として設定ファイルのパスを受け取ると、その設定ファイルを使ってRedisサーバーを起動します。

以下のコマンドで、Volumeによるデータ永続化と、Bind Mountによるカスタム設定ファイルの適用を同時に行います。

bash
docker run -d --name my-redis-custom-config \
-p 6379:6379 \
-v redis_data_custom:/data \
-v ~/docker-redis-config/my-redis.conf:/usr/local/etc/redis/redis.conf \
redis redis-server /usr/local/etc/redis/redis.conf
* -v redis_data_custom:/data: データ永続化のためのVolume Mountです。
* -v ~/docker-redis-config/my-redis.conf:/usr/local/etc/redis/redis.conf: ホストOS上のmy-redis.confファイルを、コンテナ内の/usr/local/etc/redis/redis.confにBind Mountします。
* redis: 使用するDockerイメージです。
* redis-server /usr/local/etc/redis/redis.conf: コンテナ起動時に実行するコマンドです。デフォルトのコマンドを上書きし、指定した設定ファイルを使ってredis-serverを起動します。

コンテナが起動したら、ポートマッピングしたホストのポート（6379）からRedis CLIで接続してみます。

bash
redis-cli -p 6379
パスワード認証を有効にしたため、パスワードなしではコマンドを実行できません。

127.0.0.1:6379> PING
(error) NOAUTH Authentication required.

AUTHコマンドでパスワードを指定して認証します。

127.0.0.1:6379> AUTH your_strong_password_here
OK
127.0.0.1:6379> PING
PONG # 認証成功！
127.0.0.1:6379> SET my_auth_key "This requires auth"
OK
127.0.0.1:6379> GET my_auth_key
"This requires auth"
127.0.0.1:6379> exit
設定ファイルで指定したパスワード認証が有効になっていることが確認できました。また、AOF永続化を有効にしたため、/dataディレクトリ（Volumeにマッピングされている）にはappendonly.aofファイルも生成されているはずです。

bash
docker exec my-redis-custom-config ls /data
出力例：
appendonly.aof # AOFファイルが生成されている
dump.rdb # RDBファイルも（デフォルト設定で）生成されている場合がある

よく使う設定項目

redis.confファイルには非常に多くの設定項目がありますが、DockerでRedisを使う際によくカスタマイズされる項目は以下の通りです。

  • port: リッスンするポート番号。Dockerコンテナ内ではデフォルトの6379で問題ありません。ホストOSへのマッピングは-pで行います。
  • bind: リッスンするIPアドレス。デフォルトは全てのインターフェース（bind 127.0.0.1 ::1 または設定なしで全てのインターフェース）ですが、Dockerコンテナ内では通常0.0.0.0で問題ありません。コンテナ間の通信やホストからの接続はDockerネットワークが管理します。
  • requirepass: パスワード認証を有効にし、パスワードを設定します。セキュリティ上非常に重要です。
  • maxmemory: 使用できる最大メモリ量を設定します。メモリ不足を防ぐために設定することが推奨されます。
  • maxmemory-policy: maxmemoryに達したときのキーの削除ポリシーを設定します（例: allkeys-lru, volatile-ttlなど）。
  • appendonly yes/no: AOF永続化を有効/無効に設定します。
  • appendfilename: AOFファイル名を指定します（デフォルトはappendonly.aof）。
  • save: RDB永続化のスナップショット保存条件を設定します。
  • dir: 永続化ファイル（RDB, AOF）を保存するディレクトリを指定します。Dockerコンテナ内では/dataが一般的です。ここをVolumeやBind Mountで永続化領域にマッピングします。
  • logfile: ログファイルのパスを指定します。Docker環境では、ログを標準出力/標準エラー出力に出力し、docker logsで確認するのが一般的です。この場合、設定ファイルでlogfileをコメントアウトするか、/dev/stdoutまたは/dev/stderrに設定します。公式イメージのデフォルト設定ではlogfile ""となっており、標準出力にログが出力されるようになっています。

これらの設定項目を理解し、必要に応じてカスタム設定ファイルを作成することで、Dockerで起動するRedisの動作を細かく制御できます。

Docker Composeを使った管理

単一のRedisコンテナを起動・管理するのはdocker runコマンドで十分ですが、実際のアプリケーションではWebサーバー、アプリケーションサーバー、データベース、メッセージキューなど、複数のサービスが連携して動作することが一般的です。このような複数のコンテナで構成されるアプリケーション全体を定義・管理するには、Docker Compose を使うのが非常に便利です。

Docker Composeは、YAMLファイル (docker-compose.yml) に複数サービスの構成、ネットワーク、ボリュームなどを定義し、docker compose up (または docker-compose up) という単一のコマンドで一括して起動・停止・管理できるようにするツールです。

なぜDocker Composeを使うのか

  • 設定の一元化: アプリケーションを構成する全てのサービスのイメージ、ポート、ボリューム、ネットワークなどの設定をdocker-compose.ymlファイル一つにまとめられます。
  • 環境の再現性: 開発環境、テスト環境、本番環境など、異なる環境で同じdocker-compose.ymlファイルを使うことで、同じアプリケーションスタックを簡単に再現できます。
  • 管理の簡素化: 複雑なdocker runコマンドを複数実行する代わりに、単一のdocker compose upコマンドで全てを起動できます。
  • サービス間の連携: Composeファイル内で定義されたサービスは、デフォルトで同じDockerネットワークに参加するため、サービス名（コンテナ名）を使って互いにアクセスできます。

docker-compose.yml ファイルの基本構造

docker-compose.ymlファイルはYAML形式で記述されます。基本的な構造は以下のようになります。

“`yaml
version: ‘3.8’ # Docker Compose ファイルフォーマットのバージョンを指定

services: # アプリケーションを構成する各サービスを定義するセクション
service_name_1: # サービス名 (コンテナ名としても使われる)
image: image_name:tag # 使用するDockerイメージ
ports: # ポートマッピング (ホスト:コンテナ)
– “host_port:container_port”
volumes: # ボリュームまたはBind Mount (ホスト/ボリューム名:コンテナ)
– “volume_name_or_path:container_path”
environment: # 環境変数
– KEY=value
networks: # 参加するネットワーク
– my_network
depends_on: # 依存関係 (このサービスを起動する前に起動すべきサービス)
– another_service
# その他、restart, logging, healthcheckなどの設定

service_name_2:
# service_name_1 と同様の設定…

volumes: # サービスで使用するボリュームを定義するセクション (任意)
volume_name_1:
volume_name_2:

networks: # サービスで使用するネットワークを定義するセクション (任意)
my_network:
driver: bridge
“`

単純なRedisサービスの定義

RedisサービスをDocker Composeで定義してみましょう。以下の内容でdocker-compose.ymlファイルを作成します。

“`yaml

docker-compose.yml

version: ‘3.8’

services:
redis: # サービス名: redis
image: redis:latest # Redisの公式最新イメージを使用
ports:
– “6379:6379” # ホストの6379ポートをコンテナの6379ポートにマッピング
volumes:
– redis_data:/data # redis_dataという名前のVolumeをコンテナの/dataにマッピング

volumes: # このセクションでredis_dataボリュームを定義
redis_data:
“`

このファイルでは、以下の設定を行っています。
* version: '3.8': Composeファイルフォーマットのバージョンを指定しています。
* services: サービス定義の開始です。
* redis: サービス名をredisとしています。これにより、コンテナ名なども[プロジェクト名]_redis_[番号]のようになります。
* image: redis:latest: 使用するイメージはDocker Hubの公式redisイメージの最新版です。
* ports: - "6379:6379": ホストOSの6379番ポートとコンテナの6379番ポートをマッピングします。
* volumes: - redis_data:/data: redis_dataという名前のVolumeを、コンテナ内の/dataディレクトリにマッピングします。これはRedisの永続化データを保存するための設定です。
* volumes: redis_data:: servicesセクションの下で定義したredis_dataという名前のVolumeを、このvolumesセクションで実体として定義しています。Composeはこの定義を見て、Volumeが存在しない場合は自動的に作成します。

docker compose up と docker compose down

docker-compose.ymlファイルを保存したディレクトリで、以下のコマンドを実行します。

“`bash
docker compose up -d

または docker-compose up -d (旧バージョン)

``
*up:docker-compose.ymlファイルで定義されたサービスを起動します。
*-d`: デタッチドモードで実行し、バックグラウンドでコンテナを起動します。

このコマンドを実行すると、Docker Composeは以下の処理を行います。
1. redis_dataというVolumeが存在しない場合、自動的に作成します。
2. redis:latestイメージがローカルに存在しない場合、Docker Hubからプルします。
3. redisサービスとして定義された設定に基づき、Redisコンテナを作成・起動します。ポートマッピングとVolume Mountも設定されます。

コンテナが起動したか確認するには、通常のdocker psコマンドを使います。コンテナ名にはComposeプロジェクト名（デフォルトではdocker-compose.ymlファイルがあるディレクトリ名）が付与されます。

bash
docker ps
出力例（ディレクトリ名がmyprojectの場合）：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
abcdef123456 redis:latest "docker-entrypoint.s…" 30 seconds ago Up 29 seconds 0.0.0.0:6379->6379/tcp myproject_redis_1

ホストOSからRedis CLIで接続できるか確認してみましょう。

bash
redis-cli -p 6379
127.0.0.1:6379> PING
PONG
127.0.0.1:6379> exit

サービスの実行を停止し、コンテナを削除するには、以下のコマンドを実行します。

“`bash
docker compose down

または docker-compose down (旧バージョン)

``downコマンドは、Composeファイルで定義されたサービスに関連するコンテナ、ネットワーク、Volume（外部定義されていないもの）を停止・削除します。**デフォルトではVolumeは削除されません**。Volumeも削除したい場合は-v`オプションを付けます。

bash
docker compose down -v # コンテナとVolumeを削除

Docker Composeを使った永続化、ポートマッピング、設定ファイルの適用方法

上記の例で見たように、Composeファイル内でportsとvolumesキーを使うことで、それぞれポートマッピングとVolume Mountによる永続化を設定できます。

設定ファイルの適用もComposeで簡単に行えます。volumesキーで、ホストOS上の設定ファイルをコンテナ内の設定ファイルパスにBind Mountします。さらに、commandキーを使って、起動時に読み込む設定ファイルを指定します。

例えば、前述のカスタム設定ファイル (~/docker-redis-config/my-redis.conf) を適用する場合のdocker-compose.ymlは以下のようになります。

“`yaml

docker-compose.yml with custom config

version: ‘3.8’

services:
redis:
image: redis:latest
ports:
– “6379:6379”
volumes:
– redis_data_config:/data # データ永続化用Volume
# 設定ファイルをBind Mount
– ~/docker-redis-config/my-redis.conf:/usr/local/etc/redis/redis.conf
command: redis-server /usr/local/etc/redis/redis.conf # 指定した設定ファイルで起動

volumes:
redis_data_config:
``
このファイルを保存してdocker compose up -d`を実行すれば、カスタム設定（例: パスワード認証）が有効なRedisコンテナが起動します。接続時にはパスワードが必要になります。

他のアプリケーション（例: Webサーバー）と連携させる構成例

Docker Composeの真価は、複数のサービスを連携させる場合に発揮されます。例えば、シンプルなWebアプリケーション（Python + Flaskなど）がバックエンドとしてRedisを利用するような構成を考えます。

“`yaml

docker-compose.yml – Web + Redis example

version: ‘3.8’

services:
web: # Webアプリケーションサービス
build: ./web_app # web_appディレクトリにあるDockerfileを使ってイメージをビルド
ports:
– “5000:5000” # ホストの5000ポートをWebアプリの5000ポートにマッピング
volumes:
– ./web_app:/app # ホストのコードをコンテナにBind Mount (開発時など)
environment:
# Redisへの接続情報を環境変数で渡す
REDIS_HOST: redis # サービス名 ‘redis’ でアクセス可能
REDIS_PORT: 6379
depends_on:
– redis # redisサービスが起動するまで待つ

redis: # Redisサービス
image: redis:latest
ports:
– “6379:6379” # オプション: ホストからもアクセスしたい場合に指定
volumes:
– redis_data:/data # データ永続化用Volume

volumes:
redis_data:
``
この例では、webサービスはredisサービスに依存しており、depends_onでその依存関係を指定しています。両サービスは同じデフォルトネットワークに所属するため、webサービスからredisサービスへは、ホスト名としてサービス名であるredisを指定するだけでアクセスできます（例:REDIS_HOST: redis`）。

このように、Docker Composeを使うことで、Redisを他のサービスと連携させたアプリケーションスタック全体を、一つのファイルで管理できるようになり、開発やデプロイが非常に効率的になります。

Redisの高度な使い方とDocker

ここでは、Docker環境でRedisのより高度な機能を使う際の基本的な考え方や設定について触れます。

パスワード認証 (requirepass)

セキュリティの観点から、インターネットに公開したり、信頼できないネットワークからアクセスされる可能性があるRedisインスタンスでは、必ずパスワード認証を有効にする必要があります。設定ファイル (redis.conf) でrequirepassディレクティブを使用するのが最も一般的な方法です。

requirepass your_strong_password_here
この設定を有効にしたredis.confファイルをBind MountしてRedisコンテナを起動する方法は、前述の「設定ファイルの利用」セクションで解説しました。

クライアントからの接続時には、AUTH your_strong_password_hereコマンドを実行して認証を行う必要があります。多くのRedisクライアントライブラリでは、接続時にパスワードを指定するオプションが用意されています。

注意点: パスワードは設定ファイルに平文で記述されます。ファイルへのアクセス権限を適切に設定し、.gitignoreなどでバージョン管理システムから除外するなどの対策が必要です。Docker Secretのような仕組みを利用してパスワードを安全に管理することも検討すべきです（これはDocker SwarmやKubernetesなどのオーケストレーションツールで利用されることが多いです）。

メモリ制限 (maxmemory)

Redisはインメモリデータベースであるため、使用可能なメモリ量に上限を設定しないと、ホストのメモリを枯渇させてしまう可能性があります。maxmemoryディレクティブを使って、Redisインスタンスが使用できる最大メモリ量を設定することが強く推奨されます。

maxmemory 1gb # 例: 最大1GBまで使用を許可
この設定もredis.confファイルで行い、Bind Mountでコンテナに適用します。maxmemory-policyを設定することで、上限に達した際にどのキーを削除するかを制御できます。

Redis Sentinel (高可用性)

Redis Sentinelは、Redisの高可用性ソリューションです。複数のRedisインスタンス（マスターとレプリカ）を監視し、マスターに障害が発生した際に自動的にレプリカをマスターに昇格させるフェイルオーバー機能を提供します。

DockerでSentinel構成を組む場合、通常は複数のコンテナ（マスター、複数のレプリカ、複数のSentinel）を起動し、それぞれ適切に設定して連携させる必要があります。

  • 構成要素:

    • マスターRedis: 書き込みを受け付けるメインのインスタンス。
    • レプリカRedis: マスターのデータを複製するインスタンス（旧名称: Slave）。
    • Redis Sentinel: マスターとレプリカを監視し、フェイルオーバーを調整するプロセス。通常は最低3台のSentinelインスタンスを起動します。

  • Dockerでの実現:

    • 各Redisインスタンス（マスター、レプリカ）とSentinelそれぞれに対して、個別のコンテナを起動します。
    • 各コンテナは同じDockerネットワークに参加させ、互いにサービス名やIPアドレスで通信できるようにします。
    • Redisインスタンスは、永続化設定が必要です。
    • レプリカは、起動時にマスターを指定するか、設定ファイルでマスターのホストとポートを指定します。
    • Sentinelは、設定ファイルで監視対象のマスターの名前（Sentinel内で定義する任意名）、ホスト、ポート、そして必要なSentinelの数を指定します。
    • 通常、Docker Composeを使ってこれらの複数のサービス構成を定義・管理するのが一般的です。

Sentinel構成は複雑になるため、詳細なComposeファイルの例は省略しますが、基本的には複数のサービス定義（redis-master, redis-replica-1, redis-sentinel-1, redis-sentinel-2, redis-sentinel-3など）をdocker-compose.ymlファイルに記述し、それぞれの設定ファイル（Bind Mountで適用）で連携情報を設定する形になります。

Redis Cluster (分散処理)

Redis Clusterは、複数のRedisノードにデータを自動的にシャーディング（分散）させることで、スケーラビリティと可用性を同時に実現するソリューションです。データセットが非常に大きい場合や、多数のクライアントからのアクセスを分散させたい場合に利用されます。

Redis Clusterは、最低6台のノード（3台のマスターとそれぞれのレプリカ）で構成するのが一般的です。各ノードはクラスタープロトコルを使って互いに通信し、データの所在やノードの状態を共有します。

  • 構成要素:

    • 複数のRedisノード。各ノードはクラスターモードで起動します。
    • ノード間で通信するためのポート（デフォルトポート+10000）。
    • クラスターの作成やノードの管理を行うためのツール (redis-cliのclusterコマンドやRubyスクリプト)。

  • Dockerでの実現:

    • クラスターを構成する各ノード（マスター候補、レプリカ候補）ごとに個別のRedisコンテナを起動します。
    • 各コンテナは同じDockerネットワークに参加させます。
    • 各コンテナはクラスターモード (cluster-enabled yes設定) で起動します。
    • 各コンテナはデータ永続化設定が必要です。
    • 全てのノードコンテナを起動した後、いずれかのノードに対してredis-cli --cluster create ...のようなコマンドを実行し、ノードをクラスターとして結合し、スロットを割り当てる必要があります。
    • Sentinelと同様、Docker Composeを使って複数ノードの構成を定義・管理するのが一般的です。

Redis ClusterもSentinelと同様に複数コンテナの連携が必要な複雑な構成であり、設定や管理の手間が増えます。Docker Composeでの定義も、複数のRedisサービスと初期化用のコマンドサービスなどを含むものになります。

補足: Redis Stackイメージ (redis/redis-stack-server) のように、Redisサーバーに加えてRedisJSON, RediSearchなどのモジュールや、Redis InsightのようなGUIツールが同梱されているイメージも存在します。特定のモジュールを利用したい場合は、これらのイメージの使用も検討できます。ただし、イメージサイズが大きくなる可能性があります。

Dockerを使ったRedisのベストプラクティス

Docker環境でRedisを本番運用したり、より効率的に利用したりするためのベストプラクティスをいくつか紹介します。

  • 永続化は必須: 本番環境でデータストアとしてRedisを利用する場合、必ずVolume Mountによる永続化設定を行いましょう。Bind Mountは開発やテスト目的には便利ですが、Volumeの方が管理が容易で推奨されます。
  • ポートマッピングは必要最低限に: ホストOSからRedisにアクセスする必要がない場合（例: 同じComposeファイル内の別サービスからのみアクセスする場合）、ポートマッピング(-p)は不要です。Dockerネットワーク内でサービス名を使ってアクセスすれば十分です。ホストOSにポートを公開すると、セキュリティリスクが増加します。
  • セキュリティ設定の実施:
    • requirepassによるパスワード認証は必ず有効にするべきです。強力なパスワードを設定しましょう。
    • もしインターネットにRedisポートを公開する必要がある場合は、ファイアウォールでアクセス元IPアドレスを制限するなどの対策を講じましょう。
    • Redisのデフォルトポート(6379)以外を使用するのも、単純なポートスキャン攻撃からの対策として有効な場合があります。
    • rename-commandを使って危険なコマンド（FLUSHALL, CONFIGなど）の名前を変更したり無効にしたりすることも検討できます。
  • リソース制限の設定: docker runコマンドやDocker Composeで、コンテナが使用できるCPUやメモリのリソース上限を設定しましょう。これにより、Redisが暴走してホストOSのリソースを枯渇させるのを防ぎ、他のサービスへの影響を最小限に抑えることができます。
    • docker run --memory 1g --cpus 0.5 ...
    • Docker Composeファイルでの記述例：
      yaml
      services:
      redis:
      image: redis:latest
      deploy: # Docker Swarm や Kubernetes では別の設定方法になる
      resources:
      limits:
      cpus: '0.5' # 0.5コア
      memory: 1G # 1GB
  • 適切なイメージタグの選択: redis:latestタグは常に最新版を指しますが、予期しないバージョンアップによる互換性の問題が発生する可能性があります。本番環境では、redis:6.2.7のように特定の安定バージョンを指定することをお勧めします。
  • ロギングの集中管理: Dockerコンテナのログは標準出力/標準エラー出力に出力されるのが一般的です。これらのログをDockerのロギングドライバー機能を使って、外部のロギングシステム（例: Elasticsearch, Fluentd, Splunkなど）に集約することで、監視やトラブルシューティングが容易になります。redis.confでlogfileを/dev/stdoutまたは/dev/stderrに設定するか、デフォルト設定のlogfile ""のままでログが標準出力に出るようにしておきましょう。
  • 監視の導入: Redisインスタンスのメトリクス（メモリ使用量、接続数、コマンド処理速度など）を監視システム（例: Prometheus + Grafana）で収集・可視化することで、パフォーマンスの問題や潜在的なボトルネックを早期に発見できます。Redis Exporterのようなツールを別のコンテナとして起動し、Redisコンテナを監視させる構成がDocker環境ではよく採用されます。
  • バックアップ戦略: 永続化されたVolumeのデータを定期的にバックアップする仕組みを構築しましょう。Volumeの実体があるホストOS上のパスを直接バックアップしたり、RedisのBGSAVEコマンドでRDBファイルを生成し、そのファイルを外部ストレージにコピーしたりする方法があります。AOFファイルも重要なバックアップ対象です。
  • コンテナオーケストレーション: 単一ホスト上での少数のコンテナであればdocker runやDocker Composeで管理できますが、複数のホストにまたがる大規模な環境や、高度なスケーリング・ローリングアップデート・自己回復機能が必要な場合は、KubernetesやDocker Swarmといったコンテナオーケストレーションプラットフォームの利用を検討しましょう。これらのプラットフォームは、Volume管理、シークレット管理、リソース制限、自動再起動などの機能をより洗練された形で提供します。

トラブルシューティング

DockerでRedisを使っている際に遭遇しうる一般的な問題と、その切り分け・解決方法をいくつか紹介します。

  • コンテナが起動しない:

    • docker logs <コンテナ名またはID>: まずコンテナのログを確認しましょう。起動失敗の原因（設定ファイルのエラー、ポートの競合、メモリ不足など）が記録されている可能性が高いです。
    • docker ps -a: コンテナが作成されたがすぐに終了している場合、STATUSがExitedとなっています。これもログを確認する手がかりになります。
    • docker inspect <コンテナ名またはID>: コンテナの詳細情報を確認できます。特にState.ExitCodeやState.Errorを見ると、終了コードやエラーメッセージがわかることがあります。

  • ホストOSや他のコンテナからRedisに接続できない:

    • ポートマッピングの確認: docker psで、RedisコンテナのPORTS列が正しくマッピングされているか確認します。0.0.0.0:6379->6379/tcpのように表示されているか確認します。ホストOSのファイアウォールで指定したポートがブロックされていないかも確認します。
    • Redisの設定確認: redis.confのbind設定が0.0.0.0など、コンテナ外部からの接続を受け付ける設定になっているか確認します（公式イメージのデフォルト設定であれば問題ないはずです）。
    • ネットワークの問題: Dockerネットワークが正しく設定されているか確認します。特に、複数のコンテナ間で通信する場合、同じネットワークに所属している必要があります。Docker Composeを使っている場合は、デフォルトで同じネットワークになります。
    • 認証の確認: パスワード認証（requirepass）が有効になっている場合、接続時に正しいパスワードを指定しているか確認します。
    • docker exec -it <redisコンテナ名> redis-cli: コンテナ内部からredis-cliで自身に接続できるか試します（redis-cli -h 127.0.0.1 -p 6379）。これができれば、Redisサーバー自体は起動しています。次に、同じネットワーク内の別のコンテナからRedisコンテナのIPアドレス（またはサービス名）で接続できるか試します。

  • データが永続化されない:

    • Volume/Bind Mountの設定ミス: docker runコマンドやComposeファイルのvolumes設定が正しく、コンテナ内のRedisデータディレクトリ（デフォルトは/data）にマッピングされているか確認します。docker inspect <コンテナ名>でMountsセクションを確認し、設定が反映されているか確認します。
    • Volume/Bind Mountの場所の確認: 指定したVolumeまたはホストOS上のディレクトリに、.rdbファイルや.aofファイルが実際に生成されているか確認します。Bind Mountの場合はホストのファイルシステムを直接確認できます。Volumeの場合はdocker volume inspect <volume名>でMountpointを確認できます（ただし、直接操作は推奨されません）。
    • Redisの永続化設定: Redisの設定ファイル (redis.conf) で、RDB (saveディレクティブ) やAOF (appendonly yes) が有効になっているか確認します。デフォルトではRDBは有効ですが、条件を満たさないとファイルが生成されない場合があります。
    • 権限の問題: Bind Mountを使用している場合、ホストOS上のディレクトリのパーミッションが、コンテナ内のRedisプロセス（通常はredisユーザー）が書き込みできる権限になっているか確認します。Docker Volumeの場合は通常この問題は発生しにくいです。

  • Redisの認証エラー:

    • AUTHコマンドで指定しているパスワードが、設定ファイル (requirepass) で設定したパスワードと一致しているか確認します。
    • 設定ファイルが正しくコンテナに適用されているか（Bind Mountの設定、commandオプションでの設定ファイル指定など）確認します。
    • クライアントライブラリでパスワードを指定する方法が正しいか確認します。

  • メモリ不足:

    • docker logs <redisコンテナ名>で、Redisがメモリ不足に関するログを出力していないか確認します。
    • Redis CLIでINFO memoryコマンドを実行し、used_memoryやmaxmemoryの値を確認します。
    • ホストOS全体のメモリ使用量を確認します。
    • maxmemory設定を適切に行い、必要に応じてホストOSに十分なメモリを割り当てるか、Redisインスタンス数をスケールアウトすることを検討します。Dockerのリソース制限 (--memoryオプションやComposeファイルのresources.limits.memory) を設定している場合は、その上限値が適切か確認します。

これらのトラブルシューティング手順は、問題の原因を特定するための出発点となります。詳細なエラーメッセージやログを注意深く確認することが、解決への近道です。

まとめ

この記事では、Dockerを使ってRedisを効率的に利用するための様々な方法を詳細に解説しました。

まず、DockerとRedisそれぞれの基本的な概要と、両者を組み合わせるメリットについて触れました。次に、docker runコマンドを使った簡単なRedisコンテナの起動方法、Redis CLIへの接続方法、そしてコンテナの停止・削除方法を学びました。

最も重要な要素の一つであるデータの永続化については、Volume MountとBind Mountの2つの方法を比較し、それぞれの手順と使い分けについて詳しく説明しました。RedisのRDBとAOFという2つの永続化メカニズムが、Dockerの永続化機能とどのように連携するかも理解しました。

さらに、ポートマッピングによってホストOSからRedisコンテナにアクセス可能にする方法や、カスタムのredis.conf設定ファイルをコンテナに適用してRedisの動作をカスタマイズする方法を学びました。特に、パスワード認証やメモリ制限といった重要な設定の適用方法を確認しました。

複数サービスで構成されるアプリケーションを効率的に管理するために、Docker Composeを使ったRedisサービスの定義、起動、停止方法を解説しました。Composeファイルを使って永続化や設定ファイルを記述する方法、そして他のサービスとの連携方法についても触れました。

Redisの高度な使い方として、パスワード認証、メモリ制限に加え、高可用性を実現するRedis Sentinelと分散処理を実現するRedis ClusterをDockerで実現する際の基本的な考え方にも言及しました。

最後に、Docker環境でRedisを本番運用する際のベストプラクティス（セキュリティ、リソース制限、監視、バックアップなど）と、一般的なトラブルシューティングの方法を紹介しました。

Dockerを使うことで、Redisの環境構築は格段に容易になり、開発から本番まで一貫した環境を維持しやすくなります。コンテナのポータビリティ、スケーラビリティ、リソース分離といったDockerのメリットを活かしつつ、Redisの高性能なデータストア機能を活用できるのです。

この記事で学んだ知識を基に、あなたのアプリケーション開発や運用において、Dockerを使ったRedis環境を自信を持って構築・管理できるようになることを願っています。

次のステップとして、以下の内容に挑戦してみることをお勧めします。

  • Docker Composeを使って、WebアプリケーションとRedisを連携させた簡単なアプリケーションを実際に構築してみる。
  • Redis SentinelやRedis ClusterのDocker Compose構成例を調べて、より高可用性・スケーラビリティのある構成を試してみる。
  • Dockerのロギングドライバーや監視ツール（Prometheusなど）を使って、Docker環境のRedisをより高度に監視・管理する方法を学ぶ。
  • Kubernetesなどのコンテナオーケストレーションプラットフォーム上でRedisをデプロイ・運用する方法について学ぶ。

DockerとRedisの組み合わせは、現代のアプリケーション開発において非常に強力な武器となります。ぜひ積極的に活用してください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール