MinIOはS3互換APIをコンテナ1つで立ち上げられる強力なツールですが、Dockerfile設計とバケット初期化の仕組みを正しく組み合わせておかないと、環境ごとに手順が変わる属人的な運用になりがちです。
この記事では、Rocky Linux 9系/Ubuntu 24.04 LTSを想定環境として、MinIOのDockerfile構成・entrypoint.shによるバケット自動初期化・mcコマンドを使ったアクセスキーの最小権限設計の手順を解説します。
この記事のポイント
・MinIOのDockerfileはHEALTHCHECKを追加した公式イメージ拡張が基本
・バケット初期化はmcコマンドの専用initサービスで自動化する
・アプリ用アクセスキーはROOTと別ユーザーで最小権限ポリシーを発行する
・depends_on + service_healthyで初期化の実行順序を保証できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
MinIOとS3互換ストレージの概要
MinIO(ミニオ)は、Amazon S3と同じAPIを持つオープンソースのオブジェクトストレージです。AWS S3を使うアプリケーションをローカル環境で動かす場合や、クラウドに依存せず自前でオブジェクトストレージを用意したい場面でよく使われます。MinIOのDockerイメージは公式が提供しており、ポート9000でS3互換APIを、ポート9001でWebコンソールを提供します。
・ポート9000:S3互換API(アプリケーションからの接続先)
・ポート9001:WebコンソールUI(ブラウザ管理画面)
・データ保存先:/data ディレクトリ(ボリュームで永続化が必須)
・管理CLI:mc(MinIO Client)でバケット作成やユーザー管理を行う
Dockerを使ったコンテナ型サービスの構築手順については、DockerによるLinuxサーバー構築も参考にしてください。
MinIOのDockerfile設計
MinIOをDockerで運用する際、公式イメージをそのままdocker run で使うこともできますが、本番環境ではDockerfileを作成してHEALTHCHECKを追加しておくことを推奨します。HEALTHCHECKを定義しておくと、後述の docker-compose.yml で起動順序を正確に制御できます。1. Dockerfileの基本構成
MinIOのDockerfileは、公式イメージminio/minio をベースに構成します。FROM minio/minio:RELEASE.2024-10-13T13-34-11Z # MinIOが起動したかどうかを /minio/health/live で確認 HEALTHCHECK --interval=10s --timeout=5s --start-period=20s --retries=3 \ CMD curl -f http://localhost:9000/minio/health/live || exit 1 # データディレクトリとWebコンソールポートを明示して起動 CMD ["server", "/data", "--console-address", ":9001"]
latest は再ビルド時にイメージが変わるため、日付付きタグで固定します・HEALTHCHECK:MinIOが正常起動するまでの待機制御と、Composeの依存関係判定に使います
・CMD:データディレクトリ(
/data)とコンソールアドレスを明示します2. 認証情報の設定(MINIO_ROOT_USERとMINIO_ROOT_PASSWORD)
MinIOの管理者認証情報は環境変数で指定します。Dockerfileにハードコードせず、docker-compose.yml の env_file または environment セクションで渡してください。# .env ファイルで管理する例(.gitignore に追加すること) MINIO_ROOT_USER=minioadmin MINIO_ROOT_PASSWORD=minioadmin123
・MINIO_ROOT_PASSWORD:8文字以上のパスワード(旧環境変数名 MINIO_SECRET_KEY)
本番環境では
.env ファイルを .gitignore に追加し、リポジトリにコミットしないようにしてください。3. データの永続化とボリューム設計
MinIOのデータは/data ディレクトリに保存されます。ボリュームをマウントしないとコンテナ再起動でデータが消えます。# docker-compose.yml のボリューム定義例 volumes: - minio_data:/data # ...(省略)... volumes: minio_data:
minio_data)を使うことで、コンテナを削除してもデータが残ります。バインドマウント(ホストパス直接指定)はファイルシステムの権限問題が起きやすいため、開発・本番ともに名前付きボリュームが無難です。バケット初期化の設計(entrypoint.shとmcコマンド)
MinIOの起動後にバケットを自動作成するには、mc(MinIO Client)を使った専用の初期化サービスをDocker Composeに追加するのが定石です。MinIOサービス本体のDockerfileに初期化ロジックを混ぜると責務が分散するため、専用の minio-init サービスとして分離します。1. mcコマンドによるバケット自動作成の仕組み
mc はMinIO公式のCLIクライアントです。MinIOサーバーが起動した後に以下のコマンドでバケットを作成します。# エイリアス(接続先)を登録 mc alias set local http://minio:9000 minioadmin minioadmin123 # バケットを作成(バケットが存在する場合はスキップ) mc mb --ignore-existing local/my-bucket # 出力例(環境により異なります) # Bucket created successfully `local/my-bucket`.
・mc mb:バケットを作成します(make bucketの略)
・--ignore-existing:バケットが既に存在する場合はエラーにしません(冪等性の確保)
2. init用Dockerfileとentrypoint.shの実装例
バケット初期化専用のDockerfile.init を作成します。FROM minio/mc:RELEASE.2024-10-08T09-37-26Z COPY entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"]
entrypoint.sh の内容は以下のとおりです。#!/bin/sh set -e # MinIOが起動するまでエイリアス設定をリトライ until mc alias set local "${MINIO_ENDPOINT}" \ "${MINIO_ROOT_USER}" "${MINIO_ROOT_PASSWORD}"; do echo "MinIOの起動を待機中..." sleep 2 done # バケットを作成(冪等:存在しても失敗しない) mc mb --ignore-existing local/"${MINIO_BUCKET}" echo "バケット初期化完了: ${MINIO_BUCKET}"
・until ~ do ~ done:MinIOが起動するまで接続をリトライします
・環境変数(
MINIO_ENDPOINT・MINIO_BUCKET 等)は docker-compose.yml から注入します3. docker-compose.ymlとdepends_onによる順序保証
depends_on の condition: service_healthy を使うと、MinIOのHEALTHCHECKがpassするまで minio-init の起動を待機させられます。services: minio: build: context: . dockerfile: Dockerfile ports: - "9000:9000" - "9001:9001" env_file: - .env volumes: - minio_data:/data healthcheck: test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"] interval: 10s timeout: 5s retries: 3 start_period: 20s minio-init: build: context: . dockerfile: Dockerfile.init environment: MINIO_ENDPOINT: http://minio:9000 MINIO_ROOT_USER: ${MINIO_ROOT_USER} MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD} MINIO_BUCKET: my-bucket depends_on: minio: condition: service_healthy volumes: minio_data:
minio-init を待機させます・env_file:MinIO本体の認証情報は
.env ファイルから注入します・environment:初期化サービス固有の設定(エンドポイント・バケット名)は直接渡します
アクセスキーとポリシーの最小権限設計
MinIOを本番運用する場合、MINIO_ROOT_USER はあくまで管理者アカウントです。アプリケーションからの接続には、必要な権限だけを持つ専用ユーザーを作成してアクセスキーを発行します。1. mc adminによるアプリ用ユーザー作成
entrypoint.sh に以下を追加することで、アプリ用ユーザーを自動作成できます。# アプリ用ユーザーの作成(ユーザー名とシークレットキーを指定) mc admin user add local appuser appsecret123 # 既定ポリシーを割り当て(readwrite / readonly / writeonly から選択) mc admin policy attach local readwrite --user appuser
・mc admin policy attach:既定ポリシー(readwrite・readonly・writeonly)を割り当てます
2. バケット単位のカスタムポリシー
特定バケットへの操作のみを許可するカスタムポリシーをJSONで定義できます。フォーマットはAWS IAMポリシーと同じです。# policy.json(my-bucket内のGetObject・PutObjectのみ許可) cat << 'EOF' > /tmp/policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": ["arn:aws:s3:::my-bucket/*"] } ] } EOF # カスタムポリシーを作成してユーザーにアタッチ mc admin policy create local my-bucket-rw /tmp/policy.json mc admin policy attach local my-bucket-rw --user appuser
arn:aws:s3:::バケット名/* と書くと、そのバケット内のオブジェクトだけに絞れます・Action:
s3:ListBucket も必要な場合は "arn:aws:s3:::my-bucket"(スラッシュなし)への ListBucket を別途追加してくださいよくあるエラーと対処法
「ERROR Unable to initialize config system」が出る
MinIOのデータディレクトリ(/data)のパーミッションが原因の場合があります。# ボリュームのデータディレクトリのUID確認(出力例) docker run --rm -v myproject_minio_data:/data minio/minio:RELEASE.2024-10-13T13-34-11Z \ ls -la /data # drwxr-xr-x 2 1000 1000 ... のように表示される(環境により異なります) # MinIOコンテナの実行ユーザーを確認 docker exec minio id # uid=1000(minio) gid=1000(minio) のように表示される(環境により異なります)
「mc: ERROR Unable to initialize new alias from the provided credentials.」が出る
初期化コンテナがMinIOサービスより先に実行されたときに発生します。以下の2点を確認してください。・
depends_on に condition: service_healthy が設定されているか・MinIO本体のDockerfileに
HEALTHCHECK が定義されているか(定義がないと service_healthy を評価できない)バケット名のエラー(InvalidBucketName)
MinIOのバケット名はS3と同じ命名規則に従います。よくある間違いは以下のとおりです。・3~63文字の小英字・数字・ハイフンのみ(アンダースコアは使えない)
・先頭と末尾にハイフンは不可
・IPアドレス形式(例:192.168.0.1)は不可
まとめ
MinIOのDockerfile構成とバケット初期化の要点をまとめます。| やりたいこと | 設計方針 |
|---|---|
| MinIOのDockerfile設計 | 公式イメージをベースにHEALTHCHECKを追加する |
| バケットの自動初期化 | mcコマンドを使った専用minio-initサービスをComposeに追加する |
| 初期化の実行順序の保証 | depends_on + condition: service_healthyで制御する |
| 認証情報の管理 | MINIO_ROOT_USERは管理専用にし、アプリ用ユーザーを別途発行する |
| 最小権限の設計 | mc admin policy createでバケット単位のポリシーを定義する |
| データ永続化 | 名前付きボリュームで/dataをマウントしコンテナ再起動に備える |
>> DockerによるLinuxサーバー構築の実践コースを見る
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 次のページへ:NVIDIAのGPUをDockerfileで活用する|CUDA環境コンテナ構築の実践手順
- 前のページへ:DockerコンテナのPID 1問題を解決する方法|--initフラグとtiniでシグナル処理とゾンビプロセスを防ぐ設計
- この記事の属するカテゴリ:Dockerへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます