Docker HubでRedisをサクッと起動する方法

By /

はい、承知いたしました。Docker HubからRedisをサクッと起動する方法について、詳細な説明を含む約5000語の記事を作成します。

Docker HubでRedisをサクッと起動する方法：完全ガイド

1. はじめに：RedisとDockerの出会い

現代のアプリケーション開発において、データ管理は非常に重要な要素です。特に、高速な読み書きが求められるキャッシュや、リアルタイム処理を支えるメッセージキューなど、メインのデータベースとは異なる特性を持つデータストアの需要が高まっています。その中で、インメモリデータ構造ストアとして絶大な人気を誇るのが Redis です。

1.1 Redisとは？その魅力と用途

Redisは、Remote Dictionary Serverの略称で、オープンソースのインメモリデータ構造ストアです。キー・バリュー形式を基本としながらも、文字列、リスト、セット、ソート済みセット、ハッシュ、ビットマップ、HyperLogLog、ジオスペーシャルインデックスなど、多様なデータ構造を扱うことができます。

Redisの最大の魅力は、その驚異的なパフォーマンスにあります。データをメモリ上に保持するため、ディスクベースのデータベースと比較して非常に高速なアクセスが可能です。また、シンプルなコマンドセットと柔軟なデータ構造により、様々な用途で活用されています。

代表的なRedisの用途としては、以下のようなものがあります。

  • キャッシュ: データベースへのアクセス負荷を軽減するために、頻繁に読み込まれるデータをRedisにキャッシュします。高速なデータアクセスにより、アプリケーションの応答性能を向上させます。
  • セッションストア: Webアプリケーションのユーザーセッション情報をRedisに保存します。スケーラブルなアプリケーションにおいて、複数のサーバー間でセッション情報を共有するために広く利用されます。
  • メッセージキュー/ブローカー: Pub/Sub（Publish/Subscribe）機能やリスト型を利用して、非同期処理のためのメッセージキューとして機能させます。タスクキューやイベント通知などに活用されます。
  • ランキングシステム: ソート済みセット（Sorted Set）を利用して、リアルタイムのランキング集計や表示を行います。
  • リアルタイム分析: ストリーム型やHyperLogLogなどを利用して、リアルタイムのデータ収集や分析を行います。
  • 分散ロック: セット型などを用いて、複数のアプリケーションインスタンス間で共有リソースへのアクセスを制御するための分散ロックを実装します。

このように、Redisは単なるキャッシュにとどまらず、様々なモダンなアプリケーションのバックエンドとして不可欠な存在となっています。

1.2 Dockerとは？なぜDockerでRedisなのか

一方で、Redisのようなミドルウェアを開発環境や本番環境にセットアップするには、OSへのインストール、設定ファイルの編集、依存関係の解決など、多くの手間と時間がかかる場合があります。特に、異なるプロジェクトで異なるバージョンのRedisが必要な場合や、開発チームの各メンバーが同じ環境を簡単に再現したい場合など、環境構築の課題は少なくありません。

ここで登場するのが Docker です。Dockerは、アプリケーションとその依存関係をコンテナと呼ばれる軽量でポータブルな単位にパッケージ化し、実行するためのプラットフォームです。コンテナはホストOSから隔離されており、特定のOSや環境に依存せず、どこでも同じように動作することが保証されます。

なぜDockerを使うとRedisの起動が「サクッと」できるのでしょうか？

  1. 環境構築の手間削減: Dockerイメージには、Redis本体と実行に必要な全てのライブラリや設定があらかじめ含まれています。ユーザーは複雑なインストール手順を踏む必要がなく、docker runというシンプルなコマンド一つでRedis環境を立ち上げられます。
  2. 一貫性と再現性: Dockerイメージを使えば、開発者間や開発環境、ステージング環境、本番環境といった異なる環境間でも、全く同じバージョンのRedis環境を簡単に再現できます。これにより、「自分の環境では動いたのに」といった問題を減らすことができます。
  3. 分離性: 各Redisインスタンスはコンテナとして独立して動作します。これにより、複数のRedisインスタンスを同じホスト上で実行したり、他のアプリケーションとの依存関係による競合を避けることができます。
  4. ポータビリティ: 作成したDockerイメージや設定ファイル（後述のDocker Compose）を共有することで、チームメンバーや別の環境へ簡単にRedis環境を移動させることができます。
  5. 管理の簡素化: Dockerコマンドを使えば、Redisコンテナの起動、停止、削除、再起動、ログ確認などが容易に行えます。

このように、DockerはRedisを利用する上での様々な課題を解決し、非常に手軽かつ効率的な方法を提供します。

1.3 この記事で学ぶこと

この記事では、Dockerを使ったRedisの起動に焦点を当て、以下の内容を詳細に解説していきます。

  • Docker Hubから公式Redisイメージを取得する方法
  • docker runコマンドを使った基本的なRedisコンテナの起動方法
  • ポートマッピング、データ永続化、設定ファイルの適用、パスワード設定など、Redisを実用的に使うための各種docker runオプション
  • Docker Composeを使ったより宣言的で管理しやすいRedis環境の構築方法
  • DockerでRedisを運用する上でのセキュリティ上の考慮事項
  • 起動したRedisコンテナの管理とトラブルシューティング

この記事を読み終える頃には、あなたはDockerを使って様々な設定のRedisインスタンスを自在に起動・操作できるようになっているでしょう。さあ、Dockerを使ったRedisの世界に飛び込みましょう！

2. 記事を読む上での前提条件

この記事は、読者が以下の基本的な準備と知識を持っていることを前提としています。

  • Dockerのインストール: ご自身のOS（Windows, macOS, Linux）にDocker Engineがインストールされ、正しく動作していること。必要であれば、公式ドキュメントを参考にインストールを完了させてください。
  • 基本的なコマンドライン操作: ターミナルやコマンドプロンプトを使って基本的なコマンド（ディレクトリ移動、ファイルの作成/編集、コマンド実行など）を実行できること。
  • インターネット接続: Docker Hubからイメージをダウンロードするためにインターネットに接続できる環境が必要です。

これらの準備ができていれば、記事の各ステップをスムーズに進めることができます。

3. Docker Hubの理解：Redis公式イメージを探る

3.1 Docker Hubとは？

Docker Hubは、Dockerイメージを共有するための公式レジストリサービスです。世界中の開発者が作成・公開した様々なアプリケーションやミドルウェアのDockerイメージがホストされています。ほとんどの主要なオープンソースソフトウェアや商用ソフトウェアの公式イメージが提供されており、これらを利用することで環境構築の手間を劇的に削減できます。

Docker Hubで公開されているイメージは、大きく分けて以下の2種類があります。

  • 公式イメージ (Official Images): Docker社と連携した信頼できるパブリッシャー（プロジェクト本体など）によって提供される高品質でセキュリティが考慮されたイメージです。例えば、Ubuntu, Node.js, Python, MySQL, そしてRedisなど、多くの人気ソフトウェアの公式イメージが存在します。これらは通常、ベストプラクティスに従って構築されており、安心して利用できます。
  • コミュニティイメージ (Community Images): 世界中のDockerユーザーが作成・公開したイメージです。非常に多様なイメージが存在しますが、公式イメージに比べて信頼性や保守状況を確認する必要があります。

3.2 Redis公式イメージ

Docker HubでRedisイメージを探す場合、まずは公式イメージを利用するのが最も推奨される方法です。公式イメージはredisという名前で提供されています。

