database├── factories│   └── UserFactory.php├── migrations│   ├── 0001_01_01_000000_create_users_table.php│   ├── 0001_01_01_000001_create_cache_table.php│   └── 0001_01_01_000002_create_jobs_table.php├── seeders│   └── DatabaseSeeder.php└── database.sqlite4 directories, 6 files

migrations/ — описание таблиц в коде. В блоке «Базы данных» вы создавали таблицу rest в PHPMyAdmin руками: поля, varchar(255), auto_increment, первичный ключ. Миграция делает то же самое, но файлом, который лежит в git и выполняется командой php artisan migrate. Отсюда — воспроизводимость: у коллеги и на сервере получится та же схема, а не «как у меня».

seeders/ — наполнение базы данными (как ваш truncate + вставка 42 ресторанов циклом, только оформленная команда). factories/ — генератор правдоподобных тестовых строк.

database.sqlite — файл базы SQLite, который каркас использует по умолчанию: отдельный сервер поднимать не нужно. В части 4 переключимся на MariaDB.

resources├── css│   └── app.css├── js│   └── app.js└── views    └── welcome.blade.php4 directories, 3 files

views/welcome.blade.php — шаблон стартовой страницы. Blade — это PHP-файл с короткими метками вроде {{ $name }}; Laravel превращает его в обычный PHP и уже его выполняет. Свои шаблоны положим сюда же в этой и в третьей части.

css/app.css и js/app.js — исходники для сборщика Vite, а не то, что отдаёт nginx. Обратите внимание на разницу: файлы из resources/ наружу не видны, браузеру отдаётся результат сборки из public/build/. Его здесь нет — и это нормально, обсудим на слайде про Vite.

.env, /vendor, /node_modules и /public/build в игноре — и это логично:

• .env — секреты конкретной машины: на вашем ноутбуке и на сервере они разные;
• /vendor — пакеты Composer, которые восстанавливаются одной командой composer install из composer.lock (мы ставили их в части 1);
• /public/build — результат сборки ассетов: его пересобирают, а не хранят.

Строка 6. LARAVEL_START — момент старта в микросекундах. Позже по нему фреймворк считает, сколько длилась обработка запроса.

Строки 8–11. Режим обслуживания: если существует storage/framework/maintenance.php, выполняется он, а дальнейший код не запускается. Файл появляется по команде php artisan down (она есть в списке команд artisan) — и сайт начинает отвечать заглушкой «мы на обслуживании», пока вы катите обновление.

Строка 14. Подключается автозагрузчик Composer. Именно поэтому в проекте нет сотен require: класс Illuminate\... находится по правилам PSR-4 сам. Мы это видели в части 1 на примере nesbot/carbon.

Строка 18. bootstrap/app.php возвращает собранный объект приложения — $app. Файл подключается через require once: приложение создаётся один раз на запрос.

Строка 20. Всё. Request::capture() собирает запрос из того, что прислал nginx (метод, путь, заголовки, параметры, тело), handleRequest() прогоняет его через маршруты и middleware и отправляет ответ в буфер вывода.

withRouting — где искать маршруты. web: указывает на routes/web.php (HTTP-запросы браузера), commands: — на routes/console.php (консольные команды). health: '/up' добавляет служебный маршрут-проверку «приложение живо» — им удобно мониторить деплой. Регистрирует его сам каркас, поэтому в нашем route:list --except-vendor (слайд 30) его не будет.

withMiddleware — пустая заглушка //. Middleware — это «фильтры», через которые проходит запрос до маршрута и ответ после него. Заполним её, когда понадобится своё поведение между запросом и маршрутом.

withExceptions — как отдавать ошибки. Здесь настроено: если путь начинается с api/ или клиент ждёт JSON, ошибку отдавать JSON-ом, а не HTML-страницей. Для нашего сайта с HTML-страницами поведение остаётся обычным.

