← رجوع

تجربتي مع S3 Bucket باستخدام MinIO

R

UNIXMAN

Feb 01, 2026

Article Image

تجربتي مع S3 Bucket باستخدام MinIO: لما احتجت تخزين أفهمه وأتحكم فيه

في مرحلة من المراحل، صرت ألاحظ إن التخزين صار جزء حساس من أي مشروع أشتغل عليه. صور، ملفات مرفوعة من المستخدمين، نسخ احتياطية، بيانات ما تبغى تضيع ولا تكون معلّقة على حل ما تفهمه بالكامل. كنت أعرف S3 كمفهوم، لكن استخدام خدمات سحابية جاهزة كان دايم يخليني أحس إن في طبقة غامضة بيني وبين بياناتي. أدفع، أستخدم، لكن ما عندي تحكم فعلي. من هنا بدأت أبحث عن حل يخلي فكرة S3 بيدي، داخل بيئتي، وبنفس العقلية. وهنا دخل MinIO.

ليش احتجت S3 أصلاً؟

أي مشروع يكبر شوي يبدأ يطلب:
  • تخزين ملفات خارج السيرفر الرئيسي
  • فصل التخزين عن التطبيق
  • إمكانية التوسع بدون كسر النظام
التخزين داخل مجلدات المشروع يمشي بالبدايات، لكن أول ما تدخل أكثر من سيرفر أو تبدأ تفكر بنسخ احتياطية حقيقية، تحس إنك قاعد تبني فوق شيء هش. كنت أبغى تخزين:
  • واضح
  • أفهمه
  • وأتحكم فيه بالكامل

ليش اخترت MinIO؟

MinIO ما حاول يكون خدمة سحابية بديلة بواجهة معقدة. هو ببساطة يقول لك: هذا S3 API… لكن عندك. اللي شدني:
  • متوافق مع S3 API
  • خفيف وسريع
  • تشغله محلي أو على سيرفر
  • Open Source وتعرف وش قاعد يصير
تحس إنك تتعامل مع أداة، مو اشتراك.

تشغيل MinIO باستخدام Docker

هذا هو الإعداد الذي استخدمته لتشغيل MinIO داخل Docker. الهدف منه كان واضح: تشغيل خدمة تخزين S3 محلية، مع واجهة إدارة، وتخزين ثابت ما يضيع مع إعادة التشغيل.

services:
  minio:
    image: minio/minio
    ports:
      - "9000:9000"
      - "9001:9001"
    volumes:
      - minio_storage:/data
    environment:
      MINIO_ROOT_USER: User
      MINIO_ROOT_PASSWORD: Pass#2030
    command: server --console-address ":9001" /data

volumes:
  minio_storage: {}

شرح الإعداد خطوة بخطوة

services هنا نعرّف الخدمات اللي راح يشغلها Docker Compose. في هذا الملف عندنا خدمة واحدة فقط وهي MinIO.

minio: اسم الخدمة. Docker يستخدمه داخليًا للتشغيل والربط.

image: minio/minio الصورة الرسمية لـ MinIO. تشغيل صورة رسمية مهم لأنه يضمن:
  • تحديثات أمنية مستمرة
  • سلوك متوقع بدون مفاجآت
  • توافق كامل مع بروتوكول S3

ports تحديد المنافذ اللي راح تكون مفتوحة من الحاوية إلى السيرفر:
  • 9000: هذا منفذ الـ API، وهو اللي تتصل عليه التطبيقات (Laravel، Node، إلخ).
  • 9001: هذا منفذ لوحة التحكم الخاصة بـ MinIO.
أي تطبيق يستخدم S3 راح يتعامل مع 9000، وأي إدارة أو إعداد يدوي راح يكون من 9001.

volumes: - minio_storage:/data هذا السطر من أهم الأسطر في الإعداد. هو اللي يربط التخزين داخل الحاوية بمساحة ثابتة يديرها Docker. معناه:
  • الملفات ما تنحذف لو طفيت الحاوية
  • البيانات تبقى حتى لو أعدت التشغيل
  • تقدر تنقل الخدمة لسيرفر آخر بدون فقدان التخزين
MinIO نفسه يخزن كل شيء داخل المسار /data، وهذا المسار مربوط مباشرة بالـ Volume.