Docker Hubのウェブサイト (https://hub.docker.com/) で「redis」と検索すると、公式イメージが表示されます。このページでは、イメージの概要、サポートされているタグ（バージョン）、利用方法、設定方法などの詳細な情報が提供されています。

Redis公式イメージには、様々なバージョン（タグ）が用意されています。

  • latest: 最新安定版を指します。特別な理由がなければこれで十分です。
  • 特定のバージョン番号 (6.2.7, 7.0.5, 7.2.0 など): 特定のバージョンを使用したい場合に指定します。本番環境など、バージョンの固定が必要な場合に使われます。
  • 特定のバージョン番号とOS (7.2.0-bullseye, 6.2.7-alpine など): 使用するベースOSを指定できます。alpineタグは非常に軽量なAlpine Linuxをベースにしており、イメージサイズが小さく、リソース消費を抑えたい場合に人気があります。

通常は、redisまたはredis:latestタグから始めるのが最も簡単です。必要に応じて特定のバージョンや軽量版を選択します。

4. DockerでRedisを「サクッと」起動する基本コマンド

いよいよDockerを使ってRedisを起動してみましょう。まずは最も基本的なコマンドから始めます。

4.1 イメージの取得：docker pull

Dockerコンテナを実行するには、まずそのコンテナの元となるイメージが必要です。イメージはDocker Hubのようなコンテナレジストリから取得できます。イメージを取得するコマンドは docker pull です。

Redisの公式イメージを取得するには、以下のコマンドを実行します。

bash
docker pull redis

このコマンドを実行すると、DockerはデフォルトでDocker Hubからredis:latestイメージを探してダウンロードします。もし特定のバージョンが必要な場合は、タグを指定します。例えば、Redis 6.2.7の公式イメージを取得したい場合は以下のようになります。

bash
docker pull redis:6.2.7

既にローカルにイメージが存在する場合、このコマンドは最新版を確認し、必要に応じて更新部分だけをダウンロードします。

ダウンロードが完了すると、「Status: Downloaded newer image for redis:latest」のようなメッセージが表示されます。

取得したイメージは以下のコマンドで確認できます。

bash
docker images

出力例：
REPOSITORY TAG IMAGE ID CREATED SIZE
redis latest f0e0c1f0e0c1 2 weeks ago 120MB
ubuntu latest abc123abc123 3 weeks ago 70MB
redisという名前のイメージがリストに表示されていれば、取得は成功です。

4.2 コンテナの起動：docker runの基本

イメージを取得したら、そのイメージからコンテナを起動します。コンテナを起動する最も基本的なコマンドが docker run です。

最もシンプルなRedisコンテナの起動コマンドは以下のようになります。

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

このコマンドの意味を解説します。

  • docker run: 指定したイメージから新しいコンテナを作成し、実行します。
  • --name my-redis: 起動するコンテナにmy-redisという名前を付けます。名前を付けることで、後続のDockerコマンド（停止、削除、接続など）でコンテナを指定しやすくなります。名前を付けない場合、Dockerがランダムな名前を生成します。
  • -d: detachedモードの略です。コンテナをバックグラウンドで実行します。このオプションを付けないと、コンテナの標準出力が現在のターミナルに表示され続け、ターミナルが専有されてしまいます。バックグラウンド実行は、サーバーとして動作するミドルウェアによく使われるモードです。
  • redis: どのイメージからコンテナを作成・実行するかを指定します。ここでは先ほど取得したredisイメージ（デフォルトはlatestタグ）を指定しています。

このコマンドを実行すると、Dockerはredisイメージからコンテナを作成し、バックグラウンドで起動します。コマンド実行後、コンテナIDが表示されます。

bash
abcdef1234567890abcdef1234567890abcdef1234567890

4.3 起動したコンテナの確認

コンテナが正常に起動したかを確認するには、以下のコマンドを使います。

bash
docker ps

このコマンドは、現在実行中のコンテナのリストを表示します。

出力例：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
abcdef123456 redis "docker-entrypoint.s…" 5 seconds ago Up 4 seconds 6379/tcp my-redis

出力には、コンテナID (abcdef123456...)、使用しているイメージ (redis)、実行中のコマンド (docker-entrypoint.sh redis-server)、作成からの時間、ステータス (Up 4 seconds は「4秒前から起動中」という意味)、ポート情報、そしてコンテナ名 (my-redis) が表示されます。

ステータスが Up ... となっていれば、コンテナは正常に起動しています。

docker ps -a コマンドを使うと、実行中でないコンテナも含めた全てのコンテナが表示されます。エラーで起動に失敗した場合などは、docker ps -a で状態を確認し、docker logs <container_name_or_id> でログを確認すると原因がわかることがあります。

4.4 Redisコンテナへの接続と基本操作

コンテナ内でRedisが起動したら、クライアントからそのRedisサーバーに接続して操作してみましょう。コンテナ内で実行中のアプリケーションにアクセスする方法はいくつかありますが、ここでは最も簡単な方法として、コンテナ内部でRedis CLI (redis-cli) を実行する方法を使います。

docker exec コマンドは、既に実行中のコンテナ内で指定したコマンドを実行するために使います。

my-redisコンテナ内でredis-cliを実行するには、以下のコマンドを使います。

bash
docker exec -it my-redis redis-cli

このコマンドの意味を解説します。

  • docker exec: 実行中のコンテナ内でコマンドを実行します。
  • -it: -i (インタラクティブモード) と -t (擬似ターミナル割り当て) の組み合わせです。これにより、コンテナ内のコマンドと対話的にやり取りできるようになります。redis-cliのようにユーザーからの入力を受け付けるコマンドを実行する場合に必要です。
  • my-redis: コマンドを実行したいコンテナの名前（またはID）を指定します。
  • redis-cli: コンテナ内で実行したいコマンドです。RedisイメージにはRedisサーバー本体だけでなく、クライアントであるredis-cliも含まれています。

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

127.0.0.1:6379>

これで、コンテナ内のRedisサーバーに対してコマンドを実行できるようになりました。いくつか基本的なRedisコマンドを試してみましょう。

  • サーバーが応答するか確認：
    127.0.0.1:6379> PING
    PONG
    PONGと返ってくれば正常に動作しています。
  • キーを設定：
    127.0.0.1:6379> SET mykey "Hello from Docker Redis!"
    OK
  • キーを取得：
    127.0.0.1:6379> GET mykey
    "Hello from Docker Redis!"
  • 全てのキーを表示：
    127.0.0.1:6379> KEYS *
    1) "mykey"

Redis CLIから抜けるには、exit または quit と入力します。

127.0.0.1:6379> exit

これで、最も基本的なDockerを使ったRedisの起動と操作が完了しました。「サクッと」起動できる感覚をつかめたでしょうか？

ただし、この方法ではコンテナを削除するとRedisに保存したデータは失われますし、ホストOS上の別のアプリケーションや、ホストOS外のクライアントからこのRedisに直接アクセスすることはできません。実用的なRedis環境を構築するには、さらにいくつかのオプションが必要です。次のセクションでは、それらの重要なオプションについて詳しく見ていきましょう。

5. Docker runコマンドの詳細オプション

実用的なRedis環境をDockerで構築するためには、データの永続化や外部からのアクセス、設定のカスタマイズなどが不可欠です。docker runコマンドには、これらの要件を満たすための様々なオプションが用意されています。

5.1 ポートマッピング：外部からのアクセスを可能にする -p

デフォルトでは、Dockerコンテナは独自のネットワーク空間を持ち、ホストOSや他のコンテナからは直接アクセスできません。コンテナ内で実行されているサービス（今回の場合はRedisサーバー、デフォルトポートは6379）にホストOSや外部ネットワークからアクセスできるようにするには、「ポートマッピング」という設定が必要です。

ポートマッピングは -p オプションを使って行います。

5.1.1 ポートマッピングの基本

-p オプションの基本構文は ホストポート:コンテナポート です。Redisのデフォルトポートは6379なので、ホストOSの6379ポートとコンテナの6379ポートをマッピングする場合、以下のようになります。