bootstrap/providers.php — список провайдеров приложения: один элемент, AppServiceProvider::class — тот самый файл из app/Providers/, который мы видели в дереве каталогов.

total 16drwxrwxrwx  2 student student 4096 Sep 30 13:56 .drwxrwxrwx 12 student student 4096 Oct 17 10:19 ..-rw-rw-rw-  1 student student  210 Sep 30 13:56 console.php-rw-rw-rw-  1 student student  108 Sep 30 13:56 web.php

В routes/ два файла: web.php — маршруты сайта, console.php — маршруты консоли (108 байт у web.php, 210 — у console.php). Нас интересует первый.

app.phpauth.phpcache.phpdatabase.phpfilesystems.phplogging.phpmail.phpqueue.phpservices.phpsession.php

Десять файлов — по одному на подсистему: приложение (app.php), аутентификация (auth.php), кэш, база данных, файловые хранилища, логирование, почта, очереди, внешние сервисы, сессии.

Каждый файл — просто PHP-массив. Laravel читает их при старте, а значение из кода достают как config('app.name').

Файл на 126 строк — блок прокручивается. Подсвечены строки 16, 29, 42, 68, 98 и 100; между ними длинные комментарии-баннеры, их можно не читать.

Значения по умолчанию подобраны так, что приложение остаётся в безопасном режиме, даже если в .env что-то забыли:

• 'env' => env('APP_ENV', 'production') — если не сказано иное, считаем сервер боевым;
• 'debug' => (bool) env('APP_DEBUG', false) — показ деталей ошибок выключен по умолчанию. Включённый APP_DEBUG на бою — это стектрейсы и переменные окружения прямо в ответе;

• 'timezone' => 'UTC' (строка 68) и 'cipher' => 'AES-256-CBC' (строка 98) — значения без env(): они одинаковы на всех машинах и в .env не вынесены;
• 'key' => env('APP_KEY') (строка 100) — и без значения по умолчанию. Это тот ключ, который сгенерировала установка в части 1 («Application key set successfully»); им шифруются, например, куки — мы их увидим в заголовках ответа.

total 20drwxrwxrwx 2 student student 4096 Sep 30 13:56 .drwxrwxrwx 5 student student 4096 Oct 17 10:19 ..-rw-rw-rw- 1 student student 1473 Sep 30 13:56 0001_01_01_000000_create_users_table.php-rw-rw-rw- 1 student student  873 Sep 30 13:56 0001_01_01_000001_create_cache_table.php-rw-rw-rw- 1 student student 1883 Sep 30 13:56 0001_01_01_000002_create_jobs_table.php

Три файла, и имена начинаются с даты: 0001_01_01_000000_.... Это не украшение, а порядок применения: миграции выполняются по возрастанию имени. Дата 0001_01_01 у каркасных файлов гарантирует, что они отработают раньше ваших.

Рядом лежат ..._000001_create_cache_table.php (таблица кэша) и ..._000002_create_jobs_table.php (очереди) — их мы не трогаем.

Подсвечены строки 14, 24, 30 — три вызова Schema::create(). Метод up() — строки 12–38, обратный ему down() — 43–48.

namespace App\Models; — пространство имён совпадает с путём: App\ → app/. Это правило PSR-4 из composer.json, благодаря которому автозагрузчик находит класс без единого require (часть 1).

class User extends Authenticatable — обычное наследование из блока ООП: модель получает всё поведение «пользователя, которого можно аутентифицировать».

use HasFactory, Notifiable; — это трейты: способ подключить к классу готовое поведение, не выстраивая наследование. В курсе вы реализовывали интерфейсы (lesson.oop.polymorphism.01) — здесь идея похожая, но трейт приносит не только обещание, а готовый код: HasFactory связывает модель с database/factories/UserFactory.php, Notifiable — с отправкой уведомлений.

Атрибуты #[Fillable] и #[Hidden] — метаданные класса в квадратных скобках с #. Fillable перечисляет поля, которые можно заполнять сразу массивом (name, email, password); всё, чего в списке нет, массово не заполняется — защита от ситуации, когда посетитель добавляет в форму поле is_admin. Hidden прячет password и remember_token: при превращении модели в массив или JSON их не будет.

Сравните с public/index.php — это почти он же, только для терминала: те же LARAVEL_START, тот же vendor/autoload.php, тот же bootstrap/app.php. Разница в последних строках: вместо handleRequest(Request::capture()) — handleCommand(new ArgvInput) и exit($status).

То есть запрос приходит не из браузера, а из аргументов командной строки (ArgvInput), а код возврата уходит в shell. Отсюда важное следствие: команда artisan видит то же приложение, те же конфиги и ту же базу, что и сайт.

Первая строка вывода — версия каркаса: Laravel Framework 13.37.0. Дальше общие параметры (--help, --verbose, --env) и первые команды. Мы вывод обрезали (| head -42), полный список длиннее.

Что из показанного пригодится сразу:

• about — сводка по приложению (мы запускали её в части 1);
• serve — встроенный сервер разработки, следующий слайд;
• migrate — применить миграции (часть 4);
• tinker — интерактивная консоль внутри приложения (ей мы воспользуемся через пару слайдов);
• down / up — режим обслуживания: тот самый storage/framework/maintenance.php из точки входа;

• test — запуск тестов (часть 6);
• optimize — закэшировать конфиг и метаданные (часть 6);
• pail — смотреть лог приложения в реальном времени.

Команды сгруппированы по префиксам: auth:, cache: и дальше по алфавиту — в обрезанном выводе видны auth:clear-resets, cache:clear, cache:forget, cache:prune-stale-tags.

Есть и группа make: — команды, которые создают файлы за вас: контроллер, модель, миграцию, тест. В этом выводе их нет (мы обрезали список), но именно с них начнётся часть 3: вместо того чтобы создавать файлы руками и угадывать имена, мы скажем artisan, что нужно.

9:        @fonts12:        @if (file_exists(public_path('build/manifest.json')) || file_exists(public_path('hot')))13:            @vite(['resources/css/app.css', 'resources/js/app.js'])

Это строки 9, 12 и 13 шаблона resources/views/welcome.blade.php. Логика простая:

• @fonts — директива подключения шрифтов;
• @if (file_exists(public_path('build/manifest.json')) || file_exists(public_path('hot'))) — проверить, есть ли вообще сборка ассетов: либо готовый манифест в public/build/, либо запущенный dev-сервер Vite (он оставляет файл public/hot);
• @vite(['resources/css/app.css', 'resources/js/app.js']) — подключить собранные css и js.

В public/ ни build/, ни hot нет — мы это видели в ls -la public. Значит, условие ложно, @vite не выполняется, и стартовая страница обходится теми стилями, что зашиты в сам шаблон.

package.json описывает, чем собирают ассеты: скрипт build — это vite build, dev — просто vite (dev-сервер с горячей перезаменой). В devDependencies — vite ^8.0.0, laravel-vite-plugin ^3.1, tailwindcss ^4.0.0 и @tailwindcss/vite, concurrently ^10.0.3.

Чтобы всё это заработало, нужны Node.js и npm install, а затем npm run build. В public/ нет каталога build/ — состав public/ мы смотрели выше, там четыре файла. Значит, сборку ассетов на стенде не запускали.

Что происходит. serve поднимает встроенный сервер разработки PHP на 127.0.0.1:8000 — nginx и PHP-FPM для него не нужны. Мы запустили его через nohup ... &, а вывод увели в /tmp/serve.log: иначе сервер занял бы терминал и не дал бы выполнить следующие команды. Отсюда же sleep 4 — даём серверу подняться перед первым запросом.

Что намерили. GET / → HTTP 200, 70 403 байта тела, 0.439242 с. Заголовок страницы — <title>Laravel</title>. Последний ps показывает ровно один процесс php (PID 49206, родитель 49199 — оболочка, которая его запустила).

Почему это только для разработки.

• Адрес 127.0.0.1: сервер слушает локальный интерфейс, с другой машины сайт не открыть.
• Один процесс на все запросы: ни пула воркеров PHP-FPM, ни очереди nginx.
• Логи — только то, что сервер печатает в консоль (мы увели это в /tmp/serve.log). Отдельных access.log и error.log, как у nginx, а значит и привычного инструмента диагностики (lesson.programs.01), здесь нет.
• Нет server_name: второй сайт рядом не поселить.

Всё это даёт nginx — поэтому вторую половину части мы потратим на vhost.

Два изменения в routes/web.php:

1. Корневой маршрут больше не рендерит welcome, а возвращает строку. Никакого echo, никакого HTML-каркаса: что вернуло замыкание, то и стало телом ответа. Обёртку в HTTP-ответ (статус, заголовки) Laravel берёт на себя.
2. Добавлен маршрут /hello/{name}: фигурные скобки в пути — это параметр. Замыкание объявлено как function (string $name) — типизированный аргумент, значение берётся прямо из адреса. Внутри — view('hello', ['name' => $name]): «отрендерить шаблон hello, передав в него массив с ключом name».

Hello, Laravel!GET /hello/студент -> HTTP 200, 435 байт, 0.029839 с

Проверяем без браузера — curl-ом, он показывает ровно то, что ушло по сети.

Первая команда печатает тело ответа на /: Hello, Laravel!. Вторая запрашивает /hello/студент и меряет только метрики: HTTP 200, 435 байт, 0.029839 с.

view('hello') ищет файл resources/views/hello.blade.php: имя шаблона — это путь относительно resources/views/ без суффикса .blade.php.

В шаблоне три подстановки:

• строка 6 и строка 9 — {{ $name }}: переменная, которую мы передали массивом из маршрута;
• строка 11 — {{ now()->locale('ru')->isoFormat('D MMMM YYYY, HH:mm') }}: now() возвращает объект даты и времени (тот самый Carbon, который мы ставили через Composer в части 1), locale('ru') переключает язык, isoFormat() задаёт формат.

<!DOCTYPE html><html lang="ru"><head>    <meta charset="utf-8">    <meta name="viewport" content="width=device-width, initial-scale=1">    <title>Привет, студент</title></head><body>    <h1>Привет, студент!</h1>    <p>Это шаблон Blade: значение приехало из адреса <code>/hello/{name}</code>.</p>    <p>Сейчас: 17 октября 2026, 10:20</p></body></html>

Ответ — 13 строк, ровно как в шаблоне: Blade не добавляет своей разметки, он только подставляет значения вместо {{ }}. Сравните:

Всё остальное — байт в байт тот же HTML, что мы написали.

total 0lrwxrwxrwx 1 root root 34 Oct 17 06:04 default -> /etc/nginx/sites-available/default

В sites-enabled/ одна символическая ссылка — default на sites-available/default. Это дефолтный сайт из пакета: он отвечает на запросы, для которых не нашлось своего server_name.

Работаем по схеме из lesson.linux.05–lesson.linux.06: файл vhost кладём в sites-available/, ссылку на него — в sites-enabled/. Домен project-laravel.rs при этом уже работает: dnsmasq отдаёт для всей зоны .rs адрес 127.0.0.1, поэтому настраивать DNS заново не нужно. Позже access.log это подтвердит — в строках будет client: 127.0.0.1.

/etc/nginx/fastcgi.conf:2:fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

grep искал SCRIPT_FILENAME в двух файлах и нашёл только в одном: /etc/nginx/fastcgi.conf, строка 2. Значит, в /etc/nginx/fastcgi_params этого параметра нет — иначе grep напечатал бы и его строку.

Почему это важно: по протоколу FastCGI веб-сервер передаёт PHP-FPM набор параметров, и SCRIPT_FILENAME — путь к файлу, который нужно выполнить. Без него PHP-FPM не знает, что запускать.

Мы подключаем fastcgi_params и дописываем параметр руками:

$document_root — значение директивы root для этого location, $fastcgi_script_name — путь к скрипту из запроса. Вместе они дадут /home/student/recoursia/project-laravel/public/index.php.

Конфиг выглядит разумно: server_name project-laravel.rs, index index.php index.html, .php уходит в PHP-FPM через сокет php8.3-fpm.sock. Одна строка всё ломает — root /home/student/recoursia/project-laravel;.

Дальше — привычный ритуал из lesson.linux.06: ссылка в sites-enabled, sudo nginx -t (проверить синтаксис до перезагрузки), systemctl reload nginx (перечитать конфиг без обрыва соединений), и только потом запрос.

nginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successfulGET http://project-laravel.rs/ -> 403<html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center><hr><center>nginx/1.24.0 (Ubuntu)</center></body></html>--- access.log ---127.0.0.1 - - [17/Oct/2026:10:20:33 +0000] "GET / HTTP/1.1" 403 162 "-" "curl/8.5.0"127.0.0.1 - - [17/Oct/2026:10:20:33 +0000] "GET / HTTP/1.1" 403 162 "-" "curl/8.5.0"

Разбор. nginx -t говорит, что синтаксис в порядке: конфиг корректен, ошибка смысловая, её проверка синтаксиса не ловит.

GET / → 403. И тело ответа — страница самого nginx: <center>nginx/1.24.0 (Ubuntu)</center>. Это значит, что до PHP дело не дошло: Laravel не запускался, ошибку вернул веб-сервер.

Почему 403, а не 404? nginx ищет в корне сайта index.php или index.html. В папке проекта их нет — index.php лежит на уровень глубже, в public/. Не найдя индексного файла, nginx хотел бы показать список каталога, но autoindex по умолчанию выключен — отсюда «доступ запрещён». Строку directory index of "/home/student/recoursia/project-laravel/" is forbidden мы увидим в error.log на слайде про логи.

И это ещё полбеды: при таком root снаружи виден весь проект, включая .env с ключом приложения и доступом к базе. Никакого deny для скрытых файлов в этом варианте нет — проверять мы это, разумеется, не будем.

Поправили одну строку: root теперь указывает на public. Всё остальное прежнее — и location / с try_files по-прежнему нет.

Что должно произойти по нашей теории? Корень сайта правильный, index.php в нём есть, значит главная страница заработает. А вот /hello/студент — не файл на диске, и nginx об этом ничего не знает.

nginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successfulGET / -> 200GET /hello/студент -> 404<html><head><title>404 Not Found</title></head><body><center><h1>404 Not Found</h1></center><hr><center>nginx/1.24.0 (Ubuntu)</center></body>

Разбор. GET / → 200: index index.php сработал, nginx передал public/index.php в PHP-FPM, Laravel отдал строку Hello, Laravel!.

GET /hello/студент → 404, и снова страница с подписью nginx/1.24.0 (Ubuntu) — то есть 404 вернул nginx, не Laravel. Отличать их полезно: у Laravel страница ошибки своя.

Причина: nginx обслуживает запрос как запрос к файлу. Он ищет на диске /home/student/recoursia/project-laravel/public/hello/студент, не находит и сам отдаёт 404. До index.php — а значит, и до таблицы маршрутов — запрос не доходит вообще.

Строки 3–5. listen 80 и listen [::]:80 — принимаем HTTP на 80-м порту по IPv4 и IPv6. server_name project-laravel.rs — этим доменом занимается именно этот блок server.

Строка 8. root .../project-laravel/public — корень сайта обязательно public. Всё, что выше, для nginx не существует.

Строка 9. index index.php index.html — чем отвечать на запрос к каталогу.

Строки 12–13. Главное новое:

Проверки идут слева направо, срабатывает первая совпавшая:

