MinIO у Laradock: локальне S3-сумісне сховище для Laravel

Коли Laravel-проєкт працює лише з локальним диском, усе виглядає просто: файл записується в storage, а застосунок читає його з тієї самої файлової системи.

Але production-сховище часто працює інакше. Файли можуть жити в S3 або в іншому S3-сумісному сховищі, бути приватними, завантажуватися напряму з браузера і відкриватися через тимчасові посилання.

Якщо локально розробляти тільки через звичайний диск, частина важливої поведінки взагалі не перевіряється.

Саме для цього мені став у пригоді MinIO.

Моя мета не в тому, щоб повністю відтворити AWS на ноутбуці.

Мені потрібне середовище, у якому Laravel працює не з локальним каталогом, а з об’єктним сховищем через S3-сумісний API.

Це дозволяє локально перевіряти сценарії, які на звичайному диску поводяться інакше:

• приватні файли;
• bucket замість локального каталогу;
• тимчасові посилання;
• пряме завантаження файлів;
• S3 endpoint;
• роботу Laravel Filesystem через драйвер s3.

Технічно можна було б підключити локальний проєкт прямо до AWS.

Але для щоденної розробки я цього не хочу.

Локальні тести не повинні створювати випадкові файли у справжньому bucket, залежати від інтернету або використовувати production-подібні credentials лише для перевірки звичайного сценарію завантаження.

MinIO залишає весь цей цикл усередині Docker-середовища.

Першим кроком я не почала писати новий Dockerfile або окремий Compose-сервіс.

Спочатку перевірила сам Laradock.

У ньому вже був сервіс minio з власними compose.yml і defaults.env.

Це важливий практичний принцип: перед додаванням нового контейнера варто перевірити, чи середовище вже не має готової інтеграції.

У нашому Laradock API MinIO працює на порту 9000, а веб-консоль - на 9001.

Ці два порти мають різне призначення.

Laravel звертається до S3-сумісного API на 9000.

Порт 9001 потрібен мені як розробниці: відкрити консоль, побачити bucket, перевірити об’єкти та налаштування.

Це одна з деталей, яку легко пропустити.

У браузері на моєму комп’ютері localhost:9001 означає прокинутий порт MinIO.

Але всередині PHP-контейнера localhost означає сам PHP-контейнер.

Тому застосунок звертається до MinIO через ім’я Docker-сервісу:

http://minio:9000

Оскільки сервіс уже є в Laradock, мені не потрібен окремий стек лише для MinIO.

Він запускається разом з іншими локальними сервісами і використовує ту саму Docker-мережу.

Відкрита веб-консоль ще не доводить, що Laravel-контейнер бачить MinIO.

Тому я окремо перевірила адресу http://minio:9000/minio/health/live з PHP-середовища.

Відповідь 200 OK підтверджує саме той шлях, яким пізніше користуватиметься застосунок.

Одна з причин, чому мені подобається цей підхід: я не створюю окрему MinIO-реалізацію файлової системи.

Laravel уже працює з S3 через Filesystem. Для локального середовища змінюються credentials, bucket і endpoint.

Бізнесовий код при цьому продовжує працювати через Storage, а не знати, чи за ним зараз MinIO або зовнішнє S3-сховище.

Для локального MinIO я використовую AWS_USE_PATH_STYLE_ENDPOINT=true.

Тоді bucket передається в шляху запиту, що добре працює з локальним endpoint на Docker service name.

Це прибирає необхідність створювати окремі локальні DNS-імена для кожного bucket.

Якщо файли за задумом не є публічними, я не роблю bucket відкритим лише для зручності локальної розробки.

Інакше локальне середовище приховує важливу частину майбутньої поведінки.

Приватний bucket змушує одразу правильно продумати, як застосунок видає доступ до файла.

Для простого Storage::put() обидва варіанти можуть виглядати майже однаково.

Але далі поведінка розходиться.

Об’єктне сховище має endpoint, bucket, HTTP-доступ, правила видимості та механізми підписаних посилань.

Саме тому я хочу бачити цю модель уже під час локальної розробки.

Сам контейнер MinIO ще не вирішує роботу з файлами в застосунку.

Але після цього в мене є локальна основа, на якій можна окремо перевіряти Laravel Filesystem, приватний доступ, temporaryUrl(), прямі завантаження та інші S3-сценарії.

Саме цим наступним крокам я хочу присвятити окремі статті серії.

Мій базовий список:

• Чи є сервіс MinIO в Laradock?
• Чи контейнер запущений?
• Чи відкривається веб-консоль на порту 9001?
• Чи PHP-контейнер бачить http://minio:9000?
• Чи проходить health check?
• Чи створений потрібний bucket?
• Чи Laravel використовує S3 driver, а не окрему MinIO-реалізацію?
• Чи endpoint усередині Docker використовує ім’я сервісу, а не localhost?
• Чи приватні файли залишаються приватними?

Сам по собі MinIO не є метою.

Його цінність для мене в тому, що локальний Laravel-проєкт починає працювати з тією самою моделлю зберігання файлів, яка потрібна для S3-сумісного production-сховища.

Я можу розробляти без залежності від справжнього AWS, але при цьому не спрощувати файлову систему до локального каталогу.

А Laradock робить перший крок особливо простим, бо MinIO вже є серед його сервісів.

Для мене MinIO локально - це не заміна AWS, а спосіб перевіряти S3-поведінку до того, як код потрапить у production.