bash
docker run --name my-redis-port -d -p 6379:6379 redis

  • --name my-redis-port: コンテナ名をmy-redis-portとします。
  • -d: バックグラウンドで実行します。
  • -p 6379:6379: ホストOSの6379番ポートへのアクセスを、コンテナ内の6379番ポートに転送します。

このコマンドで起動したRedisコンテナには、ホストOSからlocalhost:6379または127.0.0.1:6379でアクセスできるようになります。

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

ホストOS側のポートは、コンテナ側のポートと異なっていても構いません。例えば、ホストOSの8000番ポートでRedisにアクセスしたい場合は、以下のようになります。

bash
docker run --name my-redis-port-alt -d -p 8000:6379 redis

この場合、ホストOSからはlocalhost:8000でRedisに接続することになります。ホストOS上で複数のRedisコンテナを起動し、それぞれ異なるポートで公開したい場合などに便利です。

5.1.3 ポートマッピング後の接続方法

ポートマッピングを行ったコンテナには、ホストOSにインストールされたRedis CLIや、他のプログラミング言語のRedisクライアントライブラリから接続できます。

例えば、ホストOS上でRedis CLIがインストールされている場合、my-redis-portコンテナ（ポートマッピング -p 6379:6379）に接続するには、以下のコマンドを実行します。

bash
redis-cli -h 127.0.0.1 -p 6379

my-redis-port-altコンテナ（ポートマッピング -p 8000:6379）に接続する場合は、ポート番号を8000に指定します。

bash
redis-cli -h 127.0.0.1 -p 8000

プログラムから接続する場合も同様に、ホストアドレス（通常は127.0.0.1またはlocalhost）とマッピングしたホストポートを指定します。

5.2 データ永続化：大切なデータを失わないために -v

前述の基本的な起動方法では、Redisコンテナを停止または削除すると、その中に保存されていたデータは全て失われてしまいます。これは、コンテナのファイルシステムが一時的なものだからです。データベースやデータストアとしてRedisを使う場合、データが永続化されることが不可欠です。

Dockerでデータを永続化する方法としては、主に以下の2つがあります。

  1. Docker Volume: Dockerによって管理される領域にデータを保存する方法です。Docker CLIを使って作成・管理できます。最も推奨される方法です。
  2. Bind Mount: ホストOS上の特定のディレクトリをコンテナ内のディレクトリにマウントする方法です。ホストOSのファイルシステム構造に依存しますが、設定ファイルを共有したり、開発中にソースコードをコンテナから参照したりするのに便利です。

Redisのデータ永続化には、主にVolumeを使用するのが一般的です。

5.2.1 なぜデータ永続化が必要か

Redisはデフォルトでデータをメモリ上に保持しますが、データ永続化機能（RDBスナップショットとAOFログ）により、データをディスクに書き出すことができます。これにより、Redisサーバーが再起動してもデータを復旧することが可能です。

Dockerコンテナの場合、このディスクへの書き出し先がコンテナのファイルシステム内になってしまいます。コンテナは使い捨て可能であるべきであり、重要なデータをコンテナのファイルシステムに保存するのは適切ではありません。コンテナを更新したり、別のホストに移動したり、障害発生時に再作成したりすると、ファイルシステムはリセットされてしまいデータが失われます。

そこで、コンテナの外部にある永続的なストレージ領域（VolumeやBind Mountでマウントしたホストディレクトリ）にRedisのデータ保存先を設定することで、コンテナのライフサイクルから独立してデータを保持できるようにします。

Redis公式イメージでは、データ保存ディレクトリとして /data が標準的に使われます。Redisの設定ファイル（redis.conf）で dir /data がデフォルトになっているためです。したがって、この /data ディレクトリをVolumeやBind Mountで外部にマウントするのが一般的な方法です。

5.2.2 Docker Volumeを使った永続化

Docker Volumeを使う方法は、Dockerによって管理されるため、ホストOSのファイルシステム構造に依存せず、バックアップや移行も比較的容易です。

Volumeの作成

まず、データを保存するためのVolumeを作成します。

bash
docker volume create my-redis-data

これでmy-redis-dataという名前のVolumeが作成されました。作成されたVolumeは以下のコマンドで確認できます。

bash
docker volume ls

Volumeを使ったコンテナ起動

作成したVolumeをRedisコンテナの/dataディレクトリにマウントして起動します。-v オプションを使います。-v オプションの構文は ボリューム名:コンテナ内のパス です。

bash
docker run --name my-redis-vol -d -p 6379:6379 -v my-redis-data:/data redis

  • -v my-redis-data:/data: my-redis-dataという名前のVolumeを、コンテナ内の/dataディレクトリにマウントします。

このコマンドで起動したRedisコンテナは、/dataディレクトリへの書き込み（RedisのRDBファイルやAOFファイルなど）を、ホストOS上のDocker管理領域にあるmy-redis-data Volumeに行います。コンテナを停止・削除してもVolumeはそのまま残り、同じVolumeを使って新しいコンテナを起動すれば、以前のデータを引き継ぐことができます。

Volumeの確認と管理

Volumeの実体はホストOS上のどこかに保存されていますが、その場所を知る必要は通常ありません。Dockerが管理してくれます。Volumeの詳細情報は以下のコマンドで確認できます。

bash
docker volume inspect my-redis-data

Volumeが不要になった場合は、以下のコマンドで削除できます。ただし、Volumeを削除すると、保存されていたデータは全て失われます。コンテナがVolumeを使用中の場合は削除できません。

bash
docker volume rm my-redis-data

5.2.3 Bind Mountを使った永続化（開発・テスト向け）

Bind Mountは、ホストOS上の特定のディレクトリをコンテナ内のディレクトリに直接マウントする方法です。Volumeと比較して、ホストOSのファイルシステム構造が見えてしまうためポータビリティに劣りますが、ホストOS上で直接ファイルを確認・編集できるというメリットがあります。これは開発やテストのシナリオで特に便利です。

-v オプションの構文は ホストの絶対パス:コンテナ内のパス です。ホストのパスは必ず絶対パスで指定する必要があります。

Bind Mountを使ったコンテナ起動

例えば、ホストOS上の/opt/redis/dataディレクトリをコンテナの/dataディレクトリにマウントする場合、以下のようになります。

bash
docker run --name my-redis-bind -d -p 6379:6379 -v /opt/redis/data:/data redis

ホストOS側のディレクトリ /opt/redis/data が存在しない場合、Dockerはデフォルトでそのディレクトリを作成します。ただし、パーミッションによっては問題が発生する可能性があるため、事前に手動で作成しておくことを推奨します。

この方法で起動したRedisコンテナは、データをホストOS上の/opt/redis/dataディレクトリに書き込みます。ホストOSからこのディレクトリの内容を直接確認したり、編集したりできます。

Volume vs Bind Mount

  • Volume:
    • Dockerが管理する領域にデータを保存。
    • ホストOSのファイルシステム構造に依存しない。
    • Docker CLIによる管理が容易。
    • 本番環境でのデータ永続化に推奨。
  • Bind Mount:
    • ホストOS上の特定のディレクトリにデータを保存。
    • ホストのファイルシステム構造が見える。
    • 開発中に設定ファイルやデータをホストから編集したい場合に便利。
    • パフォーマンスやセキュリティの観点から、プロダクション用途では注意が必要な場合がある。

Redisのデータ永続化には、基本的にはVolumeを使うのがベストプラクティスです。

5.2.4 Redisのデータ永続化設定（RDBとAOF）とDocker Volume

