Після того як я підключила MinIO через стандартний S3 disk Laravel, виникло наступне питання: чи потрібно тепер мати окрему конфігурацію файлової системи для локального MinIO?
Я вирішила, що ні.
Локальне середовище і production використовують один файловий контракт. В обох випадках Laravel працює через s3.
Відрізняється лише те, куди цей disk підключений.
Тому config/filesystems.php я залишаю загальним, а відмінності передаю через змінні середовища.
Один filesystems.php для всіх середовищ
's3' => [ 'driver' => 's3', 'key' => env('AWS_ACCESS_KEY_ID'), 'secret' => env('AWS_SECRET_ACCESS_KEY'), 'region' => env('AWS_DEFAULT_REGION'), 'bucket' => env('AWS_BUCKET'), 'endpoint' =>У цьому файлі немає перевірки поточного середовища.
Немає окремого minio disk для локальної розробки і другого s3 disk для production.
Є один s3 disk, який отримує свої значення з середовища.
Саме середовище визначає, який сервер, бакет і облікові дані використовувати.
Я не додаю if local у файлову конфігурацію
'endpoint' => app()->environment('local') ? 'http://minio:9000' : null, 'use_path_style_endpoint' => app()->environment('local'),Такий код працюватиме, але він переносить знання про локальний MinIO в загальну конфігурацію застосунку.
Потім може з’явитися ще одне середовище, інший S3-сумісний постачальник або окремий стенд, і умов стане більше.
Мені простіше залишити конфігурацію декларативною: Laravel читає значення, а не вирішує, яке середовище зараз активне.
Локально змінюються лише значення середовища
AWS_ACCESS_KEY_ID=laradockAWS_SECRET_ACCESS_KEY=laradock AWS_DEFAULT_REGION=us-east-1 AWS_BUCKET=local-files AWS_ENDPOINT=http://minio:9000 AWS_USE_PATH_STYLE_ENDPOINT=trueЦі значення описують саме локальну інфраструктуру.
MinIO має свою адресу в мережі Docker, локальні облікові дані та локальний бакет.
У коді застосунку при цьому нічого не змінюється.
У production той самий disk отримує інші значення
AWS_ACCESS_KEY_ID=<production value>AWS_SECRET_ACCESS_KEY=<production secret> AWS_DEFAULT_REGION=<region> AWS_BUCKET=<production bucket> AWS_ENDPOINT=<provider endpoint if required> AWS_USE_PATH_STYLE_ENDPOINT=<true or false>Справжні секрети, назви бакетів та адреси production-сховища я, звичайно, не записую в репозиторій.
Важливий тут сам принцип: структура конфігурації не змінюється.
Інше середовище просто надає інші значення тим самим параметрам.
Endpoint є властивістю середовища, а не Laravel-коду
Локально AWS_ENDPOINT=http://minio:9000 має сенс лише тому, що Laravel працює всередині Docker.
Окремо я вже розбирала, чому з контейнера використовую minio:9000, а не localhost.
Для іншого середовища адреса буде іншою або може взагалі не потребувати явного AWS_ENDPOINT, якщо драйвер використовує стандартну адресу постачальника.
Laravel-коду не потрібно знати причину цієї різниці.
Облікові дані теж не повинні визначати логіку застосунку
Локальні облікові дані MinIO можуть бути простими і призначеними лише для розробки.
У production секрети мають зберігатися відповідно до правил середовища розгортання.
Але в обох випадках Laravel читає їх через ті самі ключі конфігурації.
Прикладний код не отримує доступ до AWS_SECRET_ACCESS_KEY напряму і не приймає рішень на його основі.
Назва бакета також може відрізнятися без зміни коду
Local AWS_BUCKET=local-files | vMinIO bucket Production AWS_BUCKET=<production bucket> | vProduction storage Режим адресації також належить конфігурації середовища
Локальний MinIO з адресою minio:9000 зручно використовувати з AWS_USE_PATH_STYLE_ENDPOINT=true.
Інший постачальник може мати інші вимоги.
Це ще одна причина не записувати режим адресації безпосередньо в filesystems.php як особливий випадок MinIO.
Код роботи з файлами залишається тим самим
Storage::disk('s3')->put( $path, $contents,); $contents = Storage::disk('s3')->get( $path,); Storage::disk('s3')->delete( $path,);Це для мене головний критерій, що межа проведена правильно.
Методи збереження, читання і видалення не повинні знати, чи зараз застосунок працює локально.
Вони працюють із s3 disk. Решта вирішується конфігурацією середовища.
Окремий minio disk часто лише дублює s3
'minio' => [ 'driver' => 's3', // ...], 's3' => [ 'driver' => 's3', // ...],Іноді окремий disk справді має сенс, якщо застосунок одночасно працює з двома різними сховищами.
Але якщо MinIO є лише локальною заміною production S3-сумісного сховища, другий disk додає зайву відмінність між середовищами.
Тоді локально код використовує minio, а в production s3, хоча бізнесово це одна й та сама залежність.
Я залишаю одну назву disk і міняю лише його інфраструктурні параметри.
Після зміни змінних середовища перевіряю кеш Laravel
php artisan config:clearЯкщо .env уже змінений, а Laravel продовжує звертатися до старої адреси, я перевіряю кеш конфігурації.
Це особливо легко пропустити під час перемикання з локального диска на S3-сумісне сховище.
Перевіряю не .env, а вже готову конфігурацію Laravel
config( 'filesystems.disks.s3.endpoint',); config( 'filesystems.disks.s3.bucket',); config( 'filesystems.disks.s3.use_path_style_endpoint',);Сам файл .env ще не доводить, що конфігурація застосунку правильна.
Тому при діагностиці я дивлюся на вже зібрані значення filesystems.disks.s3.
Так простіше відділити проблему конфігурації від проблеми Docker-мережі або самого сховища.
Що залишається однаковим, а що змінюється
Залишається однаковим: - driver = s3- назва disk = s3- Storage::disk('s3')- прикладний код- правила роботи з файлами Змінюється за середовищем: - endpoint- credentials- region- bucket- path-style settingЩо я перевіряю перед додаванням окремої локальної конфігурації
Мій короткий список:
- Чи локальне і production-сховище підтримують один S3-контракт?
- Чи справді потрібен другий disk?
- Чи можна залишити один
driver=s3? - Чи endpoint можна передати через середовище?
- Чи credentials не потрапляють у репозиторій?
- Чи назва бакета задається зовні?
- Чи режим адресації теж конфігурований?
- Чи немає
if localу прикладному коді? - Чи однаковий
Storage::disk('s3')використовується в усіх середовищах?
Середовище змінює значення, а не структуру застосунку
Для мене локальний MinIO не є окремим режимом роботи Laravel.
Це інша реалізація тієї самої інфраструктурної залежності.
Тому я не додаю окремий minio disk, не розгалужую filesystems.php за середовищами і не пишу спеціальний код для локального сховища.
Laravel продовжує працювати через стандартний s3 disk.
Локально змінюються лише адреса, облікові дані, бакет і режим адресації.
Коли контракт однаковий, різниця між середовищами повинна залишатися в конфігурації, а не розповзатися по коду.
Локальне середовище має підставити іншу інфраструктуру під той самий контракт, а не змусити застосунок працювати за іншими правилами.
