Senior: питання на співбесіді з теми «Конфігурація»
Питання з реальних співбесід з відповідями: Laravel і PHP, бази даних, JavaScript і фронтенд, Git, Docker, API, безпека й архітектура. Тими самими темами, що й тести.
1 питання
Проблема: секретів багато, вони змінюються, і їх треба передати новому розробнику, стейджингу й продакшену, не пересилаючи .env у месенджері.
Варіант 1 - зашифрований файл у репозиторії:
php artisan env:encrypt --env=production # створює .env.production.encrypted
php artisan env:decrypt --env=production --key=... # на сервері чи в CI
Зашифрований файл комітять разом з кодом - історія змін і рев'ю як для коду. Ключ зберігають окремо (секрет CI, LARAVEL_ENV_ENCRYPTION_KEY). Опція --readable шифрує лише значення, лишаючи назви змінних видимими в диффах.
Варіант 2 - секрет-менеджер платформи (AWS Secrets Manager, Vault, Doppler, секрети GitHub Actions, змінні Laravel Cloud чи Forge): значення потрапляють у змінні оточення процесу, файлу немає взагалі.
Принципи незалежно від інструмента:
- різні секрети для кожного оточення - ключ стейджингу не відкриває продакшен;
- мінімальні права: CI має лише те, що потрібно для деплою;
- ротація: після звільнення людини чи витоку - змінити, а не лише видалити доступ;
- секрети не в журналах, не у виводі
config:show, не в стектрейсах (APP_DEBUG=false); APP_KEYпри ротації - черезAPP_PREVIOUS_KEYS, щоб не розлогінити всіх.
Що з цього обрати - залежить від інфраструктури: команді з одним сервером вистачить зашифрованого файлу, для багатьох сервісів зручніший централізований менеджер.