Redisは、以下の2つの方法でデータを永続化できます。

  • RDB (Redis Database): 特定の間隔でメモリ上のデータセットのスナップショットをディスクに保存します。データ損失のリスクはありますが、ファイルがコンパクトで高速なリストアが可能です。デフォルトでは、save設定に基づいて自動的にRDBファイルが /data ディレクトリに保存されます。
  • AOF (Append Only File): サーバーが受け取った書き込みコマンドをログとして追記していきます。設定によっては全ての書き込みコマンドをログするため、RDBよりデータ損失のリスクを最小限に抑えられますが、ファイルサイズは大きくなる傾向があります。AOFを有効にするには、設定ファイルで appendonly yes を指定する必要があります。AOFファイルもデフォルトでは /data ディレクトリに保存されます。

Docker VolumeやBind Mountで /data をマウントすることで、これらのRDBファイルやAOFファイルがコンテナの外部に保存され、データの永続性が確保されます。

例えば、AOFを有効にしたRedisをVolumeで起動したい場合、AOFを有効にする設定が必要です。これについては、次の「設定ファイルの指定」セクションで詳しく説明します。

5.3 設定ファイルの指定：Redisをカスタマイズする

Redisの動作は、設定ファイル redis.conf によって細かく制御できます。デフォルト設定で十分な場合もありますが、パスワード設定、メモリ上限、永続化設定、ログレベルなど、多くの設定項目を変更したい場合があります。

Dockerで起動したRedisコンテナにカスタム設定を適用する方法はいくつかありますが、最も一般的なのはホストOS上に作成した redis.conf ファイルをコンテナ内にBind Mountする方法です。

5.3.1 デフォルト設定からの変更

Redisイメージのデフォルト設定は、公式イメージのドキュメントや、実行中のコンテナ内でデフォルト設定ファイルを確認することで把握できます。

コンテナ内のデフォルト設定ファイルを確認するには、以下のコマンドを使います。（コンテナ名は適宜変更してください）

bash
docker exec my-redis redis-cli config get *
または、コンテナ内部にログインしてファイルとして確認することもできます。
“`bash
docker exec -it my-redis bash

コンテナ内部

cat /usr/local/etc/redis/redis.conf
exit # コンテナから出る
``
通常、設定ファイルは/usr/local/etc/redis/redis.conf` に配置されています。

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

ホストOS上にカスタムの redis.conf ファイルを用意し、それをコンテナ内のデフォルト設定ファイルのパスにBind Mountすることで、カスタム設定を適用できます。

例えば、ホストOS上の /opt/redis/redis.conf にカスタム設定ファイルがあるとします。これをコンテナの /usr/local/etc/redis/redis.conf にマウントしてRedisを起動する場合、以下のコマンドになります。

bash
docker run --name my-redis-conf -d -p 6379:6379 \
-v /opt/redis/data:/data \
-v /opt/redis/redis.conf:/usr/local/etc/redis/redis.conf \
redis redis-server /usr/local/etc/redis/redis.conf

解説：
* -v /opt/redis/data:/data: データ永続化のためにVolume（ここでは例としてBind Mount）をマウントしています。
* -v /opt/redis/redis.conf:/usr/local/etc/redis/redis.conf: ホストOS上のカスタム設定ファイル /opt/redis/redis.conf を、コンテナ内のデフォルト設定ファイルパス /usr/local/etc/redis/redis.conf に上書きマウントします。
* redis-server /usr/local/etc/redis/redis.conf: これが重要な部分です。docker run <image> <command> の形式で、コンテナ起動時に実行するコマンドを指定できます。Redisイメージのデフォルトの起動コマンドは単に redis-server ですが、ここでは引数としてカスタム設定ファイルのパスを明示的に渡しています。これにより、Redisサーバーはデフォルト設定ではなく、マウントしたカスタム設定ファイルを読み込んで起動します。

ホストOS側の /opt/redis/redis.conf ファイルには、必要な設定項目を記述しておきます。例えば、AOF永続化を有効にするには appendonly yes と記述します。

5.3.3 redis.confの基本的な設定項目例

カスタム設定ファイルでよく変更される項目には以下のようなものがあります。

  • bind 0.0.0.0: どのネットワークインターフェースからの接続を許可するか。Dockerコンテナ内でホストOSからのアクセスを受け付けるには、デフォルトでbind 127.0.0.1ではなくbind 0.0.0.0になっている必要があります。Redis公式イメージのデフォルト設定はbind 0.0.0.0なので、通常は変更不要です。
  • protected-mode no: 保護モードを無効にするか。bind 0.0.0.0と同時に設定すると、認証なしで外部からのアクセスを受け付ける危険な状態になるため、通常はyesにしておくべきです。ただし、Dockerネットワーク内で他のコンテナからのみアクセスし、ポートマッピングで外部に公開しない場合はnoでも構いません。
  • port 6379: Redisサーバーがリッスンするポート。Dockerでは通常デフォルトの6379を使います。
  • requirepass your_password: クライアント接続時にパスワード認証を必須にする設定。セキュリティ上非常に重要です。
  • maxmemory <size>: Redisが使用できるメモリの最大サイズ。メモリ不足によるサービス停止を防ぐために設定することが推奨されます。例: maxmemory 512mb
  • maxmemory-policy <policy>: maxmemoryに達した場合のキー削除ポリシー。noeviction（新しい書き込みを拒否）、allkeys-lru（最も長い間使われていないキーを削除）、volatile-ttl（TTLが設定されたキーの中で最も有効期限が近いものを削除）などがあります。
  • save <seconds> <changes>: RDB永続化のスナップショット取得条件。例: save 900 1 （900秒間に1回以上の変更があればスナップショットを取得）
  • appendonly yes: AOF永続化を有効にするか。
  • logfile "/var/log/redis/redis-server.log": ログファイルのパス。Docker Volumeにマウントしたディレクトリ内にログを出力するように設定することも可能です。
5.3.4 Redis公式イメージのエントリポイントとコマンド引数

Dockerイメージには「エントリポイント (Entrypoint)」と「コマンド (Command)」が設定されています。これは、コンテナが起動したときに何を実行するかを定義するものです。Redis公式イメージのエントリポイントは、スクリプト (docker-entrypoint.shなど) になっており、これがRedisサーバー (redis-server) を起動します。

docker run <image> <command> の形式で最後に指定する <command> は、イメージのデフォルトのCommandを上書きします。Redisイメージの場合、デフォルトのCommandは通常単に redis-server です。

カスタム設定ファイルをBind Mountした場合、単にファイルをマウントするだけではRedisはそれを読み込みません。Redisに「この設定ファイルを使って起動しなさい」と明示的に指示する必要があります。そのために、上記の例のように redis-server /usr/local/etc/redis/redis.conf というコマンドを docker run の最後に指定しています。これにより、コンテナ起動時にdocker-entrypoint.shスクリプトが実行され、その中で引数として渡された /usr/local/etc/redis/redis.conf を使ってredis-serverが起動される、という流れになります。

5.4 パスワード保護：セキュリティを強化する

インターネット上に公開されたRedisサーバーや、信頼できないネットワーク上にあるRedisサーバーは、認証なしで誰でもアクセスできる非常に危険な状態です。セキュリティのため、パスワードを設定することが強く推奨されます。

Redisでパスワードを設定するには、requirepass 設定項目を使います。

5.4.1 パスワード設定の重要性

Redisは非常に高速なデータストアであるため、認証なしで公開されていると、悪意のあるユーザーによって簡単にアクセスされ、データの不正取得、改ざん、削除が行われる可能性があります。また、DDoS攻撃の踏み台として悪用されるリスクも指摘されています（Memcachedなど他のインメモリストアでも同様のリスクがあります）。

特にDockerで -p オプションを使ってRedisポートをホストOSに公開する場合、ファイアウォール設定やDockerネットワーク設定でアクセス元を厳密に制限しない限り、インターネットからのアクセスも可能になってしまいます。このような状況では、パスワード設定は必須です。

5.4.2 設定ファイルによるパスワード設定

最も一般的なパスワード設定方法は、カスタム設定ファイル（redis.conf）に requirepass ディレクティブを記述することです。