environment هنا نحدد بيانات الدخول الأساسية:
  • MINIO_ROOT_USER: المستخدم الرئيسي
  • MINIO_ROOT_PASSWORD: كلمة المرور
هذا الحساب يستخدم للإدارة فقط:
  • إنشاء Buckets
  • إدارة المستخدمين
  • تحديد الصلاحيات
في الاستخدام الفعلي، الأفضل:
  • عدم استخدام هذا الحساب داخل التطبيقات
  • إنشاء مستخدمين بصلاحيات محدودة عبر لوحة التحكم
command: server --console-address ":9001" /data هذا هو أمر تشغيل MinIO نفسه. هو يقول:
  • شغّل MinIO كسيرفر
  • خلي التخزين داخل /data
  • شغّل لوحة التحكم على المنفذ 9001
بدون هذا الأمر، الحاوية ما تعرف كيف تبدأ الخدمة.

volumes: minio_storage: {} هنا نعرّف الـ Volume باسم minio_storage. Docker يتكفل بإنشائه وإدارته بدون ما تحتاج تحدد مسار يدوي.

النتيجة بعد التشغيل

بعد تشغيل Docker Compose:
  • MinIO API شغال على المنفذ 9000
  • لوحة التحكم متاحة على 9001
  • التخزين ثابت وما يضيع
  • الخدمة معزولة داخل Docker
هذا الإعداد بسيط، لكنه كافي لبناء نظام تخزين يعتمد عليه، سواء للتجربة أو للاستخدام الحقيقي مع تطبيقات خارجية.
Docker دليل تقني شامل لإدارة الحاويات والبنية المعزولة

استخدامه من سيرفر آخر

النقطة اللي فرقت معي فعلًا: MinIO ما كان مربوط بسيرفر واحد. كان عندي:
  • سيرفر تطبيق
  • وسيرفر تخزين (MinIO)
التطبيق يتعامل مع MinIO عن طريق:
  • Endpoint
  • Access Key
  • Secret Key
ولا يهم وين السيرفر الثاني، طالما الاتصال مضبوط والصلاحيات صحيحة. هنا حسّيت لأول مرة إن التخزين صار خدمة مستقلة فعلًا.

الصلاحيات: الجزء اللي لازم تنتبه له

MinIO يعطيك حرية كاملة… وهذا سلاح ذو حدين. تقدر:
  • تعطي مستخدم صلاحية قراءة فقط
  • أو كتابة فقط
  • أو الوصول لـ Bucket محدد
وأهم درس تعلمته: لا تستخدم Root Credentials في التطبيق. أنا سويت:
  • Bucket مخصص
  • User مخصص للتطبيق
  • Policy محددة بدقة
مثلاً:
  • التطبيق يرفع ويقرأ ملفات
  • ما يقدر يحذف كل شيء
  • وما يشوف Buckets ثانية
أي خطأ هنا ممكن يفتح عليك باب كبير.

التعامل مع API و Access Keys

التعامل مع MinIO من التطبيق مشابه جدًا لـ S3. لكن الفرق إنك:
  • تعرف وين الـ Endpoint
  • تعرف مين المستخدم
  • وتتحكم بالصلاحيات بنفسك
هذا يخليك تفكر أكثر:
  • وين تحط المفاتيح؟
  • كيف تحميها؟
  • كيف تغيرها بدون ما يكسر النظام؟
هنا تعلمت إن إدارة المفاتيح جزء من النظام، مو مجرد إعداد مرة وحدة.

كونه Open Source: حرية ومسؤولية

كون MinIO Open Source شيء ممتاز، لكن يعني إن الأمان مسؤوليتك. ما في أحد:
  • يمنعك من فتح الخدمة للعالم
  • ولا يحميك إذا أعطيت صلاحيات غلط
لازم:
  • تحميه بجدار ناري
  • تحدد مين يوصل له
  • وتراجع الصلاحيات باستمرار
الأداة قوية، لكن استخدامها العشوائي خطر.

وش تعلمت من التجربة؟

من تجربتي مع MinIO:
  • فهمت S3 بشكل عملي
  • تعلمت إن التخزين خدمة مستقلة
  • عرفت قيمة الصلاحيات الدقيقة
حتى لو ما استخدمته دائمًا، التجربة نفسها رفعت فهمي للتخزين بشكل كبير.