本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Docker Composeでマルチサービス定義
Docker Composeは、複数のコンテナサービスをまとめて定義し、ライフサイクルを管理するためのツールです。アプリケーションがWebサーバー、データベース、キャッシュなど複数のコンポーネントで構成される場合に、それぞれのコンテナ定義、ネットワーク、ボリュームなどを一元的に管理できるため、開発・運用効率が大幅に向上します。
要件と前提
、以下の要件を満たすDocker Composeによるマルチサービス定義と運用について解説します。
マルチサービス定義: 複数コンテナ（Webアプリ、データベース）をDocker Composeで定義します。
安全なBashスクリプト:
set -euo pipefail、trap、mktempを用いたスクリプト作成。外部ツール連携:
jqを用いたJSON処理、curlによるTLS通信と再試行/バックオフ処理。systemd連携: サービスを
systemdのUnit/Timerとして管理し、自動起動・ログ確認を実装します。権限管理:
root権限の扱いと権限分離に関する注意点を示します。冪等性: スクリプトや設定が何度実行されても同じ結果になるようにします。
前提として、Docker EngineとDocker Composeが動作するLinux環境（例: Ubuntu Server）が構築済みであることを想定します。
実装
Docker Compose ファイルの準備
基本的なWebアプリケーションとデータベースの構成を例に、docker-compose.yml を作成します。
ディレクトリ構成
.
├── app/
│ ├── Dockerfile
│ └── app.py
├── docker-compose.yml
└── scripts/
├── start_app.sh
├── health_check.sh
└── manage_backup.sh
アプリケーションサービス例
app/Dockerfile:
FROM python:3.9-slim-buster WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["python", "app.py"]
app/requirements.txt:
Flask redis psycopg2-binary
app/app.py:
import os
from flask import Flask
import redis
import psycopg2
app = Flask(__name__)
REDIS_HOST = os.environ.get('REDIS_HOST', 'redis')
POSTGRES_HOST = os.environ.get('POSTGRES_HOST', 'db')
POSTGRES_DB = os.environ.get('POSTGRES_DB', 'myapp_db')
POSTGRES_USER = os.environ.get('POSTGRES_USER', 'user')
POSTGRES_PASSWORD = os.environ.get('POSTGRES_PASSWORD', 'password')
@app.route('/')
def hello():
try:
r = redis.Redis(host=REDIS_HOST, port=6379, db=0)
r.ping()
redis_status = "Redis connected"
except Exception as e:
redis_status = f"Redis connection error: {e}"
try:
conn = psycopg2.connect(host=POSTGRES_HOST, database=POSTGRES_DB, user=POSTGRES_USER, password=POSTGRES_PASSWORD)
cur = conn.cursor()
cur.execute("SELECT 1")
db_status = "PostgreSQL connected"
cur.close()
conn.close()
except Exception as e:
db_status = f"PostgreSQL connection error: {e}"
return f"Hello from Flask! {redis_status}. {db_status}\n"
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)
docker-compose.yml の例
Docker Composeファイルのバージョンは、Docker Composeドキュメント（{{jst_today}}時点）で最新のものを参照してください。
# docker-compose.yml
version: '3.8'
services:
web:
build: ./app
ports:
- "5000:5000"
environment:
FLASK_ENV: development
REDIS_HOST: redis
POSTGRES_HOST: db
POSTGRES_DB: myapp_db
POSTGRES_USER: user
POSTGRES_PASSWORD: password
depends_on:
- db
- redis
networks:
- app_network
restart: unless-stopped # コンテナ停止時以外は再起動
db:
image: postgres:13
environment:
POSTGRES_DB: myapp_db
POSTGRES_USER: user
POSTGRES_PASSWORD: password
volumes:
- db_data:/var/lib/postgresql/data
networks:
- app_network
healthcheck: # データベースのヘルスチェック
test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
redis:
image: redis:6-alpine
networks:
- app_network
healthcheck: # Redisのヘルスチェック
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
volumes:
db_data:
networks:
app_network:
driver: bridge
安全なスクリプトでの起動
start_app.sh：Docker Composeアプリケーションを安全に起動するためのスクリプトです。
#!/bin/bash
# scripts/start_app.sh
# 1. 厳格なエラーハンドリングを有効化 (必須)
# -e: コマンドが失敗した場合、即座にスクリプトを終了
# -u: 未定義の変数を使用した場合、エラーとして終了
# -o pipefail: パイプライン中のコマンドが一つでも失敗した場合、パイプライン全体を失敗とする
set -euo pipefail
# 2. 一時ディレクトリの作成と自動クリーンアップ (必須)
# mktemp -d: 安全な一時ディレクトリを作成
TMP_DIR=$(mktemp -d -t docker-compose-XXXXXX)
# trap: スクリプト終了時に一時ディレクトリを削除
# EXITシグナル: スクリプトが正常終了、エラー終了に関わらず実行される
trap 'echo "Cleaning up temporary directory: ${TMP_DIR}"; rm -rf "${TMP_DIR}"' EXIT
echo "Starting Docker Compose services..."
echo "Temporary directory for logs/data: ${TMP_DIR}"
# 環境変数 DOCKER_COMPOSE_FILE に compose ファイルのパスを設定
# デフォルトはカレントディレクトリの docker-compose.yml
DOCKER_COMPOSE_FILE="${DOCKER_COMPOSE_FILE:-docker-compose.yml}"
PROJECT_NAME="myapp_$(basename "$(pwd)")" # プロジェクト名をディレクトリ名から生成
# 3. Docker Composeの実行 (冪等性を考慮)
# -f: 使用するComposeファイルを指定
# --project-name: プロジェクト名を明示的に指定し、コンテナ名の衝突を防ぐ
# --build: イメージが変更されている場合は再ビルド
# -d: デタッチドモード（バックグラウンド）で実行
echo "Running: docker compose -f \"${DOCKER_COMPOSE_FILE}\" --project-name \"${PROJECT_NAME}\" up --build -d"
docker compose -f "${DOCKER_COMPOSE_FILE}" --project-name "${PROJECT_NAME}" up --build -d
echo "Waiting for services to be healthy..."
# サービスがhealthyになるまで待機
# --timeout: ヘルスチェックのタイムアウトを設定 (デフォルトは無制限)
# ここでは5分 (300秒) を設定
docker compose -f "${DOCKER_COMPOSE_FILE}" --project-name "${PROJECT_NAME}" ps --services --filter "status=running" | while read -r service; do
echo "Waiting for service: $service"
docker compose -f "${DOCKER_COMPOSE_FILE}" --project-name "${PROJECT_NAME}" wait "$service" --timeout 300 || {
echo "Error: Service $service did not become healthy within 300 seconds." >&2
exit 1
}
echo "Service $service is healthy."
done
echo "Docker Compose services started and healthy."
echo "Application can be accessed at http://localhost:5000"
安全なスクリプトのポイント:
set -euo pipefail: スクリプトの堅牢性を高めます。trap '...' EXIT: 予期せぬ終了時でも一時ファイルを確実にクリーンアップします。mktemp -d: 一意で安全な一時ディレクトリを作成し、競合や情報漏洩のリスクを低減します。--project-name: 環境ごとに異なるプロジェクト名を付与することで、複数のComposeプロジェクトが同じホストで実行される際のコンテナ名衝突を防ぎます。
jq と curl の活用例
health_check.sh：Webサービスのエンドポイントを curl で確認し、jq でJSONレスポンスを処理する例です。
#!/bin/bash
# scripts/health_check.sh
set -euo pipefail
APP_URL="http://localhost:5000"
MAX_RETRIES=10
RETRY_DELAY_SEC=5
echo "Checking application health at ${APP_URL}..."
for ((i=1; i<=$MAX_RETRIES; i++)); do
echo "Attempt $i/$MAX_RETRIES: Fetching health status..."
# curl の安全な利用例
# -s: サイレントモード
# -S: エラー表示 (サイレントモードでも)
# --fail: HTTPステータスが400以上の場合にエラーコードを返す
# --max-time: 全体的なタイムアウト
# --connect-timeout: 接続タイムアウト
# --retry: 指定回数リトライ (ここではループで制御するため1回)
# --retry-delay: リトライ間の遅延 (ループで制御するため0)
# -v / --cacert / --tlsv1.2: TLS関連 (本例ではHTTPなので不要だが、HTTPSの場合に利用)
# --output /dev/null: 出力を捨ててステータスコードのみ確認する場合
# --write-out '%{http_code}' /dev/stderr: HTTPステータスコードを標準エラーに出力
# -L: リダイレクトをフォロー
RESPONSE=$(curl -sS --fail -L \
--max-time 10 --connect-timeout 5 \
"${APP_URL}")
# curl が成功した場合
if [ $? -eq 0 ]; then
echo "Received response:"
echo "$RESPONSE" | jq '.' # jqでJSONを整形して出力
# jq を使ってレスポンス内容をチェックする例
# . | contains("Redis connected") で部分文字列のマッチング
if echo "$RESPONSE" | jq -e 'contains("Redis connected") and contains("PostgreSQL connected")' > /dev/null; then
echo "Application is healthy and services are connected!"
exit 0
else
echo "Application response indicates a problem with backend services. Retrying..."
fi
else
echo "curl failed (HTTP status or connection error). Retrying..."
fi
if [ "$i" -lt "$MAX_RETRIES" ]; then
echo "Waiting ${RETRY_DELAY_SEC} seconds before next retry..."
sleep "$RETRY_DELAY_SEC"
fi
done
echo "Error: Application did not become healthy after $MAX_RETRIES retries." >&2
exit 1
curl のポイント:
--fail: HTTP 4xx/5xx レスポンスでcurlが終了コードを返すため、スクリプトでエラーを捕捉しやすくなります。-sS: サイレントモードで進捗メータなどを非表示にしつつ、エラーメッセージは表示します。--max-time,--connect-timeout: ネットワークの問題でハングアップするのを防ぎます。HTTPSの場合:
--cacertでCA証明書を指定、--tlsv1.2で特定のTLSバージョンを強制するなど、セキュリティを強化できます。ループと
sleep: 指数バックオフはcurlの組み込み機能だけでは難しいため、シェルスクリプトのループで実装します。
jq のポイント:
jq '.': 受信したJSONを整形して表示します。jq -e 'contains("...")': 特定の文字列が含まれているかをチェックし、結果を終了コードで返します。これにより、シェルスクリプトでの条件判定が容易になります。> /dev/null:jqの出力を捨て、終了コードのみを利用します。
検証
サービス起動確認
start_app.sh スクリプトを実行して、Docker Composeサービスが正常に起動することを確認します。
cd /path/to/your/project chmod +x scripts/start_app.sh scripts/start_app.sh
スクリプトが「Docker Compose services started and healthy.」と出力すれば成功です。
Webブラウザで http://localhost:5000 にアクセスし、「Hello from Flask! Redis connected. PostgreSQL connected.」と表示されることを確認します。
ログ確認
docker compose logs コマンドで、実行中のコンテナのログを確認できます。
docker compose -f docker-compose.yml --project-name myapp_projectname logs -f
myapp_projectname は start_app.sh スクリプトで生成されたプロジェクト名に置き換えてください。-f オプションでリアルタイムにログを追跡できます。
運用
systemd との連携
Docker Composeアプリケーションをサーバー起動時に自動で立ち上げ、安定稼働させるために systemd と連携させます。
フローチャート
graph TD
A["システム起動/タイマー発動"] --> B{"systemdユニット実行"};
B --> C["ExecStart: docker compose up -d"];
C --> D["サービス起動"];
D -- 稼働中 --> E["systemd status/journalctl"];
D -- 停止時 --> F["ExecStop: docker compose down"];
E -- 定期実行 --> G{"systemdタイマー発動"};
G --> H["ExecStart: docker compose exec ... script"];
Unitファイル例 (/etc/systemd/system/myapp.service)
アプリケーションサービスを起動・停止するUnitファイルです。
User と Group を指定することで、Dockerデーモンとの通信権限を持つ非rootユーザーで実行することが推奨されます。
# /etc/systemd/system/myapp.service [Unit] Description=My Docker Compose Application Service After=network-online.target docker.service Wants=network-online.target Requires=docker.service [Service] # User/Group を指定し、root以外のユーザーで実行する # Dockerグループに属するユーザーであればdockerデーモンと通信可能 User=your_user # Dockerグループに属するユーザー Group=docker # WorkingDirectory を指定 WorkingDirectory=/path/to/your/project # ExecStart: start_app.sh スクリプトを呼び出す # Environment: スクリプトに compose ファイルパスを渡す ExecStart=/bin/bash /path/to/your/project/scripts/start_app.sh # ExecStop: docker compose down でサービスを停止 ExecStop=/usr/local/bin/docker compose -f /path/to/your/project/docker-compose.yml --project-name myapp_projectname down # 起動タイプ。forkingはバックグラウンドプロセスがメインになる場合に指定 # compose up -d はバックグラウンドで実行されるため forking が適している Type=forking # 再起動ポリシー Restart=on-failure RestartSec=5s # 標準出力/エラー出力のログを journalctl で確認 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target
注意点:
/path/to/your/projectは実際のプロジェクトディレクトリのパスに置き換えてください。your_userは Dockerグループに属する非rootユーザー名に置き換えてください。myapp_projectnameはdocker-compose.ymlで定義した、またはstart_app.shで生成されるプロジェクト名に置き換えてください。ExecStartとExecStopのdocker composeのパスは、which docker composeで確認したフルパスを使用してください (例:/usr/local/bin/docker compose)。
Timerファイル例 (/etc/systemd/system/myapp-backup.timer と /etc/systemd/system/myapp-backup.service)
定期的なバックアップ処理などのタスクは systemd のTimer機能で実行できます。
myapp-backup.timer:
# /etc/systemd/system/myapp-backup.timer [Unit] Description=Run My Docker Compose App Backup every day [Timer] # 毎日午前3時に実行 OnCalendar=*-*-* 03:00:00 # タイマーがシステムの起動後すぐに実行されるように (OnCalendarが過去の場合) Persistent=true [Install] WantedBy=timers.target
myapp-backup.service:
# /etc/systemd/system/myapp-backup.service [Unit] Description=My Docker Compose App Backup Task # myapp.service が動作していることを前提とする After=myapp.service Requires=myapp.service [Service] User=your_user Group=docker WorkingDirectory=/path/to/your/project # データベースコンテナ内でバックアップスクリプトを実行する例 ExecStart=/usr/local/bin/docker compose -f /path/to/your/project/docker-compose.yml --project-name myapp_projectname exec -T db pg_dumpall -U user > /path/to/your/project/backups/db_backup_$(date +\%Y\%m\%d\%H\%M\%S).sql StandardOutput=journal StandardError=journal
注意点:
バックアップスクリプトは
/path/to/your/project/backupsディレクトリを事前に作成しておく必要があります。pg_dumpallのパスはコンテナ内のパスを想定しています。dbコンテナでpg_dumpallが利用可能であることを前提としています。
起動/ログ確認
systemd ユニットとタイマーを有効化し、起動とログ確認を行います。
systemdの設定をリロード:sudo systemctl daemon-reload
サービスを有効化して起動:
sudo systemctl enable myapp.service sudo systemctl start myapp.service
タイマーを有効化:
sudo systemctl enable myapp-backup.timer sudo systemctl start myapp-backup.timer
サービスの状態確認:
sudo systemctl status myapp.service
ログの確認:
sudo journalctl -u myapp.service -f sudo journalctl -u myapp-backup.service -f
権限分離と root 権限の扱い
root権限の最小化: Docker Composeを本番環境で運用する場合、サービス起動スクリプトやsystemdユニットは可能な限りroot以外のユーザーで実行すべきです。Dockerグループに所属する非rootユーザーを作成し、そのユーザーでDockerデーモンとのやり取りを行わせるのが一般的なプラクティスです。コンテナ内のユーザー: コンテナイメージ内部では
rootユーザーではなく、専用の非特権ユーザーでプロセスを実行するようにDockerfileを記述することがセキュリティベストプラクティスです。ボリュームの権限: ボリュームをマウントする場合、ホスト側のディレクトリの権限が適切に設定されているか確認し、コンテナ内のユーザーが必要な読み書き権限を持つようにします。
シークレット管理: データベースパスワードなどの機密情報は、
docker-compose.ymlに直接ハードコードせず、environmentセクションの_FILEサフィックスを利用したシークレットファイルやDocker Secrets（Swarmモードの場合）を利用することを検討してください[1]。
トラブルシュート
一般的なDocker Composeのトラブルシューティングは以下の通りです。
コンテナが起動しない:
docker compose logs <service_name>で特定サービスのログを確認。docker compose psでコンテナの状態を確認（Exitedの場合、終了コードを確認）。docker compose build --no-cacheでイメージを再ビルドしてみる。Dockerデーモンが起動しているか
sudo systemctl status dockerで確認。
サービス間の通信ができない:
docker-compose.ymlのnetworks定義を確認し、全てのサービスが同じネットワークに接続されているか確認。サービス名がDNSとして解決されているか、コンテナ内で
ping <service_name>を試す（例:docker compose exec web ping db）。ファイアウォール（ufw/firewalld）がコンテナ間の通信をブロックしていないか確認。
ポートが競合する:
docker-compose.ymlのportsマッピングを確認し、ホスト側のポートが他のプロセスで使用されていないかsudo netstat -tulpn | grep :<port>で確認。
ボリュームのマウントエラー:
ホスト側のパスが存在し、Dockerデーモンやコンテナを実行するユーザーが必要な権限を持っているか確認。
Dockerボリュームの権限が正しく設定されているか確認。
まとめ
本記事では、Docker Composeを使用して複数のサービスを定義し、安全なBashスクリプトによる起動、jqとcurlを用いた健全性チェック、そしてsystemdと連携した自動運用までの一連の流れを解説しました。特に、Bashスクリプトの堅牢化 (set -euo pipefail, trap, mktemp) や systemd によるサービス管理は、本番運用において不可欠な要素です。
これらの実践を通じて、Docker Composeアプリケーションの信頼性と運用効率を向上させることができます。セキュリティと権限分離の原則を常に念頭に置き、最小限の権限でサービスを運用するよう努めてください。
[1] Docker Docs: Security best practices, {{jst_today}}更新. https://docs.docker.com/develop/security-best-practices/