/opt/redis/redis.conf ファイルに以下のように記述します。

“`ini

その他の設定…

requirepass your_very_secure_password

その他の設定…

``your_very_secure_password` の部分は、推測されにくい強力なパスワードに変更してください。

この設定ファイルをBind MountしてRedisを起動します（前述の「設定ファイルの指定」を参照）。

bash
docker run --name my-redis-pass-conf -d -p 6379:6379 \
-v /opt/redis/data:/data \
-v /opt/redis/redis.conf:/usr/local/etc/redis/redis.conf \
redis redis-server /usr/local/etc/redis/redis.conf

5.4.3 コマンドライン引数によるパスワード設定

設定ファイルを使わずに、redis-server 起動時のコマンドライン引数としてパスワードを指定する方法もあります。

bash
docker run --name my-redis-pass-arg -d -p 6379:6379 \
-v /opt/redis/data:/data \
redis redis-server --requirepass "your_very_secure_password"

この場合、redis-server コマンドの引数として --requirepass "パスワード" を渡しています。これは手軽ですが、パスワードが docker ps コマンドなどで見えてしまう可能性があるため、セキュリティ上のリスクがあります。設定ファイルを使う方が推奨されます。

5.4.4 環境変数によるパスワード設定（公式イメージの機能）

Redis公式イメージは、パスワード設定のために環境変数 REDIS_PASSWORD をサポートしています。これは、設定ファイルをマウントする手間を省きたい場合に便利な方法です。

bash
docker run --name my-redis-pass-env -d -p 6379:6379 \
-v my-redis-data:/data \
-e REDIS_PASSWORD="your_very_secure_password" \
redis

  • -e REDIS_PASSWORD="your_very_secure_password": コンテナ内に REDIS_PASSWORD という環境変数を設定します。Redis公式イメージのエントリポイントスクリプトは、この環境変数を確認し、requirepass 設定を自動的に適用してRedisサーバーを起動します。

この方法は、特に開発環境や一時的な用途で手軽にパスワードを設定したい場合に便利です。パスワードは docker inspect <container_name> コマンドで確認できてしまう点には注意が必要です。

5.4.5 パスワード付きRedisへの接続

パスワードが設定されたRedisに接続する場合、クライアント側でもパスワードを指定する必要があります。

Redis CLIで接続する場合、-a オプションでパスワードを渡すか、接続後に AUTH コマンドを実行します。

-a オプションを使う方法：
bash
redis-cli -h 127.0.0.1 -p 6379 -a your_very_secure_password

接続後に AUTH コマンドを使う方法：
“`bash
redis-cli -h 127.0.0.1 -p 6379

プロンプトが表示されたら

AUTH your_very_secure_password

OK と表示されれば認証成功

PING
PONG
“`

プログラミング言語のクライアントライブラリを使う場合も、通常は接続オプションとしてパスワードを指定できるようになっています。

注意: docker run コマンドの引数や環境変数にパスワードを直接記述する方法は、コマンド履歴やDockerの設定ファイルに残るため、セキュリティ上は完全ではありません。よりセキュアな方法としては、Docker Secrets（Docker SwarmやKubernetesで使用可能）などを利用することが検討されますが、これはより高度なトピックとなります。開発環境や小規模な環境であれば、設定ファイルをBind Mountする方法か、環境変数による方法でも十分な場合があります。

5.5 メモリ制限：リソースを管理する --memory

Redisはインメモリデータストアであるため、使用するメモリ量は重要なリソースです。無制限にメモリを使用すると、ホストOS全体のパフォーマンスに影響を与えたり、他のアプリケーションの動作を妨げたりする可能性があります。Dockerでは、コンテナが使用できるリソース（CPUやメモリなど）に制限を設けることができます。

Redisコンテナが使用できるメモリの最大値を制限するには、--memory オプションを使います。

5.5.1 メモリ制限の必要性

Redisが利用可能な物理メモリを超えてデータを保持しようとすると、OSのスワップが発生したり、Out Of Memory (OOM) Killerによってプロセスが強制終了されたりする可能性があります。コンテナ環境では、一つのコンテナがホストOS全体のリソースを使い尽くしてしまうことを防ぐために、リソース制限を設定することが推奨されます。

Redis自身にも maxmemory という設定項目があり、メモリ使用量に上限を設けることができますが、これはあくまでRedisプロセス自身のメモリ管理です。Dockerの --memory 制限はOSレベルでの制限であり、Redisプロセスだけでなく、コンテナ内で実行される全てのプロセス（例えばバックグラウンドセーブを行う子プロセスなど）のメモリ使用量の合計に適用されます。両方を設定するのが最も確実な方法ですが、通常はDockerの --memory 制限だけでも効果があります。

5.5.2 --memoryオプションの使い方

--memory オプションには、使用できるメモリの最大サイズを指定します。単位としては、バイト (b), キロバイト (k), メガバイト (m), ギガバイト (g) などが使えます。

例：メモリ使用量を512MBに制限する場合
bash
docker run --name my-redis-mem -d -p 6379:6379 \
-v my-redis-data:/data \
--memory 512m \
redis

このコンテナは、合計で最大512MBのメモリを使用できます。もしRedisがこれを超えるメモリを使用しようとすると、コンテナが停止される可能性があります。

5.5.3 Redisのmaxmemory設定との連携

Dockerの --memory 制限とRedisの maxmemory 設定は、どちらか一方だけを設定することも、両方を設定することも可能です。

  • --memory のみ設定: OSレベルでの制限。Redisプロセスだけでなく、コンテナ内の他のプロセス（フォークされた子プロセスなど）も含まれます。Redisは自身のmaxmemory設定を知らないため、制限に達するまでメモリを使い続ける可能性があります。制限を超えるとOSによってコンテナが終了させられる可能性があります。
  • maxmemory のみ設定: Redisプロセス自身が管理するメモリ上限。maxmemory-policy に基づいてキーの削除などが行われます。ただし、バックグラウンドセーブなどで一時的にメモリ使用量が増加した場合、コンテナ全体のメモリがOSレベルの制限（もしあれば）を超える可能性はあります。
  • 両方設定: 最も推奨される方法です。Redisの maxmemory をDockerの --memory 制限より少し小さく設定することで、Redis自身が積極的にメモリを管理し、Dockerによる強制終了を避けつつ、コンテナ全体のリソース使用量も制限できます。例えば、--memory 512m に設定する場合、redis.conf で maxmemory 450mb のように設定すると良いでしょう。

5.6 再起動ポリシー：コンテナのライフサイクルを管理する --restart

Dockerコンテナは、エラーが発生したり、Dockerデーモンが再起動したりした場合に停止することがあります。本番環境などでRedisコンテナを常に稼働させておきたい場合は、コンテナが終了した場合の再起動ポリシーを設定しておくことが重要です。

再起動ポリシーは --restart オプションで設定します。

5.6.1 再起動ポリシーの種類

--restart オプションには、以下の値が指定できます。

  • no (デフォルト): コンテナが終了しても自動的に再起動しません。
  • on-failure[:max-retries]: コンテナがゼロ以外の終了コードで終了した場合（エラー終了）にのみ再起動します。max-retriesで再起動を試みる最大回数を指定できます。
  • always: コンテナが終了したらいつでも（正常終了かエラー終了かに関わらず）自動的に再起動します。Dockerデーモンが起動した際にもコンテナを起動します。
  • unless-stopped: コンテナが停止したらいつでも再起動します。ただし、Dockerデーモン起動時にユーザーが明示的に停止したコンテナは起動しません。ユーザーが手動でdocker stopまたはdocker rm -fするまで再起動を続けます。
5.6.2 --restartオプションの使い方

本番環境などで、Redisコンテナを常に起動させておきたい場合は、always または unless-stopped を設定するのが一般的です。

例：常に再起動させる場合
bash
docker run --name my-redis-restart -d -p 6379:6379 \
-v my-redis-data:/data \
--restart always \
redis

この設定により、何らかの原因でmy-redis-restartコンテナが停止しても、Dockerは自動的に再起動を試みます。

alwaysとunless-stoppedの違いは、Dockerデーモン起動時に、前回ユーザーが手動で停止したコンテナを起動するかどうかです。開発中などで一時的にコンテナを止めたいが、サーバー再起動時には勝手に起動してほしくない場合は unless-stopped が便利です。本番環境でサーバー起動と同時にRedisも起動してほしい場合は always が適しています。

6. Docker Composeを使ったRedisの起動と管理

これまで見てきたように、docker run コマンドには様々なオプションがあり、Redisの設定に応じてコマンドラインが長くなりがちです。また、複数のコンテナ（例えば、アプリケーションサーバーとRedisなど）を組み合わせて使う場合、それぞれのdocker runコマンドを管理するのは煩雑になります。

このような複数のコンテナで構成されるアプリケーションを管理するために便利なのが Docker Compose です。Docker Composeを使うと、コンテナの定義、ネットワーク設定、ボリューム設定などをYAMLファイル（通常docker-compose.ymlという名前）に記述し、単一のコマンドでまとめて起動・停止・管理できます。

6.1 Docker Composeとは？

Docker Composeは、複数のコンテナからなるアプリケーションを定義・実行するためのツールです。YAMLファイルを使って、アプリケーションを構成する各サービス（コンテナ）の設定（使用するイメージ、ポート、ボリューム、環境変数、依存関係など）を記述します。そして、docker-compose upというコマンド一つで、ファイルに定義された全てのサービスを起動できます。

Docker ComposeはDocker Desktopに含まれています。Linux環境では別途インストールが必要な場合がありますが、現在はDocker Engineと一緒にインストールされることが多くなっています。

6.2 docker-compose.ymlファイルの作成

Docker Composeを使うには、まずアプリケーションのルートディレクトリなどに docker-compose.yml という名前のファイルを作成します。

以下は、Docker Composeを使ってRedisコンテナを起動するための基本的な docker-compose.yml の例です。

“`yaml

docker-compose.yml

version: ‘3.8’ # Composeファイルフォーマットのバージョン

services:
redis: # サービス名（コンテナ名の一部にもなる）
image: redis:latest # 使用するDockerイメージ
container_name: my-compose-redis # コンテナ名を明示的に指定
ports:
– “6379:6379” # ポートマッピング（ホスト:コンテナ）
volumes:
– redis_data:/data # Volumeをマウント（Volume名:コンテナ内のパス）
# カスタム設定ファイルをマウントする場合:
# – ./redis.conf:/usr/local/etc/redis/redis.conf
environment: # 環境変数を設定（公式イメージのREDIS_PASSWORDなど）
# REDIS_PASSWORD: your_very_secure_password
– REDIS_PASSWORD=your_very_secure_password # パスワードを環境変数で指定
restart: unless-stopped # 再起動ポリシー

volumes:
redis_data: # 使用するVolumeの定義（servicesセクションの外に記述）
driver: local # ドライバー指定（デフォルトはlocal）
“`

このファイルは、servicesというトップレベルのキーを持ち、その中に起動したいサービスを名前（ここではredis）を付けて定義します。各サービスの下に必要な設定を記述していきます。

6.3 docker-compose.ymlの内容解説

上記のdocker-compose.ymlファイルの内容を詳しく見ていきましょう。

  • version: '3.8': 使用するComposeファイルフォーマットのバージョンを指定します。新しいバージョンでは利用できる機能が増えます。特に理由がなければ最新の安定版を指定します。
  • services:: アプリケーションを構成する各サービスを定義するセクションです。
  • redis:: サービス名です。ここではRedisサービスなのでredisという名前にしています。この名前は、同じComposeファイル内で定義された他のサービスからこのサービスにアクセスする際のホスト名としても使われます。また、コンテナ名のプレフィックスとしても使われます（例: myproject_redis_1、container_nameで上書き可能）。
  • image: redis:latest: このサービスに使用するDockerイメージを指定します。docker pull redis:latest と同じ意味です。特定のバージョンを使いたい場合はredis:7.2.0のように指定します。
  • container_name: my-compose-redis: 起動するコンテナに付ける名前を明示的に指定します。指定しない場合、Composeはディレクトリ名とサービス名を組み合わせた名前を自動生成します。
  • ports:: ポートマッピングを設定します。リスト形式で記述します。
    • - "6379:6379": ホストOSの6379ポートをコンテナの6379ポートにマッピングします。docker run -p 6379:6379 と同じ意味です。
  • volumes:: データ永続化のためにVolumeまたはBind Mountを設定します。リスト形式で記述します。
    • - redis_data:/data: redis_dataという名前のVolumeをコンテナ内の/dataディレクトリにマウントします。Volume名はvolumes:セクションで別途定義する必要があります。
    • # - ./redis.conf:/usr/local/etc/redis/redis.conf: コメントアウトされていますが、Bind Mountで設定ファイルをマウントする例です。カレントディレクトリにあるredis.confをコンテナの/usr/local/etc/redis/redis.confにマウントします。ホストのパスは相対パス(.)で指定できますが、実行するディレクトリに注意が必要です。
  • environment:: コンテナ内に設定する環境変数を指定します。リスト形式またはマップ形式で記述できます。
    • - REDIS_PASSWORD=your_very_secure_password: REDIS_PASSWORDという環境変数に値を設定します。Redis公式イメージはこの環境変数を見てパスワードを設定します。
  • restart: unless-stopped: コンテナの再起動ポリシーを設定します。docker run --restart unless-stopped と同じ意味です。
  • volumes: (最下部): servicesセクションで使用するVolumeを定義するセクションです。
    • redis_data:: servicesセクションで指定したVolume名です。
    • driver: local: 使用するVolumeドライバー。デフォルトはlocalで、特別な理由がなければ変更する必要はありません。

6.4 Docker Composeによる起動と停止

docker-compose.ymlファイルが準備できたら、そのファイルがあるディレクトリでコマンドを実行します。

コンテナの起動

docker-compose.ymlファイルに定義された全てのサービスをバックグラウンドで起動するには、以下のコマンドを実行します。

bash
docker-compose up -d

  • docker-compose up: docker-compose.ymlファイルを読み込み、定義されたサービスを作成・起動します。
  • -d: detachedモード。コンテナをバックグラウンドで実行します。このオプションを付けないと、全てのコンテナのログがターミナルに表示され続け、ターミナルが専有されます。

初めて実行する場合、Docker Composeは必要なイメージ（この場合はredis:latest）をDocker Hubから自動的にダウンロードします。その後、Volumeを作成し、コンテナを作成・起動します。

起動したコンテナは、通常のdocker psコマンドで確認できます。

bash
docker ps

出力例：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
abcdef123456 redis:latest "docker-entrypoint.s…" 10 seconds ago Up 9 seconds 0.0.0.0:6379->6379/tcp, :::6379->6379/tcp my-compose-redis
指定したコンテナ名 (my-compose-redis) のコンテナが起動していることがわかります。

ポートマッピングやパスワードを設定していれば、それらを使ってRedisに接続できます。（パスワードを設定した場合の接続方法は前述の5.4.5を参照）。

コンテナの停止と削除

docker-compose.ymlファイルに定義された全てのサービスを停止するには、以下のコマンドを実行します。

bash
docker-compose stop

このコマンドはコンテナを停止しますが、削除はしません。停止したコンテナはdocker ps -aで確認できます。再開するには再びdocker-compose up -dを実行します。

定義されたサービス（コンテナ）とデフォルトで作成されたネットワークを削除するには、以下のコマンドを実行します。

