MinIOのDockerfile構成とS3互換ストレージ運用|バケット初期化と認証設定の手順

運営:リナックスマスター.JP(代表 宮崎智広)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Docker > MinIOのDockerfile構成とS3互換ストレージ運用|バケット初期化と認証設定の手順
「MinIOのコンテナを再起動したらバケットが消えていた」「初期バケットの作成やアクセスキーの発行を毎回 docker exec で手動実行している」という声は、DockerでMinIOを運用し始めた現場でよく聞きます。

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で初期化の実行順序を保証できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

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"]

・FROM のタグ固定: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_USER:3文字以上の管理者ユーザー名(旧環境変数名 MINIO_ACCESS_KEY)
・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 alias set:接続先サーバーに別名(エイリアス)をつけます
・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}"

・set -e:エラーが出た時点でスクリプトを終了します
・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:

・condition: service_healthy:MinIOのHEALTHCHECKがpassするまで 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 user add:アプリ専用のユーザーとシークレットキーを作成します
・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

・Resource の指定: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) のように表示される(環境により異なります)

ホスト側のボリュームディレクトリの所有者がMinIOコンテナのUID(通常1000)と一致しているか確認してください。

「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をマウントしコンテナ再起動に備える
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、MinIOのようなコンテナベースのサービス設計から、セキュリティを考慮したDockerfile・Compose設計まで体系的に学べる環境を用意しています。

>> DockerによるLinuxサーバー構築の実践コースを見る

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。