Подготовка к production и деплой приложения

Поздравляем! Ваш интернет-магазин готов на локальном компьютере. Последний, но один из самых ответственных этапов разработки — это Деплой (Deployment), то есть перенос кода на боевой сервер (Production), где приложение будет доступно реальным пользователям интернета. Среда Production кардинально отличается от вашей локальной среды (Local). Локально мы используем инструменты для отладки, видим подробные сообщения об ошибках, наши файлы не кешируются для удобства разработки. На боевом сервере приоритеты меняются на 180 градусов: на первом месте стоят безопасность и максимальная производительность. Если на Production произойдет ошибка, пользователь должен увидеть красивую страницу 'Что-то пошло не так (500)', а не экран с кусками вашего кода и паролями от базы данных. Процесс деплоя включает клонирование кода из Git-репозитория на сервер (обычно под управлением ОС Linux: Ubuntu или Debian), установку зависимостей, настройку окружения и оптимизацию фреймворка.

Первый шаг на сервере — это настройка файла .env. Этот файл не переносится через Git, вы создаете его на сервере вручную. Ключевые изменения: параметр APP_ENV меняем с 'local' на production. Критически важно установить APP_DEBUG=false. Если оставить true, любая ошибка раскроет злоумышленникам структуру вашей БД и ключи API! Установите корректный APP_URL=https://yourdomain.com. Далее, заполните данные для подключения к боевой базе данных (DB_HOST, DB_DATABASE и т.д.). И, наконец, замените тестовые ключи платежных систем (Stripe, Vipps) на боевые (Live Keys). После настройки .env мы устанавливаем PHP-зависимости. В отличие от локального ПК, на сервере нам не нужны пакеты для тестирования или генерации кода. Поэтому мы запускаем команду composer install --optimize-autoloader --no-dev. Флаг --no-dev исключает установку библиотек для разработки, экономя место и повышая безопасность.

bash

# Пример скрипта деплоя (bash-команды, выполняемые на сервере Ubuntu)

# 1. Переходим в папку проекта
cd /var/www/myshop

# 2. Получаем последние обновления кода из ветки main
git pull origin main

# 3. Устанавливаем зависимости без dev-пакетов
composer install --optimize-autoloader --no-dev

# 4. Выполняем миграции базы данных (флаг --force нужен для production)
php artisan migrate --force

# 5. Сборка фронтенда (если используется Vite/NPM)
npm install
npm run build

# 6. ОПТИМИЗАЦИЯ LARAVEL (Кеширование)
# Кешируем конфигурацию (.env)
php artisan config:cache
# Кешируем маршруты (ускоряет роутинг)
php artisan route:cache
# Кешируем скомпилированные Blade шаблоны
php artisan view:cache
# Кешируем события
php artisan event:cache

# 7. Настройка прав доступа к папкам (важно для Linux)
chown -R www-data:www-data storage bootstrap/cache
chmod -R 775 storage bootstrap/cache

Обратите внимание на блок команд оптимизации в коде выше. Фреймворк Laravel при каждом запросе пользователя читает десятки конфигурационных файлов и проверяет сотни маршрутов. В production это недопустимая трата ресурсов. Команды php artisan config:cache и route:cache собирают все настройки и маршруты в единые плоские файлы, которые PHP читает мгновенно. Это увеличивает скорость работы приложения в несколько раз! Однако помните: после того как вы закешировали конфиг, Laravel перестает читать файл .env. Если вы изменили пароль от БД или ключ Stripe в .env, изменения не вступят в силу, пока вы снова не запустите php artisan config:cache. Также крайне важным аспектом является настройка прав доступа в Linux (команды chown и chmod). Веб-сервер (Nginx или Apache) работает от имени пользователя www-data. Этот пользователь должен иметь права на запись в папки storage (для логов, сессий, загруженных картинок) и bootstrap/cache (для файлов кеша). И последнее: для работы с платежными системами ваш сайт обязан работать по защищенному протоколу HTTPS. На сервере необходимо установить SSL-сертификат (например, бесплатный от Let's Encrypt).

Задание

Подготовьте ваше приложение к релизу, сымитировав процесс деплоя локально.

Измените в файле .env параметр APP_DEBUG на false.
Выполните команду php artisan config:cache.
Попробуйте намеренно вызвать ошибку в коде (например, обратитесь к несуществующей переменной) и посмотрите, как теперь выглядит страница ошибки.
Выполните php artisan route:cache и view:cache.
Очистите все кеши командой php artisan optimize:clear, чтобы вернуть приложение в режим разработки.

10 баллов

Почему при деплое на боевой сервер параметр APP_DEBUG в файле .env ОБЯЗАТЕЛЬНО должен быть установлен в false?

Потому что с APP_DEBUG=true Laravel работает слишком быстро, и сервер может перегреться

Чтобы скрыть детальную информацию об ошибках, которая содержит пути к файлам сервера, структуру БД и пароли, предотвращая их утечку злоумышленникам

Это отключает кеширование браузера

Чтобы база данных автоматически делала бэкапы

Напишите команду artisan, которая используется для объединения всех конфигурационных файлов в один кеш-файл для ускорения работы приложения.

Флеш-карточки

1 /

Зачем нужен флаг --no-dev при выполнении команды composer install на сервере?

Нажмите, чтобы увидеть ответ

Чтобы исключить установку пакетов, необходимых только для разработки (например, phpunit, faker). Это экономит дисковое пространство и повышает безопасность приложения.

Нажмите, чтобы вернуться

Уроки курса