bash
docker-compose down

docker-compose down はコンテナとネットワークを削除しますが、Volumeはデフォルトでは削除されません。Volumeも同時に削除したい場合は、-vオプションを付けます。

bash
docker-compose down -v
注意: -v オプションを付けて down を実行すると、Redisに保存されていたデータが全て失われます。本当にVolumeが必要ない場合のみ使用してください。

6.5 Docker Composeを使うメリット

Docker Composeを使う主なメリットは以下の通りです。

  • 宣言的な定義: アプリケーションの構成要素（サービス、ネットワーク、ボリュームなど）をYAMLファイルという宣言的な形式で記述できます。これにより、構成が分かりやすく、管理しやすくなります。
  • 単一コマンドでの管理: docker-compose up, docker-compose down, docker-compose start, docker-compose stop, docker-compose restart, docker-compose logs など、単一のコマンドで複数のコンテナのライフサイクルをまとめて管理できます。
  • 再現性: docker-compose.ymlファイルを共有すれば、誰でも同じアプリケーション環境を簡単に構築・再現できます。
  • 依存関係の解決: 複数のサービス間に依存関係がある場合（例: アプリケーションサーバーがRedisより先に起動してはいけない）、depends_onなどの設定を使って起動順序を制御できます。
  • 複雑な設定の簡素化: ポートマッピング、ボリュームマウント、環境変数設定など、docker runコマンドで長くなりがちなオプションを構造化して記述できます。

単一のRedisコンテナを起動するだけでもComposeは便利ですが、特にWebアプリケーションとデータベース、Redisキャッシュ/キューといった複数のコンテナが必要なアプリケーションを開発・運用する際に、Docker Composeはその真価を発揮します。

7. Dockerを使ったRedis運用におけるセキュリティ考慮事項

Dockerを使うことでRedisの起動は容易になりますが、セキュリティについて適切に考慮しないと、意図せずデータを危険に晒してしまう可能性があります。特に、本番環境や公開ネットワーク上でRedisコンテナを運用する場合には、以下の点に注意が必要です。

7.1 パスワード設定は必須

前述の通り、パスワード認証を有効にすることは最も基本的なセキュリティ対策です。requirepass設定を行うか、公式イメージがサポートするREDIS_PASSWORD環境変数を使用してください。推測されにくい、強力なパスワードを設定することが重要です。

7.2 ポート公開の範囲を限定する

-pオプションでホストOSのポートとRedisコンテナのポートをマッピングすると、ホストOSにアクセスできる全てのクライアントからRedisにアクセスできるようになります。

  • インターネットに公開する場合: ホストOSのファイアウォール（iptables, firewall-cmd, Windows Firewallなど）を設定し、Redisポート（デフォルト6379）へのアクセスを特定のIPアドレスやネットワーク範囲に限定してください。
  • ローカルネットワーク内でのみ使用する場合: ポートマッピングを127.0.0.1:6379:6379のようにホスト側のIPアドレスを指定することで、ローカルホストからのみアクセス可能にできます。
    bash
    docker run --name my-redis-local -d -p 127.0.0.1:6379:6379 redis
  • Dockerネットワーク内で他のコンテナからのみ使用する場合: アプリケーションコンテナとRedisコンテナを同じカスタムDockerネットワークに接続し、Redisコンテナにポートマッピングを設定しないことで、ホストOSや外部からのアクセスを完全にブロックできます。アプリケーションコンテナからは、サービス名（Docker Composeの場合）やコンテナ名を使ってRedisにアクセスできます。これは最もセキュアな方法の一つです。

7.3 Dockerネットワークの利用

Docker Composeで複数のサービスを定義すると、デフォルトでそれらのサービスは内部的なDockerネットワークに接続されます。このネットワーク内では、サービス名をホスト名として他のサービスにアクセスできます（例: アプリケーションコンテナからredis:6379でRedisに接続）。この場合、Redisコンテナのports設定を削除すれば、外部にポートが公開されず、内部ネットワークからのアクセスのみに限定できます。

“`yaml

セキュアなRedis構成例（Docker Compose）

version: ‘3.8’

services:
app: # 例：アプリケーションサービス
image: your_app_image
ports:
– “80:80” # アプリケーションのポートのみ外部に公開
environment:
REDIS_HOST: redis # redisというサービス名でアクセス
REDIS_PORT: 6379
REDIS_PASSWORD: ${REDIS_PASSWORD} # 環境変数からパスワードを読み込む
depends_on:
– redis # redisサービスが起動してからappサービスを起動

redis: # Redisサービス
image: redis:latest
container_name: my-secure-redis
# ports: # ポートマッピングは設定しない（外部に公開しない）
volumes:
– redis_data:/data
environment:
REDIS_PASSWORD: ${REDIS_PASSWORD} # パスワードは環境変数で設定
restart: unless-stopped

volumes:
redis_data:

環境変数 REDIS_PASSWORD は .env ファイルなどに記述する

例: .env ファイルに REDIS_PASSWORD=your_very_secure_password と記述

``
この構成では、アプリケーションコンテナだけがRedisコンテナと同じネットワークに属しており、サービス名redisを使ってアクセスします。Redisコンテナのポートは外部に公開されていないため、セキュリティが向上します。パスワードは環境変数で注入し、Docker Composeの機能（${VAR}）でホストOSや.envファイルから読み込むと、docker-compose.yml`ファイルに直接パスワードを書かずに済みます。

7.4 最新かつ信頼できるイメージの使用

Docker Hubの公式イメージは、セキュリティパッチやバグ修正が定期的に適用されています。常に最新の安定版タグ（latestや最新バージョン番号タグ）のイメージを使用することで、既知の脆弱性リスクを低減できます。また、出所の不明なイメージを使用することは避けてください。

8. Dockerで起動したRedisの管理とトラブルシューティング

DockerでRedisコンテナを起動・運用する上で、コンテナの基本的な操作や、問題発生時の対処法を知っておくことは重要です。

8.1 コンテナの基本操作（停止、起動、削除）

起動中のコンテナを操作する基本的なコマンドです。コンテナ名はdocker psコマンドで確認できます。

  • 停止: 起動中のコンテナを停止します。graceful shutdown（正常終了処理）が行われます。
    bash
    docker stop my-redis
    Docker Composeを使っている場合は、docker-compose stopで定義されている全てのサービスを停止します。

  • 起動: 停止中のコンテナを再開します。
    bash
    docker start my-redis
    Docker Composeを使っている場合は、停止中のサービスを起動するにはdocker-compose start redisのようにサービス名を指定するか、あるいはdocker-compose up -dを実行します（既に存在するコンテナは再開されます）。

  • 削除: 停止中のコンテナを削除します。コンテナと関連付けられていたコンテナ内のファイルシステム（Bind MountやVolumeがマウントされていない部分）は完全に削除されます。
    bash
    docker rm my-redis
    起動中のコンテナを強制的に削除するには-fオプションを付けますが、通常はstopしてからrmするのが推奨です。
    bash
    docker rm -f my-redis # 強制削除
    Docker Composeを使っている場合は、docker-compose downで定義されている全てのサービス（コンテナとネットワーク）を削除します。Volumeも削除する場合は-vオプションを付けます。

8.2 ログの確認：何が起きているかを知る

コンテナ内で何が起きているか、特にエラー発生時にはログを確認することが不可欠です。Redisサーバーの標準出力や標準エラー出力は、Dockerのログ機能で確認できます。

bash
docker logs my-redis
このコマンドは、コンテナの起動から現在までのログ全てを表示します。

リアルタイムでログを追跡するには-fオプションを付けます。
bash
docker logs -f my-redis

Docker Composeを使っている場合は、以下のコマンドでサービス名を指定してログを確認できます。
bash
docker-compose logs redis
docker-compose logs -f redis # リアルタイム追跡
docker-compose logs をサービス名を指定せずに実行すると、全てのサービスのログが表示されます。

