Чому я перевіряю MinIO з контейнера застосунку, а не лише через браузер

Після запуску MinIO я могла відкрити його веб-консоль у браузері. На перший погляд це виглядало як достатнє підтвердження: контейнер працює, порт відповідає, MinIO доступний.

Але Laravel не звертається до MinIO тим самим шляхом, що й браузер.

Браузер працює на моєму комп’ютері, а PHP виконується всередині контейнера.

Як я вже розбирала окремо, localhost усередині контейнера означає сам контейнер.

Тому для перевірки сховища мені важливо тестувати не лише MinIO взагалі, а саме маршрут, яким користуватиметься застосунок.

Обидва маршрути закінчуються в MinIO, але проходять через різні частини мережі.

У першому випадку Docker публікує порт для комп’ютера.

У другому випадку два контейнери спілкуються через внутрішню мережу Docker.

Тому успіх першого маршруту не є перевіркою другого.

Якщо в браузері відкривається http://localhost:9001, я знаю кілька корисних речей:

• контейнер MinIO запущений;
• веб-консоль слухає свій порт;
• порт опублікований на комп’ютер;
• маршрут від браузера до цього порту працює.

Але я ще не знаю, чи ім’я minio знаходиться з контейнера застосунку, чи доступний порт 9000 і чи може Laravel дістатися S3-сумісного API.

Цю команду важливо виконати саме в контейнері, з якого Laravel буде звертатися до MinIO.

Адреса minio:9000 перевіряє внутрішнє ім’я сервісу та порт S3-сумісного API.

Шлях /minio/health/live дає просту перевірку того, що сервіс живий і відповідає через потрібний мережевий маршрут.

Успішна відповідь уже доводить значно більше, ніж просто відкрита веб-консоль.

Контейнер застосунку зміг знайти сервіс minio, встановити з’єднання з портом 9000 і отримати відповідь від MinIO.

Тобто базова мережева передумова для Laravel Filesystem уже виконана.

Це важливе обмеження.

200 OK від /minio/health/live не означає, що Laravel уже правильно налаштував облікові дані або має доступ до потрібного бакета.

Перевірка стану відповідає лише на мережеве питання: чи може потрібне середовище дістатися MinIO.

Наступним шаром я окремо перевіряю роботу через Laravel Storage.

Коли мережевий маршрут уже підтверджений, я переходжу до наступного шару: підключення MinIO через стандартний S3 disk.

Тут перевіряються вже облікові дані, бакет, S3-конфігурація і реальна операція з об’єктом.

Завдяки такій послідовності я не змішую мережеву проблему з помилкою Laravel Filesystem.

Мені подобається така послідовність, бо кожна помилка звужує область пошуку.

Якщо не знаходиться ім’я minio, немає сенсу змінювати S3 credentials.

Якщо /minio/health/live відповідає, але Storage::put() падає, мережа вже значно менш імовірна причина.

Так діагностика стає послідовною, а не набором випадкових змін конфігурації.

Якщо ця команда не знаходить minio, проблема виникає ще до HTTP.

Я перевіряю, чи обидва контейнери підключені до потрібної мережі Docker і чи справді сервіс має ім’я minio.

Лише після цього має сенс перевіряти сам порт.

Можлива й інша ситуація: minio успішно знаходиться, але звернення до 9000 не працює.

Тоді вже дивлюся, чи сервіс запущений, який порт він слухає і чи використовую внутрішній порт контейнера, а не номер, призначений лише для доступу з комп’ютера.

Тобто пошук імені та доступність порту я теж не змішую в одну перевірку.

Якщо Laravel виконується в одному контейнері, а я запускаю curl на своєму комп’ютері, я знову перевіряю інший маршрут.

Тому найкорисніша діагностична команда виконується саме там, де потім працюватиме PHP.

Це правило корисне не тільки для MinIO. Воно так само працює для Redis, бази даних, поштового сервісу та інших залежностей у Docker.

Я не відмовляюся від перевірки веб-консолі.

Вона зручна, щоб переконатися, що MinIO запущений, зайти в бакет, побачити об’єкти та перевірити локальні налаштування.

Просто я не використовую її як доказ того, що Laravel уже має робочий шлях до S3 API.

Мій короткий список:

• Чи контейнер MinIO запущений?
• Чи веб-консоль відкривається з комп’ютера?
• Чи контейнер застосунку знаходить ім’я minio?
• Чи обидва сервіси мають спільну мережу Docker?
• Чи використовується внутрішній порт 9000?
• Чи /minio/health/live відповідає з контейнера застосунку?
• Чи Laravel використовує правильний AWS_ENDPOINT?
• Чи правильні credentials і bucket?
• Чи працює реальний запис через Storage::disk('s3')?

Відкрити MinIO в браузері корисно, але цього недостатньо для перевірки Laravel.

Браузер і контейнер застосунку приходять до MinIO різними мережевими шляхами.

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

Якщо вона проходить, я вже знаю, що Docker-ім’я, мережа і порт працюють.

Після цього можна переходити на наступний рівень і перевіряти credentials, bucket та Laravel Filesystem.

Хороша перевірка відтворює шлях реального коду, а не лише доводить, що сервіс доступний звідкись.