Именно поэтому статика из public/ отдаётся быстро и без PHP, а всё остальное уходит в роутер Laravel.

?$query_string в конце — обязательная деталь: без неё параметры после «?» потеряются при передаче, и ?page=2 из пагинации (lesson.http.i.05) до Laravel не доедет.

Строки 17–20. .php уходит в PHP-FPM через unix-сокет /run/php/php8.3-fpm.sock — тот же адрес и тот же протокол FastCGI, что в lesson.linux.06. include fastcgi_params + явный SCRIPT_FILENAME — по причине, которую мы проверили grep-ом.

Строки 24–25. location ~ /\. { deny all; } — любой путь, в котором есть «точка после слэша» (.env, .git, .htaccess), запрещён. Второй рубеж защиты к тому, что root уже спрятал эти файлы.

Оба маршрута работают. GET / → 200 и тело Hello, Laravel!, GET /hello/студент → 200. Значит, try_files передаёт запрос в index.php, а роутер Laravel находит в таблице и строку, и параметр.

Кто отвечает. Server: nginx/1.24.0 (Ubuntu) — отвечает nginx, встроенный сервер разработки больше не участвует.

Content-Type: text/html; charset=utf-8 — заголовок, по которому браузер понимает, как показывать тело (вы разбирали его в lesson.http.i.02). Указана кодировка UTF-8 — поэтому «студент» в ответе не превращается в кракозябры.

Cache-Control: no-cache, private — ответ динамический: промежуточным кэшам его хранить нельзя, он личный для этого пользователя.

Connection: keep-alive — соединение не закрывается после ответа, следующий запрос уйдёт по нему же.

Две куки в ответе.

Set-Cookie: XSRF-TOKEN=... и Set-Cookie: laravel-session=..., обе с Max-Age=7200 (два часа), path=/ и samesite=lax. У laravel-session дополнительно стоит httponly — такую куку не прочитать из JavaScript.

Значение — не открытый текст. Это base64; если раскодировать, получится JSON из четырёх полей: iv (24 символа base64 = 16 байт — размер блока шифра, в config/app.php стоит 'cipher' => 'AES-256-CBC'), value (зашифрованное содержимое), mac (64 hex-символа — код аутентификации, проверка, что значение не подменили) и пустой tag.

То есть приложение уже ведёт сессию и выдаёт токен защиты от подделки запроса. Что с этим делать — разберём в части 5, когда будем отправлять формы: без XSRF-TOKEN POST-запрос будет отклонён.

access.log — кто приходил. Поля в строке: IP клиента, время, "метод путь версия", статус-код, число байт, referer и User-Agent (у нас curl/8.5.0). Этот формат вы разбирали в lesson.programs.01 и lesson.http.i.01.

Три детали, на которые стоит посмотреть:

• путь записан как /hello/%D1%81%D1%82%D1%83%D0%B4%D0%B5%D0%BD%D1%82 — в лог попадает URL в том виде, в каком он пришёл по сети, в percent-encoding;
• "HEAD / HTTP/1.1" 200 0 — наш curl -I отправил HEAD-запрос: заголовки те же, что и на GET, а тела нет, поэтому байт 0;
• client: 127.0.0.1 — домен project-laravel.rs разрешился в локальный адрес: это работа dnsmasq из lesson.linux.05.

error.log — почему не получилось. Здесь лежат объяснения обеих наших ошибок, и времена совпадают с попытками:

• 10:20:33 — directory index of "/home/student/recoursia/project-laravel/" is forbidden. Это вариант 1: root на папке проекта, индексного файла нет, список каталога показывать запрещено → те самые 403.
• 10:20:35 — open() "/home/student/recoursia/project-laravel/public/hello/студент" failed (2: No such file or directory), дважды. Это вариант 2: nginx буквально искал файл с таким именем → 404. Строка даже показывает путь, который он подставил, — сразу видно, что root уже правильный, а try_files нет.