Redisの起動エラー、設定ファイルのエラー、メモリ関連のエラーなどは、これらのログに出力されることが多いため、問題解決の第一歩となります。

8.3 コンテナ内部の調査

コンテナ内部のファイル構成や、特定のプロセスがどのように実行されているかなどを調査したい場合があります。docker execコマンドを使えば、実行中のコンテナ内でシェルコマンドを実行できます。

例えば、コンテナ内のファイルリストを確認するには：
bash
docker exec my-redis ls -l /data
設定ファイルが正しくマウントされているか確認するには：
bash
docker exec my-redis cat /usr/local/etc/redis/redis.conf

このように、コンテナ内部の状態を調べることがトラブルシューティングに役立ちます。

8.4 一般的なトラブルシューティング

DockerでRedisを起動・運用する際に遭遇しやすい一般的な問題とその対処法をいくつか紹介します。

  • ポート競合: docker run -p 6379:6379 ... でコンテナを起動しようとした際に、「Bind for 0.0.0.0:6379 failed: port is already allocated」のようなエラーが表示される。

    • 原因: ホストOSの6379ポートが既に他のプロセスやコンテナによって使用されています。
    • 対処法:
      • ホストOSでどのプロセスがポートを使用しているか調査し、そのプロセスを停止するか、他のポートを使用するように設定を変更します。（Linux: sudo netstat -tulnp | grep 6379, Windows: netstat -ano | findstr :6379, macOS: lsof -i :6379）
      • Redisコンテナを起動する際に、ホスト側のポート番号を変更します。（例: -p 6380:6379）

  • ボリュームのマウント失敗: VolumeやBind Mountが正しく機能せず、データが永続化されない、またはRedisが起動しない。

    • 原因: Volume名が間違っている、ホスト側のパスが存在しない、ホスト側のパスに対する権限がない、コンテナ内のパスが間違っているなど。
    • 対処法:
      • docker volume lsでVolumeが作成されているか確認します。
      • Bind Mountの場合、ホスト側の指定したパスが存在し、Dockerユーザーが書き込み権限を持っているか確認します。
      • docker logs <container_name>で起動ログを確認し、ファイルが見つからない、権限がないといったエラーが出ていないか確認します。
      • docker exec <container_name> ls -l <container_path> でコンテナ内のマウント先のディレクトリが意図通りになっているか確認します。

  • 設定ファイルのエラー: カスタム設定ファイルをマウントして起動したが、Redisが起動しない、または設定が反映されない。

    • 原因: 設定ファイルのパス間違い、設定ファイルの内容に構文エラーがある、redis-serverコマンドの引数に設定ファイルのパスを渡し忘れている、設定ファイルが正しくマウントされていないなど。
    • 対処法:
      • docker logs <container_name>で起動ログを確認します。Redisは設定ファイルのパースエラーなどをログに出力します。
      • docker exec <container_name> cat <container_config_path> で、コンテナ内の設定ファイルの内容が意図通りになっているか確認します（マウントが正しく行われているか）。
      • docker runコマンドの最後にredis-server <container_config_path>のように、カスタム設定ファイルのパスを明示的に渡しているか確認します。
      • 設定ファイルの内容に誤りがないか（スペルミス、無効な設定項目など）Redisの公式ドキュメントを参照しながら確認します。

  • 権限の問題: VolumeやBind MountでマウントしたディレクトリにRedisがデータを書き込めない。

    • 原因: ホスト側のディレクトリの所有者やパーミッションが、コンテナ内でRedisプロセスを実行するユーザー（通常はredisユーザーやroot）に書き込み権限を与えていない。
    • 対処法:
      • ホスト側のマウント先ディレクトリの所有者やパーミッションを、コンテナ内のRedisプロセスが書き込めるように変更します。公式Redisイメージは通常redisユーザーで実行されます。ホスト側でchownコマンドなどで所有者を変更するか、書き込み可能なパーミッション（例: chmod 777 ※セキュリティリスクに注意）を設定します。Bind Mountの場合、docker runコマンドに-u <user>:<group>オプションを付けて、コンテナ内のユーザーをホスト側のディレクトリ所有者と合わせることも可能です。

これらの基本的なトラブルシューティング手順を覚えておくと、問題発生時に迅速に対応できるようになります。

9. より発展的な使い方への展望

この記事では、Dockerを使った単一のRedisインスタンスの起動方法に焦点を当ててきましたが、Dockerはより複雑なRedis構成にも柔軟に対応できます。

  • Redis ClusterとSentinel: Redisは、スケーラビリティと高可用性のために、Cluster（シャーディング）やSentinel（フェイルオーバー）といった機能を提供しています。これらの機能も、複数のRedisコンテナとSentinelコンテナを組み合わせてDockerやDocker Composeで構築・運用することが可能です。これは複数のサービスを定義するComposeの得意とするところです。
  • 軽量なRedisイメージ（Alpine版など）: Docker HubのRedis公式イメージには、軽量なAlpine Linuxをベースにしたタグ（例: redis:latest-alpine, redis:7.2.0-alpine）が用意されています。イメージサイズが小さく、セキュリティリスクも低い傾向があるため、コンテナイメージサイズを最適化したい場合やリソースが限られた環境で利用するのに適しています。
  • カスタムイメージの作成: 特定の設定が常に必要な場合や、Redisに独自のモジュールを組み込みたい場合など、独自のDockerfileを作成してカスタムRedisイメージを構築することも可能です。これにより、docker runコマンドのオプションや設定ファイルの管理をさらに簡素化できます。

これらのトピックは本記事の範囲を超えるため詳細な説明は省きますが、Dockerを使えば、単なるキャッシュ用途から大規模な本番システムまで、様々なRedisのニーズに対応できることを示しています。

10. まとめ：DockerでRedisを最大限に活用する

この記事では、Docker HubからRedisを起動する基本的な方法から、データ永続化、ポートマッピング、設定ファイルの適用、パスワード設定、リソース制限、再起動ポリシーといった実用的なオプション、そしてDocker Composeを使った複数コンテナ管理まで、幅広く解説しました。

Dockerを使うことで、これまで手間がかかっていたRedisの環境構築が劇的に簡素化され、「サクッと」起動できるようになることがお分かりいただけたでしょう。また、Dockerの持つ分離性、一貫性、ポータビリティといった特徴は、開発、テスト、本番といった様々な環境でRedisを利用する上で大きなメリットをもたらします。

Docker Hubの公式イメージは、Redisの利用を始める上で最も簡単かつ信頼性の高い出発点です。基本的なdocker run -d redisコマンドから始め、必要に応じて-p、-v、-e、--memory、--restartといったオプションを追加していくことで、要件に合ったRedis環境を柔軟に構築できます。

複数のコンテナで構成されるアプリケーション開発においては、Docker Composeが非常に強力なツールとなります。docker-compose.ymlファイルにRedisコンテナを含むサービスの定義を記述することで、アプリケーション全体の環境構築と管理を効率化できます。

ただし、Dockerを使った運用においても、セキュリティ対策は決して疎かにできません。特にパスワード設定とポート公開範囲の制限は、外部からの不正アクセスを防ぐために必須の考慮事項です。Dockerネットワークを適切に活用することで、よりセキュアな構成を実現できます。

もし問題が発生した場合は、docker ps、docker logs、docker execといった基本的なコマンドを使ったコンテナの状態確認やログ分析が、トラブルシューティングの鍵となります。

この記事が、あなたがDockerを使ってRedisをより手軽に、そして安全に活用するための一助となれば幸いです。ぜひ様々なオプションを試して、DockerとRedisの組み合わせがもたらす開発・運用上のメリットを最大限に享受してください。

コメントする

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

上部へスクロール