はい、承知いたしました。【初心者向け】Docker Composeを使ったRedisの簡単な始め方に関する詳細な記事を作成します。約5000語を目指し、初心者の方がつまずきやすい点を丁寧に解説します。
以下に記事の内容を直接表示します。
【初心者向け】Docker Composeを使ったRedisの簡単な始め方
はじめに:なぜDocker ComposeでRedisを始めるのが簡単なの?
データベースやキャッシュストアなどのサービスを開発環境にセットアップするのは、時に面倒な作業です。OSのバージョン、依存関係、インストールパス、設定ファイルの場所… これらが複雑に絡み合い、動かすまでに多くの時間と労力を要することが少なくありません。
特に、モダンなアプリケーション開発では、複数のサービス(例えば、データベース、キャッシュ、メッセージキュー)を組み合わせて使用することが一般的です。これらのサービスをそれぞれ個別にインストールし、設定し、連携させるのは、初心者にとって高いハードルとなります。
そこで登場するのが Docker と Docker Compose です。
Dockerは、アプリケーションとその実行に必要な環境(ライブラリ、設定ファイルなど)をまとめて「コンテナ」という軽量な仮想環境に閉じ込める技術です。コンテナ化されたアプリケーションは、どこでも同じように動作することを保証されます。
そして、Docker Composeは、複数のDockerコンテナを連携させて、一つのアプリケーションとしてまとめて管理するためのツールです。設定ファイル(docker-compose.yml
)に、どのイメージを使うか、ポートをどう割り当てるか、コンテナ間でどう通信するかなどを記述するだけで、複雑なサービス構成をコマンド一つで起動・停止できるようになります。
この記事では、インメモリデータ構造ストアとして非常に人気があり、キャッシュやメッセージキューとしてよく使われる Redis を例に、Docker Composeを使ったサービスの始め方を、初心者の方でも迷わないようにイチから丁寧に解説します。
「Dockerって聞いたことはあるけどよく分からない」「Redisを使ってみたいけどインストールが面倒そう」と感じている方に、その簡単さと便利さを実感してもらうことを目指します。
さあ、Docker ComposeとRedisの世界へ飛び込みましょう!
この記事で学ぶこと
- なぜDockerとDocker Composeを使うとサービス構築が楽になるのか
- Redisとは何か、どのような用途で使われるのか
- DockerとDocker Composeのインストール方法(簡単な紹介)
docker-compose.yml
ファイルの書き方(超基本から解説)- Docker Composeを使ってRedisコンテナを起動する方法
- 起動したRedisに外部から、あるいはコンテナ内から接続する方法
- Redisの基本的な操作コマンド(
SET
,GET
,PING
など) - コンテナを停止・削除する方法
- 最も重要:コンテナを削除してもRedisのデータを永続化する方法(Docker Volumeの利用)
docker-compose.yml
のもう少し詳しい設定(ポートマッピング、ボリューム)- よくあるトラブルとその解決策
この記事を読めば、あなたはRedisの環境構築の煩わしさから解放され、すぐに開発や学習に集中できるようになります。
第1章:なぜDockerとDocker Composeを使うのか?
1.1. Dockerとは? コンテナという魔法
Dockerを一言でいうと、「アプリケーションとその実行環境をまとめて箱に詰める技術」です。この「箱」がコンテナです。
従来の仮想マシン(VM)は、OS全体をエミュレートするため、起動に時間がかかり、必要なディスク容量やメモリも大きくなりがちでした。しかし、Dockerコンテナは、ホストOSのカーネルを共有し、その上にアプリケーション実行に必要な最小限のファイルシステムと設定だけを載せます。
これにより、以下のようなメリットが生まれます。
- 軽量かつ高速: VMに比べて起動が圧倒的に速く、必要なリソースも少ないです。
- 環境の分離と一貫性: アプリケーションはホストOSや他のアプリケーションから隔離されたコンテナ内で動作します。これにより、「私の環境では動くのに、あなたの環境では動かない」といった「環境依存問題」を劇的に減らすことができます。開発環境、テスト環境、本番環境で全く同じコンテナイメージを使うことで、どこでも同じ挙動を保証できます。
- ポータビリティ: 作成したコンテナイメージは、DockerがインストールされていればどんなOS上でもほぼ同じように実行できます。
- 管理の容易さ: アプリケーションのインストール、設定、削除がコンテナイメージとコンテナの操作に集約されます。
Redisを例にとると、Dockerを使えば、Redisの公式サイトからソースコードをダウンロードしてビルドしたり、OSのパッケージマネージャーを使ってインストールしたり、設定ファイルを編集したりといった面倒な作業は不要になります。代わりに、Docker Hub(Dockerイメージの公開リポジトリ)から公式のRedisイメージをダウンロードして実行するだけで、すぐにRedisサーバーが起動します。
1.2. Docker Composeとは? 複数のコンテナをまとめるオーケストレーター
アプリケーションは単一のサービスだけで構成されることは稀です。Webアプリケーションであれば、Webサーバー、アプリケーションサーバー、データベース、キャッシュサーバー(今回のRedisなど)といった複数のサービスが連携して動作するのが一般的です。
Dockerだけを使っても複数のコンテナを起動し、連携させることは可能ですが、それはコマンドラインで一つずつコンテナを起動し、ネットワーク設定を行い… と非常に煩雑な作業になります。
ここでDocker Composeが活躍します。
Docker Composeは、YAML形式のファイル(docker-compose.yml
)に、アプリケーションを構成する複数のサービス(各サービスは1つ以上のコンテナに対応します)の定義、つまり「どのDockerイメージを使うか」「ポートはどうするか」「データはどこに保存するか」「サービス間はどう連携するか」といった設定をまとめて記述し、それを元に一括でコンテナ群を起動・停止・管理できるツールです。
Docker Composeを使うメリットは以下の通りです。
- 設定の一元化: アプリケーション全体の構成が
docker-compose.yml
ファイル一つに記述されるため、管理が容易になります。 - 再現性:
docker-compose.yml
ファイルを共有すれば、誰でも全く同じ開発環境やテスト環境を簡単に構築できます。 - コマンド一つで操作:
docker compose up
というコマンド一つで、ファイルに記述されたすべてのサービス(コンテナ)が起動し、必要な設定(ネットワークなど)が自動的に行われます。停止もdocker compose down
一つです。
この記事の目的である「Docker Composeを使ってRedisを起動する」というのは、厳密には「Docker Composeを使って、単一のRedisサービス(コンテナ)を定義し、それを起動・管理する」ことになります。単一のサービスから始めることで、Docker Composeの基本的な考え方と操作方法を学ぶのに最適です。将来的に、このRedisサービスに依存するWebアプリケーションなどの他のサービスを追加する際にも、同じdocker-compose.yml
ファイルに追記していくだけで良いため、スムーズに移行できます。
1.3. なぜRedisをDocker Composeで?
Redisは高性能なインメモリデータストアであり、開発やテストで頻繁に利用されます。Docker Composeを使うことで、Redisの環境構築が以下のように非常に簡単になります。
- インストール不要: ホストOSにRedisを直接インストールする必要がありません。
- クリーンな環境: コンテナ内で実行されるため、ホストOSの他のアプリケーションやライブラリとの干渉を心配する必要がありません。
- 使い捨てが容易: 開発やテストのために一時的にRedis環境が必要な場合でも、
docker compose up
で起動し、用が済んだらdocker compose down
で完全に削除できます。ホストOSに不要なファイルや設定が残りません。 - バージョン管理:
docker-compose.yml
ファイルでRedisのバージョンを固定して使用できるため、プロジェクトごとに異なるバージョンのRedisを使い分けるのも容易です。 - 構成の共有: チーム内で
docker-compose.yml
ファイルを共有すれば、全員が同じRedis環境を簡単に構築できます。
これらの理由から、Redisのような開発・テストで頻繁に使うサービスは、Docker Composeで管理するのが非常に効率的でモダンな方法と言えます。
第2章:Redisとは? 何に使われるの?
Docker ComposeでRedisを動かす前に、そもそもRedisがどのようなものか、簡単に理解しておきましょう。
2.1. Redisの基本
Redis (Remote Dictionary Server) は、オープンソースのインメモリデータ構造ストアです。データは主にRAM(メモリ)上に保持されるため、非常に高速な読み書きが可能です。
主な特徴は以下の通りです。
- インメモリ: データをメモリに保持するため、ディスクアクセスに比べて圧倒的に高速です。
- キーバリュー型: 基本的には、キー(文字列)とそれに紐づく値(様々なデータ構造)を格納するシンプルなデータモデルです。
- 豊富なデータ構造: 単なる文字列だけでなく、リスト(Lists)、セット(Sets)、ソート済みセット(Sorted Sets)、ハッシュ(Hashes)、ビットマップ(Bitmaps)、HyperLogLog、ジオスペーシャルインデックス(Geospatial indexes)など、様々なデータ構造をサポートしています。これにより、多様な要件に対応できます。
- 永続化オプション: データはメモリに保持されますが、RDB(Point-in-time snapshots)やAOF(Append-only file)といった機能を使ってディスクに永続化するオプションもあります。これにより、サーバー再起動時にもデータを復旧できます。
- レプリケーションとクラスタリング: データの冗長化や水平スケーリングのための機能も提供されています。
- Pub/Sub機能: メッセージングシステムとしても利用できます。
2.2. Redisの主な用途
Redisの高速性と多様なデータ構造は、様々な用途で活用されています。
- キャッシュ(Caching): 最も一般的な用途です。データベースからの取得結果などをRedisに一時的に保存しておくことで、同じデータへのアクセスがあった際にデータベースへの問い合わせをスキップし、アプリケーションの応答速度を大幅に向上させます。
- セッションストア(Session Store): Webアプリケーションのユーザセッション情報を保存するために使われます。特に、複数のアプリケーションサーバーでセッション情報を共有したい場合に便利です。
- メッセージキュー(Message Queue): Pub/Sub機能やListデータ構造を利用して、非同期処理のためのメッセージキューとして使用されます。
- レートリミッター(Rate Limiting): 特定の操作(例: API呼び出し)の頻度を制限するために使用されます。
- ランキング/リーダーボード(Rankings/Leaderboards): Sorted Sets機能を使って、リアルタイムなランキングを簡単に実装できます。
- リアルタイム分析(Real-time Analytics): 高速な読み書きを活かして、ストリーミングデータの集計や分析に利用されます。
今回は最も基本的な「キャッシュ」や「汎用的なデータストア」としての利用を想定して、キーバリュー操作を中心に解説を進めます。
第3章:準備編 – DockerとDocker Composeのインストール
Docker Composeを使ってRedisを起動するためには、当然ながらDockerとDocker Composeがあなたのコンピューターにインストールされている必要があります。
最近のDocker Desktop(WindowsおよびmacOS向け)や、Linux向けのDocker Engineインストールには、Docker Composeも同梱されているか、またはdocker compose
コマンドとして統合されています。したがって、Docker本体をインストールすれば、Docker Composeも使えるようになっている場合が多いです。
3.1. インストール方法の概要
お使いのOSに合わせて、以下の公式ドキュメントを参照し、Dockerをインストールしてください。インストールには、オペレーティングシステムやそのバージョンに応じた具体的な手順が必要です。
- Windows: Install Docker Desktop on Windows
- macOS: Install Docker Desktop on Mac
- Linux: Install Docker Engine および Install Docker Compose Plugin
- Linuxの場合は、Docker Engine本体に加えて、Docker Compose Pluginを別途インストールする必要がある場合があります。最新の推奨されるインストール方法を確認してください。多くのディストリビューションでは、パッケージマネージャー(
apt
,yum
,dnf
など)経由でのインストールが可能です。
- Linuxの場合は、Docker Engine本体に加えて、Docker Compose Pluginを別途インストールする必要がある場合があります。最新の推奨されるインストール方法を確認してください。多くのディストリビューションでは、パッケージマネージャー(
Docker Desktopをインストールした場合、通常はDocker Composeも自動的にインストールされ、docker compose
コマンドが利用できるようになります。
3.2. インストール後の確認
インストールが完了したら、ターミナル(またはコマンドプロンプト/PowerShell)を開いて、以下のコマンドを実行し、DockerとDocker Composeが正しくインストールされ、バージョン情報が表示されるか確認してください。
bash
docker --version
docker compose version
または、最新のDocker DesktopやLinuxのインストール方法では、docker compose
がdocker
コマンドのサブコマンドとして統合されているため、以下のコマンドでバージョンを確認できます。
bash
docker version
このコマンドの出力の中にCompose
やDocker Compose
といった項目があれば、正しくインストールされています。
“`
Client: Docker Engine – Community
Version: 24.0.5
API version: 1.43
… (省略) …
Server: Docker Engine – Community
Engine:
Version: 24.0.5
API version: 1.43 (minimum version 1.12)
… (省略) …
Experimental: false
Containerd:
Version: 1.6.21
GitCommit: 3dce88cb4d6fbd32f34732b93f80083ba573fa6c
… (省略) …
Runc:
Version: 1.1.9
GitCommit: v1.1.9-0-gafb9b58
… (省略) …
Docker Compose:
Version: v2.20.2 # <– この部分があればOK
Build: b381f5f5
“`
バージョン情報が表示されれば準備完了です!もしエラーが出る場合は、インストール手順に戻って確認してください。
第4章:はじめてのdocker-compose.yml
ファイル作成
いよいよDocker Composeの設定ファイル、docker-compose.yml
を作成します。このファイルに、起動したいRedisサービスの設定を記述します。
4.1. docker-compose.yml
とは?
docker-compose.yml
は、Docker Composeがサービス構成を理解するための設定ファイルです。YAML(YAML Ain’t Markup Language)という形式で記述します。YAMLは、人間にとって読み書きしやすいデータ記述言語であり、インデント(字下げ)を使って構造を表すのが特徴です。
ファイル名としては、デフォルトでdocker-compose.yml
またはdocker-compose.yaml
が使われます。今回はdocker-compose.yml
を使用します。
4.2. 最小限のdocker-compose.yml
ファイル
まずは、Redisを起動するための最小限の設定を記述してみましょう。お好みのテキストエディタ(VS Code, Sublime Text, Atomなど)を開いて、新しいファイルを作成し、以下の内容をコピー&ペーストしてください。
“`yaml
docker-compose.yml
version: ‘3.8’
services:
redis:
image: redis
ports:
– “6379:6379”
“`
ファイルをdocker-compose.yml
という名前で、作業用のディレクトリ(例: ~/my-redis-app
や C:\Users\YourName\Documents\my-redis-app
)に保存してください。
4.3. docker-compose.yml
の解説
作成したdocker-compose.yml
ファイルの内容を一行ずつ見ていきましょう。
version: '3.8'
- これはDocker Composeファイルのフォーマットバージョンを指定しています。バージョンによって利用できる機能や記述方法が異なります。
3.8
は比較的新しいバージョンで、広く使われています。通常は、最新の安定版に近いバージョンを指定しておけば問題ありません。シングルクォートで囲むのが推奨です。
- これはDocker Composeファイルのフォーマットバージョンを指定しています。バージョンによって利用できる機能や記述方法が異なります。
services:
- ここから下に、起動したいサービスの定義を列挙します。Docker Composeの主要な要素です。この下に記述する各項目が、それぞれ一つのサービス(通常は一つのコンテナ)に対応します。
redis:
- これはサービスの名前です。自由に決めることができますが、後述するように、他のサービスからこのサービスに接続する際のホスト名としても使われるため、分かりやすい名前(例:
database
,cache
,web
など)を付けるのが一般的です。今回はRedisなのでシンプルにredis
としました。行頭のスペースは、services:
の下にこのサービスが属していることを示すためのインデントです。YAMLではこのインデントが非常に重要です。サービス名の下の設定項目も、このサービス名に対してインデントされています。
- これはサービスの名前です。自由に決めることができますが、後述するように、他のサービスからこのサービスに接続する際のホスト名としても使われるため、分かりやすい名前(例:
image: redis
- このサービスに使用するDockerイメージを指定します。
image:
の後ろに続くredis
は、Docker Hubにある公式のRedisイメージを指します。特にバージョンを指定しない場合(例:redis:latest
と同じ意味になります)、Docker ComposeはDocker Hubから最も新しいバージョンのredis
イメージをダウンロードしようとします。 - 特定のバージョンを使用したい場合は、
image: redis:6.2
のようにタグを指定します。プロダクション環境などでは、後から予期せずバージョンが変わるのを避けるために、特定のタグを指定することが推奨されます。今回は入門なのでredis
(最新版)で構いません。
- このサービスに使用するDockerイメージを指定します。
ports:
- これは、コンテナのポートをホストOSのポートにマッピングするための設定です。コンテナは隔離された環境で動作するため、デフォルトではホストOSからはコンテナ内のポートに直接アクセスできません。
ports
設定を使うことで、ホストOSの特定のポートへの通信を、コンテナ内の特定のポートに転送させることができます。
- これは、コンテナのポートをホストOSのポートにマッピングするための設定です。コンテナは隔離された環境で動作するため、デフォルトではホストOSからはコンテナ内のポートに直接アクセスできません。
- "6379:6379"
ports:
の下にリスト形式(先頭に-
を付ける)で記述します。記述形式は"ホストOSのポート:コンテナ内のポート"
です。6379
はRedisのデフォルトのポート番号です。- この設定は、「ホストOSの
6379
番ポートに来た通信を、redis
コンテナ内の6379
番ポートに転送する」という意味になります。 - これにより、ホストOSから
localhost:6379
に接続すると、コンテナ内で起動しているRedisサーバーにアクセスできるようになります。 - ホストOS側のポートは自由に指定できます(例:
"6380:6379"
とすれば、ホストの6380番ポートでRedisにアクセスできます)。今回はデフォルトの6379番を使います。
これで、Redisを起動するための最小限の設定ファイルが完成しました。次の章で、このファイルを使って実際にRedisを起動してみましょう。
第5章:Redisコンテナを起動してみよう
docker-compose.yml
ファイルが作成できたら、いよいよコマンドを実行してRedisコンテナを起動します。
5.1. ターミナルでの準備
docker-compose.yml
ファイルを保存したディレクトリ(例: ~/my-redis-app
)をターミナルで開いてください。コマンド実行は、このディレクトリで行います。
“`bash
例: macOS/Linuxの場合
cd ~/my-redis-app
例: Windowsの場合 (PowerShell)
cd C:\Users\YourName\Documents\my-redis-app
“`
5.2. サービスを起動するコマンド
準備ができたら、以下のコマンドを実行してください。
bash
docker compose up
このコマンドを実行すると、Docker Composeはカレントディレクトリにあるdocker-compose.yml
ファイルを探し、そこに記述されているサービスを起動します。
初めて実行する場合、Docker Composeはまずimage: redis
で指定されたRedisイメージがローカルにあるか確認します。もしなければ、Docker Hubから自動的にダウンロードを開始します。
[+] Running 1/0
✔ Network my-redis-app_default Created 0.1s
... (イメージのダウンロードが始まる可能性があります) ...
Pulling redis (redis:latest)...
... (ダウンロードの進捗が表示されます) ...
Status: Downloaded newer image for redis:latest
[+] Running 1/1
✔ Container my-redis-app-redis-1 Created 0.1s
Attaching to my-redis-app-redis-1 # <- アタッチされています
my-redis-app-redis-1 | 1:C 16 Aug 2023 00:00:00.123 # oO0OoO0OoO0Oo RediS is starting oO0OoO0OoO0Oo
my-redis-app-redis-1 | 1:C 16 Aug 2023 00:00:00.123 # Redis version=7.0.12, bits=64, commit=00000000, modified=0, pid=1, just started
... (Redisの起動ログが表示されます) ...
my-redis-app-redis-1 | 1:M 16 Aug 2023 00:00:00.456 * Ready to accept connections
上記のログが表示されれば、Redisコンテナが正常に起動しています。
ここで注意点です。 docker compose up
をそのまま実行すると、コンテナのログがターミナルに表示され続け、ターミナルが専有されてしまいます(これをフォアグラウンド実行と呼びます)。
5.3. バックグラウンドで起動する(デタッチモード)
コンテナをバックグラウンドで起動し、ターミナルをすぐに解放したい場合は、-d
オプションを付けます。このモードをデタッチモードと呼びます。
まず、フォアグラウンドで起動している場合は、ターミナルでCtrl+C
を押してコンテナを停止してください。
次に、以下のコマンドを実行します。
bash
docker compose up -d
出力が簡潔になります。
bash
[+] Running 2/2
✔ Network my-redis-app_default Created 0.1s
✔ Container my-redis-app-redis-1 Started 0.5s
これで、Redisコンテナはバックグラウンドで起動しました。ターミナルは他の作業に使用できます。
5.4. 起動したコンテナを確認する
バックグラウンドで起動した場合、コンテナが本当に動いているか確認したいですよね。以下のコマンドで、Docker Composeによって管理されているサービス(コンテナ)の状態を確認できます。
bash
docker compose ps
出力例:
bash
NAME COMMAND SERVICE STATUS PORTS
my-redis-app-redis-1 "docker-entrypoint.s…" redis running 0.0.0.0:6379->6379/tcp
STATUS
がrunning
になっていれば、Redisコンテナは正常に起動しています。PORTS
の欄は、0.0.0.0:6379->6379/tcp
となっており、「ホストOSのすべてのIPアドレスの6379番ポート(0.0.0.0:6379
)が、コンテナ内の6379番ポート(->6379/tcp
)にマッピングされている」ことを示しています。これはdocker-compose.yml
で"6379:6379"
と設定した通りの結果です。
コンテナ名がmy-redis-app-redis-1
のようになっているのは、Docker Composeがデフォルトで「現在のディレクトリ名(my-redis-app
)」+「サービス名(redis
)」+「インスタンス番号(-1
)」という命名規則でコンテナを作成するためです。
これで、あなたのローカル環境にRedisサーバーが起動しました!
第6章:起動したRedisに接続してみよう
Redisサーバーが起動しただけでは意味がありません。データを保存したり取得したりするためには、クライアントから接続する必要があります。ここでは、最も一般的なRedisクライアントであるredis-cli
を使って接続する方法を解説します。
redis-cli
は、DockerコンテナとしてRedisを起動した場合でも、ホストOSから直接、あるいはコンテナの中から実行することができます。両方の方法を見てみましょう。
6.1. ホストOSからredis-cli
で接続する
ホストOSに既にredis-cli
がインストールされている場合(または別途インストールする場合)、そのredis-cli
を使ってDockerコンテナで起動したRedisに接続できます。
ターミナルで以下のコマンドを実行してください。
bash
redis-cli
Redisがデフォルトポート(6379)で起動しており、かつports: - "6379:6379"
の設定でホストOSにポートが公開されていれば、特に引数なしでredis-cli
を実行すると、自動的にlocalhost:6379
への接続を試みます。
接続に成功すると、プロンプトが127.0.0.1:6379>
のように変化します。
$ redis-cli
127.0.0.1:6379>
もしデフォルト以外のポートで接続したい場合や、別のホストに接続する場合は、-h
オプション(ホスト名)と-p
オプション(ポート番号)を使います。今回はホストはlocalhost
(または127.0.0.1
)、ポートは6379
なので以下のようにも書けますが、デフォルトなので省略可能です。
bash
redis-cli -h localhost -p 6379
プロンプトが表示されたら、基本的なRedisコマンドを実行してみましょう。
- サーバーが応答するか確認:
127.0.0.1:6379> PING
PONG
PONG
が返ってくれば、サーバーは正常に動作しています。 - キーに値をセットする:
127.0.0.1:6379> SET mykey "Hello from Redis!"
OK - キーの値を取得する:
127.0.0.1:6379> GET mykey
"Hello from Redis!"
正しく設定した値が取得できました。 - すべてのキーを確認する(開発・テスト以外では非推奨なコマンドです):
127.0.0.1:6379> KEYS *
1) "mykey"
セットしたmykey
が見つかりました。
Redisへの接続と基本的な操作が成功しました!
redis-cli
を終了するには、exit
またはquit
と入力するか、Ctrl+C
を押します。
注意点: ホストOSにredis-cli
がインストールされていない場合は、この方法は使えません。その場合は次の「コンテナの中からredis-cli
で接続する」方法を試してください。あるいは、Dockerを使って一時的にredis-cli
コンテナを起動して接続することも可能です(少し応用的なのでここでは割愛しますが、興味があれば調べてみてください)。
6.2. コンテナの中からredis-cli
で接続する
redis-cli
はRedisサーバーイメージにも含まれていることが多いツールです。Dockerコンテナとして起動したRedisサーバーの中に直接入って、その中でredis-cli
を実行することも可能です。
この方法の利点は、ホストOSにredis-cli
をインストールする必要がないことです。また、コンテナ内部からの視点で操作できるため、ネットワークなどのデバッグにも役立ちます。
Dockerコンテナ内でコマンドを実行するには、docker exec
コマンドを使います。
まず、起動しているRedisコンテナの名前またはIDを確認します。先ほど使ったdocker compose ps
コマンドのNAME
列で確認できます。今回はmy-redis-app-redis-1
という名前でした。
bash
docker compose ps
次に、以下のコマンドを実行して、そのコンテナの中でredis-cli
を実行します。
bash
docker exec -it my-redis-app-redis-1 redis-cli
docker exec
: 起動中のコンテナ内でコマンドを実行するためのDockerコマンドです。-it
: オプションです。-i
は標準入力を開いたままにする、-t
は擬似ターミナルを割り当てる、という意味です。これらを組み合わせることで、コンテナ内で対話的にコマンドを実行できるようになります(redis-cli
のように入力待ちになるプログラムには必須です)。my-redis-app-redis-1
: コマンドを実行したいコンテナの名前(またはID)です。redis-cli
: コンテナ内で実行したいコマンドです。
実行すると、ホストOSから実行したときと同様に、プロンプトが表示されます。
$ docker exec -it my-redis-app-redis-1 redis-cli
127.0.0.1:6379>
プロンプトが出たら、先ほどと同様にコマンドを実行してみましょう。
127.0.0.1:6379> PING
PONG
127.0.0.1:6379> GET mykey # 先ほどホストOSからセットした値が取得できるはずです
"Hello from Redis!"
127.0.0.1:6379> SET anotherkey "This is from inside the container"
OK
127.0.0.1:6379> KEYS *
1) "anotherkey"
2) "mykey"
ホストOSから設定したキーも、コンテナ内から設定したキーも、同じRedisサーバーに保存されていることが確認できます。
コンテナ内のredis-cli
を終了するには、exit
またはquit
と入力します。
これで、Docker Composeを使って起動したRedisサーバーに、ホストOSから、あるいはコンテナの中から接続し、基本的な操作を行う方法をマスターしました!
第7章:コンテナを停止・削除しよう
開発やテストが終わったら、起動したコンテナを停止または削除する必要があります。Docker Composeを使えば、これも簡単なコマンド一つで行えます。
7.1. サービスの停止と削除
docker-compose.yml
ファイルがあるディレクトリで、以下のコマンドを実行してください。
bash
docker compose down
このコマンドは、docker-compose.yml
ファイルに定義されているすべてのサービスに関連するコンテナを停止し、削除します。さらに、Docker Composeが自動的に作成したネットワークも削除します。
実行すると、以下のような出力が表示されます。
bash
[+] Running 1/1
✔ Container my-redis-app-redis-1 Removed 0.1s
✔ Network my-redis-app_default Removed 0.0s
これでRedisコンテナは停止され、あなたのシステムから削除されました。
7.2. 停止のみ行う
コンテナを停止するだけで、削除はしたくない場合は、以下のコマンドを使います。
bash
docker compose stop
このコマンドは、コンテナを停止しますが、削除はしません。コンテナはディスク上に保持されたままになるため、docker compose start
コマンドで素早く再開できます。
bash
docker compose stop
出力例:
bash
[+] Stopping 1/1
✔ Container my-redis-app-redis-1 Stopped 0.1s
docker compose ps
で確認すると、STATUS
がexited
などになっているはずです。
bash
docker compose ps
出力例:
bash
NAME COMMAND SERVICE STATUS PORTS
my-redis-app-redis-1 "docker-entrypoint.s…" redis exited (0)
停止したコンテナを再開するには、以下のコマンドを使います。
bash
docker compose start
出力例:
bash
[+] Starting 1/1
✔ Container my-redis-app-redis-1 Started 0.3s
docker compose ps
で確認すると、再びrunning
になっているはずです。
開発中は、stop
やstart
を使うことで、設定ファイルはそのままでコンテナの状態だけを切り替えられます。しかし、環境を完全にクリーンな状態に戻したい場合は、down
コマンドを使うのが一般的です。
ほとんどの場合、開発環境でRedisを一時的に起動したいだけなら、docker compose up -d
で起動し、用が済んだらdocker compose down
で削除、というサイクルで十分でしょう。
第8章:データ永続化の重要性 – Docker Volumeの利用
ここまでの手順でRedisを起動・停止できるようになりました。しかし、重大な問題が一つあります。それは、コンテナを削除すると、Redisに保存したデータも一緒に消えてしまうことです。
これは、コンテナのファイルシステムは一時的なものであり、コンテナが削除されると同時に破棄されてしまうためです。開発やテストで一時的に使うだけなら問題ありませんが、重要なデータを保存したい場合や、コンテナを再起動してもデータが失われてほしくない場合は、このままでは困ります。
そこで必要になるのが、データの永続化(Persistence)です。Dockerでは、コンテナのライフサイクルとは独立してデータを保存するための仕組みとして、Volume(ボリューム)を提供しています。
8.1. Docker Volumeとは? なぜ永続化に必要?
Docker Volumeは、Dockerによって管理されるストレージ領域であり、コンテナの外部にデータが保存されます。コンテナが削除されても、Volumeはデフォルトでは削除されずに残り続けます。これにより、新しいコンテナが同じVolumeをマウントして起動すれば、以前のコンテナが保存したデータを引き継ぐことができます。
docker-compose.yml
にVolumeの設定を追加することで、Redisコンテナのデータを永続化させることができます。
8.2. Redisのデータ保存場所
公式のRedis Dockerイメージは、デフォルトで/data
ディレクトリをデータの保存場所(作業ディレクトリ)として使用するように設定されています。ここにRDBファイル(スナップショット)やAOFファイル(追記ログ)が作成され、データが永続化されます。
したがって、Docker Volumeを使って、ホストOS上の永続化したい場所と、Redisコンテナ内の/data
ディレクトリを関連付けてあげれば良いのです。
8.3. docker-compose.yml
にVolumeを追加する
docker-compose.yml
ファイルを編集し、Volumeの設定を追加します。
“`yaml
docker-compose.yml (永続化対応版)
version: ‘3.8’
services:
redis:
image: redis
ports:
– “6379:6379”
volumes: # ★ ここからvolumesの設定を追加
– redis_data:/data # ★ 名前付きボリューム「redis_data」をコンテナ内の「/data」にマウント
volumes: # ★ ファイル最下部に名前付きボリュームの定義を追加
redis_data: # ★ ボリューム名を指定。Dockerによって管理されます。
“`
変更点は以下の通りです。
services:
の下のredis
サービスの定義にvolumes:
セクションを追加しました。- redis_data:/data
: これは「redis_data
という名前のDocker Volumeを、コンテナ内の/data
ディレクトリにマウントする」という意味です。ホストOS上の具体的なパスを指定する代わりに、Dockerが管理する名前付きボリュームを指定しています。
- ファイルの最下部に、トップレベルの
volumes:
セクションを追加しました。redis_data:
: これは、上でサービス定義から参照しているredis_data
という名前付きボリュームを定義しています。この記述があることで、Docker Composeがdocker compose up
実行時にこの名前付きボリュームを自動的に作成・管理するようになります。
名前付きボリューム(Named Volume)は、Dockerが内部的に管理するストレージ領域であり、通常はホストOSの特定のディレクトリ(Dockerのデータディレクトリ内)に作成されます。具体的なパスを意識する必要がなく、docker volume ls
コマンドなどで管理できるため、シンプルで推奨される方法です。
8.4. 永続化されているか確認してみよう
更新したdocker-compose.yml
ファイル(永続化対応版)を使って、Redisを起動し、データを保存し、一度コンテナを削除してから、再度コンテナを起動してデータが残っているか確認してみましょう。
手順:
- 古いコンテナを削除する: 以前
docker compose up -d
で起動していたコンテナが残っている場合は、一度docker compose down
で削除してください。
bash
docker compose down
もし、前回起動時にvolumes
設定を追加していなかった場合、このdown
コマンドではボリュームは削除されません(名前付きボリュームが定義されていなかったため)。Volumeが作成されていなければ、ここで気にすることはありません。もし以前に名前付きボリュームを使っていて、完全にゼロから試したい場合は、後述のdocker volume rm
でボリュームを削除してから始めても良いでしょう。 - 新しい
docker-compose.yml
で起動する: 更新したdocker-compose.yml
ファイルがあるディレクトリで、以下のコマンドを実行します。
bash
docker compose up -d
Docker Composeは新しい設定を読み込み、redis_data
という名前付きボリュームを作成し(まだ存在しない場合)、そのボリュームを/data
にマウントした新しいRedisコンテナを起動します。
docker volume ls
コマンドを実行すると、redis_data
という名前のボリュームが作成されていることを確認できます。
bash
docker volume ls - データを入れてみる: 起動したRedisに接続し、いくつかのデータを保存します。今回はホストOSから
redis-cli
で接続してみましょう(ports
設定で6379
が開いている前提)。
bash
redis-cli
接続後、プロンプトでデータをセットします。
127.0.0.1:6379> SET user:1 '{"name":"Alice", "age":30}'
OK
127.0.0.1:6379> SET user:2 '{"name":"Bob", "age":25}'
OK
127.0.0.1:6379> GET user:1
"{\"name\":\"Alice\", \"age\":30}" # JSON文字列として取得されます
127.0.0.1:6379> KEYS *
1) "user:1"
2) "user:2"
データが正しく保存されていることを確認したら、exit
でredis-cli
を終了します。 - コンテナを削除する(ボリュームはそのまま残す):
docker compose down
コマンドを再度実行します。注意点: 通常のdocker compose down
は、サービス定義で明示的に定義された名前付きボリュームはデフォルトでは削除しません。
bash
docker compose down
出力でコンテナとネットワークが削除されたことが確認できます。docker compose ps
を実行しても、コンテナが見つからないはずです。
しかし、docker volume ls
を実行すると、redis_data
ボリュームはまだ存在していることが確認できます。
bash
docker volume ls - 再度サービスを起動する: もう一度
docker compose up -d
を実行します。Docker Composeはredis_data
ボリュームが既に存在することを確認し、それを再利用して新しいRedisコンテナを起動します。
bash
docker compose up -d - データが残っているか確認する: 起動した新しいRedisコンテナに再び接続し、以前保存したデータが残っているか確認します。
bash
redis-cli
接続後、KEYS *
やGET
コマンドを実行します。
127.0.0.1:6379> KEYS *
1) "user:1"
2) "user:2"
127.0.0.1:6379> GET user:2
"{\"name\":\"Bob\", \"age\":25}"
以前保存したデータがちゃんと残っていることが確認できました! これでRedisのデータ永続化が成功です。
8.5. ボリュームも完全に削除する場合
開発環境で、全てのデータを含めて完全にクリーンな状態に戻したい場合は、docker compose down
コマンドに--volumes
(または-v
)オプションを付けて実行します。
bash
docker compose down --volumes
このコマンドは、コンテナ、ネットワークに加えて、docker-compose.yml
ファイルで定義されている名前付きボリュームも削除します。
実行後、docker volume ls
を実行すると、redis_data
ボリュームがリストから消えていることが確認できます。
これで、永続化の仕組みと、コンテナやボリュームのライフサイクルを制御する方法を理解できたはずです。データベースなど、状態を持つサービスをDocker Composeで管理する際には、Volumeの設定は非常に重要です。
第9章:もう少し進んだ設定 – ポートマッピングとボリュームの別記法
これまでの設定で基本的なRedisの起動と永続化はできるようになりました。ここでは、docker-compose.yml
のports
とvolumes
の記述方法について、もう少し詳細や別の記法を見てみましょう。
9.1. ports
設定のバリエーション
ports
はリスト形式で記述し、複数のポートをマッピングできます。記述方法にはいくつか種類があります。
"ホストOSのポート:コンテナ内のポート"
(文字列)- これが最も一般的で推奨される形式です。ホストOSのIPアドレス(
0.0.0.0
など)を指定したい場合や、UDPポートを指定したい場合もこの形式を使います。 - 例:
"127.0.0.1:6379:6379"
(ホストの特定IPにバインド) - 例:
"6379:6379/tcp"
(TCPポートであることを明示) - 例:
"6379:6379/udp"
(UDPポートのマッピング、Redisでは通常使いませんが例として)
- これが最も一般的で推奨される形式です。ホストOSのIPアドレス(
ホストOSのポート:コンテナ内のポート
(数値)- 文字列でなく数値で指定することもできます。ただし、IPアドレスの指定や
/tcp
,/udp
の指定はできません。シンプルなTCPポートマッピングにのみ使えます。 - 例:
6379:6379
- 文字列でなく数値で指定することもできます。ただし、IPアドレスの指定や
コンテナ内のポート
(数値)- ホストOS側のポートを明示せず、コンテナ内のポート番号だけを指定した場合、DockerはホストOS上の利用可能なランダムなポートを割り当て、そのポートをコンテナ内の指定したポートにマッピングします。
- 例:
- "6379"
- この場合、
docker compose ps
などで実際にホストOSのどのポートが使われているか確認する必要があります。 - ランダムなポートを使いたい場合(例: 同時に複数のRedisインスタンスを起動したいがポート衝突を避けたい)に便利ですが、外部アプリケーションからの接続にはその都度割り当てられたポートを確認する必要があります。
今回のRedisの例では、ホストOS側の6379番ポートに固定するのが最も分かりやすく、一般的な使い方なので、"6379:6379"
(文字列形式)を使うのが良いでしょう。
9.2. volumes
設定のバリエーション(Bind Mount vs. Named Volume)
Volumeを使った永続化では、主に「名前付きボリューム(Named Volume)」と「バインドマウント(Bind Mount)」の2種類が使われます。
-
名前付きボリューム (Named Volume)
redis_data:/data
のように、名前を指定する方法です。DockerがホストOS上のどこにデータを保存するかを管理します。- メリット: Dockerに管理を任せられるためシンプル。バックアップなどがしやすい仕組みが提供されることがある。ホストOSとコンテナで異なるOS(LinuxとWindows/macOS)を使う場合にパフォーマンスが良いことが多い(特にDocker Desktop)。
- デメリット: ホストOS上の具体的な保存場所はDockerが決めるため、人間が直接アクセスしてファイルを確認したり編集したりするのには向いていません。
- 記述:
volumes:
のトップレベル定義が必要。サービス内で- volume_name:/container/path
と指定。
-
バインドマウント (Bind Mount)
- ホストOS上の特定のディレクトリを、コンテナ内の特定のディレクトリに直接マッピングする方法です。
- メリット: ホストOS上のファイルシステム上の具体的な場所を指定するため、ホスト側でファイルの内容を確認したり、ホスト上の既存の設定ファイルをコンテナに読み込ませたりするのに便利です。設定ファイルのマウントによく使われます。
- デメリット: ホストOS側のパスを絶対パスまたはカレントディレクトリからの相対パスで記述する必要がある。OSによってパスの記述方法が異なる場合がある。ホストOSのファイルシステムに依存するため、ポータビリティがNamed Volumeより劣る可能性がある。ホストOSとコンテナで異なるOS(LinuxとWindows/macOS)を使う場合にパフォーマンス問題が出やすいことがある(特に大量のI/Oがある場合)。
- 記述: サービス内で
- /host/path:/container/path
または- ./relative/path:/container/path
と指定。トップレベルのvolumes:
定義は不要(バインドマウントは定義ブロックを使わない)。
Redisのデータ永続化のように、コンテナ内部で生成・更新されるデータを永続的に保存したい場合は、一般的に名前付きボリュームを使用するのが推奨されます。
一方で、Redisの設定ファイルを外部から与えたい場合などは、バインドマウントを使うのが便利です。例えば、ローカルにredis.conf
という設定ファイルを用意し、それをコンテナに読み込ませたい場合は、以下のように記述できます。(※ただし、公式Redisイメージで外部から設定ファイルを読み込むには、command
オプションも併用する必要があります。詳細は後述の応用セクションで触れます。)
“`yaml
例:設定ファイルをバインドマウントする場合 (データ永続化は別途設定)
version: ‘3.8’
services:
redis:
image: redis
ports:
– “6379:6379”
volumes:
# ホストOSのカレントディレクトリにある redis.conf を
# コンテナ内の /usr/local/etc/redis/redis.conf にマウント
– ./redis.conf:/usr/local/etc/redis/redis.conf
# 設定ファイルを読み込むようにコマンドを上書きする必要がある場合
# command: [“redis-server”, “/usr/local/etc/redis/redis.conf”]
この例では名前付きボリュームは定義していませんが、データ永続化と組み合わせる場合は別途 volumes: redis_data: … の定義が必要です。
“`
このように、volumes
設定は単に- ボリューム名:コンテナパス
だけでなく、ホストパスを指定する- ホストパス:コンテナパス
という記法もあり、それぞれ名前付きボリュームとバインドマウントに対応しています。Redisのデータ(/data
)には名前付きボリューム、設定ファイルにはバインドマウント、のように使い分けることが多いです。
第10章:もう少し進んだ設定 – コマンドと環境変数
Docker Composeでは、サービスの起動コマンドを上書きしたり、コンテナに環境変数を渡したりすることもできます。これは、Redisの設定を変更したい場合に役立ちます。
10.1. command
オプションで起動コマンドを変更する
command
オプションを使うと、Dockerイメージのデフォルトの起動コマンド(DockerfileのCMDやENTRYPOINTで定義されているもの)を上書きできます。
公式のRedisイメージは、デフォルトでredis-server
コマンドが実行され、特に引数がない場合はデフォルト設定で起動します。ここに引数を渡すことで、起動時にいくつかの設定を変更できます。例えば、AOF(Append Only File)永続化を有効にしたい場合などです。
“`yaml
docker-compose.yml (AOF永続化を有効にする例)
version: ‘3.8’
services:
redis:
image: redis
ports:
– “6379:6379”
volumes:
– redis_data:/data
command: [“redis-server”, “–appendonly”, “yes”] # ★ ここでコマンドを上書き
volumes:
redis_data:
“`
command: ["redis-server", "--appendonly", "yes"]
:- これは、コンテナ起動時に実行されるコマンドを
redis-server --appendonly yes
に変更しています。 - リスト形式(
[要素1, 要素2, ...]
)で記述するのが一般的です。これは、コマンドとその引数を分けて指定する方法です。 --appendonly yes
は、RedisサーバーにAOF永続化を有効にするよう指示するオプションです。
- これは、コンテナ起動時に実行されるコマンドを
この設定で起動すると、RedisはRDBスナップショットに加えてAOFファイルも作成し、データがより頻繁にディスクに書き込まれるようになります。もちろん、保存場所は/data
、つまりマウントされたredis_data
ボリューム内になります。
パスワードを設定したい場合は、--requirepass
オプションを使います。
“`yaml
docker-compose.yml (パスワードを設定する例 – 非推奨の簡易設定)
version: ‘3.8’
services:
redis:
image: redis
ports:
– “6379:6379”
volumes:
– redis_data:/data
command: [“redis-server”, “–requirepass”, “your_very_secret_password”] # ★ パスワードを指定
volumes:
redis_data:
“`
注意点: --requirepass
をcommand
で渡すのは、docker ps
などでコマンドライン引数が見えてしまうため、セキュリティ上のリスクがあります。より安全な方法は、設定ファイルをマウントするか、Redis専用の認証メカニズム(ACLなど)を使用することです。しかし、簡易な開発環境であればこの方法でも動作確認はできます。
パスワードを設定した場合、redis-cli
で接続する際には-a
オプションでパスワードを指定する必要があります。
bash
redis-cli -a your_very_secret_password
接続後も、認証コマンド(AUTH
)を最初に実行する必要があります。
127.0.0.1:6379> AUTH your_very_secret_password
OK
127.0.0.1:6379> PING
PONG
10.2. environment
オプションで環境変数を渡す
一部のDockerイメージは、環境変数を使って設定を渡せるようになっています。公式Redisイメージ自体は、主にコマンドライン引数や設定ファイルで設定を制御しますが、他のサービス(例えば、Webアプリケーションサービス)からRedisに接続する際の接続情報を環境変数で渡す、といった使い方は一般的です。
environment
オプションは、コンテナ内で利用可能になる環境変数を設定します。
“`yaml
docker-compose.yml (例:他のサービスにRedis接続情報を渡す)
version: ‘3.8’
services:
redis:
image: redis
ports:
– “6379:6379”
volumes:
– redis_data:/data
myapp: # 例として追加するあなたのアプリケーションサービス
image: your-app-image # あなたのアプリケーションのイメージ
ports:
– “80:8000” # 例
environment: # ★ ここで環境変数を渡す
REDIS_HOST: redis # 同じdocker-compose.yml内のサービス名で指定
REDIS_PORT: 6379 # コンテナ内のポート番号を指定(内部通信なのでホストのポートは不要)
# REDIS_PASSWORD: your_very_secret_password # パスワードも渡す場合 (セキュアな方法は別途考慮)
depends_on: # ★ myappがredisに依存することを宣言 (redisが先に起動される)
– redis
volumes:
redis_data:
“`
上記の例では、myapp
というサービスに対して、REDIS_HOST
とREDIS_PORT
という環境変数を渡しています。
REDIS_HOST: redis
: ホスト名としてredis
という値を渡しています。同じdocker-compose.yml
ファイル内で定義されたサービスは、互いにサービス名をホスト名として通信できます。つまり、myapp
コンテナ内からはredis:6379
でRedisに接続できる、ということです。REDIS_PORT: 6379
: ポート番号として6379
を渡しています。これはRedisコンテナ内のポート番号です。myapp
は同じDockerネットワーク内にいるため、ホストOSのポートマッピング(6379:6379
)を経由する必要はなく、コンテナ内のポートに直接アクセスできます。
このように、environment
オプションは主にアプリケーションサービスが依存するデータベースやキャッシュなどの接続情報を設定する際に非常に便利です。
depends_on: - redis
は、myapp
サービスを起動する前にredis
サービスが起動するのを待つようにDocker Composeに指示します。これは、依存関係のある複数のサービスを起動する際に役立ちます。
これらのcommand
やenvironment
といったオプションを使うことで、より柔軟にコンテナの起動設定を制御できるようになります。
第11章:よくあるトラブルと解決策
Docker Composeを使ったサービス起動は簡単ですが、いくつか初心者が遭遇しやすいトラブルがあります。
11.1. ポートが既に使われている (Port conflict)
docker compose up
を実行した際に、以下のようなエラーが表示されることがあります。
Error response from daemon: driver failed programming external connectivity on endpoint my-redis-app-redis-1 (...): Error starting userland proxy: listen tcp 0.0.0.0:6379: bind: address already in use
これは、ホストOSの6379番ポートが、Dockerコンテナ以外(あるいは以前に起動した別のDockerコンテナ)によって既に使用されていることを示しています。
解決策:
- 原因となっているプロセスを探す: ホストOS上で6379番ポートを使用しているプロセスを特定します。
- macOS/Linux:
sudo lsof -i :6379
- Windows (PowerShell):
Get-Process -Id (Get-NetTCPConnection -LocalPort 6379).OwningProcess
またはnetstat -ano | findstr :6379
- 特定できたら、そのプロセスを停止します。
- macOS/Linux:
docker-compose.yml
のポートを変更する: ホストOS側のポート番号を変更します。例えば、6380番ポートを使うように設定ファイルを編集します。
yaml
ports:
- "6380:6379" # ホストOS側を6380に変更
ファイルを保存し、再度docker compose up -d
を実行します。この場合、Redisへの接続はlocalhost:6380
に対して行う必要があります。
11.2. サービスが起動しない、すぐに終了してしまう
docker compose up -d
は成功したが、docker compose ps
で見るとSTATUS
がexited
になっている、という場合があります。これはコンテナが起動直後にエラーで終了してしまったことを意味します。
解決策:
コンテナが終了した原因を確認するには、コンテナのログを見るのが最も有効です。docker compose logs
コマンドを使います。
bash
docker compose logs redis # 'redis' はサービス名
特定のサービス名(例: redis
)を指定することで、そのサービスのコンテナログだけを表示できます。エラーメッセージ(Error
, FATAL
などを含む行)や、終了直前のログを確認し、何が問題だったのかを特定します。
よくある原因としては、設定ファイルの記述ミス(YAMLのインデント間違いなど)、ボリュームのマウント先の問題(権限不足など)、コンテナに渡した設定が不正だった、などが考えられます。
11.3. ボリュームのマウントエラー、権限問題
特にLinuxホストで、バインドマウント(ホストのディレクトリをコンテナにマウント)を使用した場合に、ホスト側のディレクトリの権限設定によってコンテナからの書き込みができずエラーになることがあります。名前付きボリュームでも、まれにDockerのデータディレクトリの権限問題が影響することがあります。
解決策:
- ログの確認: まずは
docker compose logs service_name
でログを確認し、Permission denied(権限拒否)などのエラーメッセージが出ていないか確認します。 - バインドマウントの場合: ホストOS側のマウント元ディレクトリのパーミッションを確認し、コンテナ内のプロセス(Redisの場合、通常は
redis
ユーザー)が書き込める権限があるか確認します。必要に応じてchmod
コマンドなどで権限を変更します。 - 名前付きボリュームの場合: Dockerが管理するボリュームのパーミッションはユーザーが直接操作することは少ないですが、Dockerのデータディレクトリ自体の問題や、SELinuxのようなセキュリティ機構が影響している可能性もゼロではありません。多くの場合は、
docker compose down --volumes
でボリュームを一度削除し、再作成することで解決します。それでも解決しない場合は、ホストOSやDockerのインストールに関する問題かもしれません。 - コンテナ内のユーザー: Dockerfileで特別なユーザーが設定されている場合、そのユーザーが書き込めるようにホスト側の権限を設定する必要があります。公式のRedisイメージはデフォルトで
redis
ユーザーを使います。
11.4. docker-compose.yml
のYAML構文エラー
docker compose up
実行時に、以下のようなYAML構文エラーが表示されることがあります。
ERROR: yaml.scanner.ScannerError: while scanning for the next token
found character '\t' that cannot start any token
in ".\docker-compose.yml", line 5, column 3
これは、docker-compose.yml
ファイルに記述ミスがあることを意味します。特にYAMLではインデント(スペース)が重要なので、タブ文字が混入していたり、スペースの数が間違っていたりするとエラーになりやすいです。
解決策:
エラーメッセージに示されている行番号と列番号を確認し、該当箇所を修正します。YAMLファイルを作成・編集する際は、タブをスペースに自動変換してくれるエディタを使うことを推奨します。
これらの一般的なトラブルシューティング方法を知っておけば、問題が発生しても落ち着いて対処できるようになります。ログを確認することが、原因特定のための第一歩です。
第12章:次に進むために – さらにRedisとDocker Composeを活用するには
ここまでで、Docker Composeを使ってRedisを起動し、永続化し、接続・操作する基本的な流れを習得しました。これは、あなたの開発や学習において非常に役立つはずです。
ここからさらに進んで、RedisやDocker Composeを本格的に活用するための次のステップをいくつか紹介します。
12.1. Redisの高度な機能と設定
- AOF永続化: 第10章で触れたAOF(Append Only File)は、RDBより詳細な時点でのデータ復旧を可能にする永続化方法です。本番環境ではAOFとRDBを組み合わせて使うことが多いです。設定ファイル(
redis.conf
)を編集してAOFを詳細に設定したり、RDBのスナップショット頻度を調整したりすることを学ぶと良いでしょう。 - メモリ制限: Redisはインメモリデータベースなので、使えるメモリ量には制限があります。
maxmemory
設定を使って、Redisが使用するメモリの上限を設定し、上限に達した場合の挙動(新しい書き込みを拒否するか、古いキーを削除するかなど)を制御することが重要です。これもredis.conf
で設定します。 - セキュリティ: パスワード(
requirepass
)は基本的な認証ですが、より高度なアクセス制御にはACL(Access Control List)を使用します。また、外部からの接続を許可する場合は、ファイアウォールの設定やTLS/SSLによる暗号化なども検討する必要があります。 - レプリケーションとSentinel: 高可用性を実現するために、マスター/レプリカ構成でRedisを起動し、Sentinelを使ってマスターの監視と自動フェイルオーバーを行うことができます。
- Redis Cluster: 大量のデータを扱ったり、高いスループットが必要な場合は、データを複数のノードに分散させるRedis Clusterを構築します。
- データ構造の活用: Listをキューとして使う、Sorted Setsでランキングを作る、Pub/Subでリアルタイム通知を実装するなど、様々なデータ構造を活用したアプリケーションロジックを学びましょう。
これらの設定や機能は、Redisの公式ドキュメントで詳しく解説されています。Docker Composeを使う場合でも、これらの設定の多くは設定ファイルをボリュームマウントするか、コマンドライン引数として渡すことで実現できます。
12.2. Docker Composeの応用
- 複数のサービスを定義する: Webアプリケーション、APIサーバー、データベース、キャッシュなどを一つの
docker-compose.yml
ファイルにまとめて定義し、一括で起動・管理できるようにしましょう。これにより、開発環境の構築がさらに効率的になります。 - ネットワーク: Docker Composeはデフォルトでサービス間の通信用のネットワークを作成しますが、より複雑な要件に合わせて独自のネットワークを定義することも可能です。
- 環境変数ファイルの利用:
docker-compose.yml
内で環境変数を直接記述するのではなく、.env
ファイルに環境変数をまとめて定義し、それをDocker Composeから読み込むようにすることができます。これにより、パスワードなどの機密情報をdocker-compose.yml
ファイル本体から分離し、管理しやすくなります。 docker-compose.yml
の分割: 大規模なプロジェクトでは、docker-compose.yml
ファイルを複数のファイルに分割し、必要に応じてそれらを組み合わせて使うこともできます(docker compose -f docker-compose.yml -f docker-compose.override.yml up
のように-f
オプションで複数のファイルを指定)。
Docker Composeの公式ドキュメントは、これらの応用法についても非常に詳細に解説しています。
12.3. Dockerイメージの作成(Dockerfile)
今回は公式のRedisイメージをそのまま使いましたが、独自のDockerfileを作成してカスタムイメージを作ることもできます。例えば、特定のモジュールが組み込まれたRedisイメージを作成したり、独自のredis.conf
ファイルをイメージ内に含めたりする場合です。
Dockerfileで独自のイメージを作成し、そのイメージをdocker-compose.yml
のimage:
で指定することで、さらに柔軟な環境構築が可能になります。
おわりに
この記事では、初心者の方を対象に、Docker Composeを使ってRedisを起動し、データ永続化を実現する方法を詳細に解説しました。
DockerとDocker Composeを使うことで、Redisのようなミドルウェアの環境構築が驚くほど簡単になり、開発や学習に集中できることを実感していただけたのではないでしょうか。特に、docker-compose.yml
ファイル一つで環境を定義し、コマンド一つで起動・停止・削除できる手軽さ、そしてVolumeによるデータ永続化の仕組みは、今後のあなたの開発ワークフローを大きく改善してくれるはずです。
もちろん、Docker、Docker Compose、そしてRedisには、この記事で触れられなかった多くの機能や設定があります。しかし、ここで学んだ基本的な概念(サービス、イメージ、ポート、ボリューム)と操作(up
, down
, ps
, logs
)を理解していれば、公式ドキュメントなどを参照しながら、さらに応用的な使い方に進んでいくことができるでしょう。
技術の世界は常に進化していますが、基礎をしっかりと押さえることが新しい技術を学ぶ上での一番の近道です。この記事が、あなたのDockerとRedisを使った開発の素晴らしいスタートになることを願っています。
ぜひ、手を動かして、今回学んだコマンドや設定を繰り返し試してみてください。実践こそが、理解を深める最良の方法です。
Happy Coding with Docker and Redis!