SymfonyWorld Online 2020
100% online
30+ talks + workshops
Live + Replay watch talks later

Шаг 5: Поиск и устранение неисправностей

5.0 version
Maintained

Поиск и устранение неисправностей

Настройка проекта также подразумевает наличие правильных инструментов для отладки.

Установка дополнительных зависимостей

Помните, наш проект создан с очень небольшим количеством зависимостей: без шаблонизатора, без инструментов для отладки, без логера. Такой подход позволяет добавить другие зависимости только тогда, когда они вам нужны. Зачем вам шаблонизатор, если вы разрабатываете HTTP API или CLI-инструмент?

Как добавить больше зависимостей? Через Composer. Помимо «обычных» Composer-пакетов, мы будем работать с двумя «специальными» видами пакетов:

  • Компоненты Symfony: пакеты с базовой функциональностью и низкоуровневыми абстракциями, необходимые большинству приложений (маршрутизация, консоль, HTTP-клиент, почтовый клиент, кеш и т.д.);
  • Бандлы Symfony: пакеты, которые добавляют высокоуровневую функциональность или предлагают интеграцию со сторонними библиотеками (эти бандлы в основном разрабатываются сообществом).

Для начала давайте добавим Symfony Profiler, который поможет сэкономить много времени в поиске источника проблемы:

1
$ symfony composer req profiler --dev

profiler — это псевдоним для пакета symfony/profiler-pack.

Псевдонимы — это не функция самого Composer, а концепция Symfony, чтобы облегчить нам жизнь. Псевдонимы — это ярлыки для популярных Composer-пакетов. Вашему приложению нужен ORM? Установите orm. Хотите разработать API? Установите api. Псевдонимы автоматически преобразуются в один или несколько обычных Composer-пакетов. Псевдонимы назначаются основной командой Symfony.

Ещё одна интересная особенность — можно не указывать вендора symfony в имени пакета. Поэтому, например, вместо symfony/cache набирайте cache.

Совет

Мы уже упоминали Composer-плагин symfony/flex. Псевдонимы — лишь одна из его функциональных возможностей.

Понимание окружений Symfony

Вы заметили флаг --dev при использовании команды composer req? Поскольку Symfony Profiler имеет смысл использовать во время разработки, то не стоит устанавливать его в продакшене.

Symfony поддерживает создание окружений. По умолчанию есть три окружения с возможностью добавить дополнительные: dev, prod и test. Все окружения используют один и тот же код, но имеют разные конфигурации.

Например, в окружении dev все инструменты отладки включены. Когда как в окружении prod такого нет, потому что приложение должно быть оптимизировано для повышения производительности.

Изменяя значение переменной окружения APP_ENV можно переключаться с одного окружения на другое.

Во время развёртывания на SymfonyCloud, окружение (сохранённое в APP_ENV) автоматически переключится на prod.

Управление конфигурациями окружений

Переменная APP_ENV может быть задана с помощью «настоящих» переменных окружения в терминале:

1
$ export APP_ENV=dev

Переменные окружения, такие как APP_ENV, рекомендуется явно определять на продакшен-серверах. Однако в процессе разработки установка таким образом множество переменных окружения может стать утомительной. Поэтому вместо этого определите их в файле .env.

При создании проекта был автоматически сгенерирован файл .env:

.env
1
2
3
4
5
6
###> symfony/framework-bundle ###
APP_ENV=dev
APP_SECRET=c2927f273163f7225a358e3a1bbbed8a
#TRUSTED_PROXIES=127.0.0.1,127.0.0.2
#TRUSTED_HOSTS='^localhost|example\.com$'
###< symfony/framework-bundle ###

Совет

Благодаря использованию рецептов Symfony Flex, любой пакет может добавить свои переменные окружения в этот файл.

Файл .env хранится в репозитории и содержит значения по умолчанию для продакшена. Вы можете задать свои значения, создав файл .env.local. Этот файл не хранится в репозитории, поэтому изначально игнорируется в .gitignore.

Никогда не храните конфиденциальную информацию в этих файлах. Позже мы рассмотрим, как управлять такими видами данных.

Логирование всех действий

По умолчанию возможности отладки и логирования ограничены в новых проектах. Давайте добавим дополнительные инструменты, которые помогут нам в решении проблем как в процессе разработке, так и в продакшене:

1
$ symfony composer req logger

Установим инструменты отладки только в окружении разработчика:

1
$ symfony composer req debug --dev

Изучение средств отладки Symfony

При обновлении главной страницы в нижней части экрана должна появиться панель отладки:

Первое, на что вы, скорее всего, обратите внимание — надпись 404 на красном фоне. Помните, это просто страница-заглушка, поскольку мы ещё не определили домашнюю страницу. И даже если эта страница достаточно хорошо выглядит, она всё ещё остаётся страницей ошибки. Так что правильный код статуса HTTP для этой страницы — 404, а не 200. Благодаря панели отладки, вы сразу же получите всю необходимую информацию.

Нажмите на маленький восклицательный знак и вы увидите сообщение «настоящего» исключения в логах профилировщика Symfony. Если вы хотите увидеть трассировку стека, нажмите на ссылку «Exception» в левом меню.

Когда возникает проблема с кодом, вы увидите похожую страницу об ошибке со всей необходимой информацией для отладки:

Уделите немного времени и поизучайте данные в профилировщике Symfony, нажимая по разным ссылкам.

Логи весьма полезны при отладке. В Symfony есть удобная команда для отображения последних строк всех логов (веб-сервера, PHP и вашего приложения):

1
$ symfony server:log

Проведем небольшой эксперимент. Откройте public/index.php и сделайте ошибку в PHP-коде (например, добавьте foobar посередине кода). Обновите страницу в браузере и понаблюдайте за логом:

1
2
Dec 21 10:04:59 |DEBUG| PHP    PHP Parse error:  syntax error, unexpected 'use' (T_USE) in public/index.php on line 5 path="/usr/bin/php7.42" php="7.42.0"
Dec 21 10:04:59 |ERROR| SERVER GET  (500) / ip="127.0.0.1"

Логи отображаются разными цветами, чтобы привлечь ваше внимание к ошибкам.

Symfony-функция dump() — ещё один замечательный помощник во время отладки. Она глобально доступна и отображает значение переменных в удобном интерактивном формате.

Временно измените файл public/index.php, чтобы вывести объект Request:

patch_file
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
--- a/public/index.php
+++ b/public/index.php
@@ -23,5 +23,8 @@ if ($trustedHosts = $_SERVER['TRUSTED_HOSTS'] ?? $_ENV['TRUSTED_HOSTS'] ?? false
 $kernel = new Kernel($_SERVER['APP_ENV'], (bool) $_SERVER['APP_DEBUG']);
 $request = Request::createFromGlobals();
 $response = $kernel->handle($request);
+
+dump($request);
+
 $response->send();
 $kernel->terminate($request, $response);

После обновления страницы обратите внимание на новую иконку с мишенью. Она позволит вам посмотреть детали объекта. Щёлкните по ней, чтобы перейти на отдельную страницу с полной информацией об объекте:

Отмените это изменение кода перед коммитом других изменений, которые были сделаны на этом шаге:

1
$ git checkout public/index.php

Настройка среды разработки

В локальном окружении разработки при генерации исключения Symfony отображает страницу с сообщением исключения и его трассировкой. К отображаемому пути файла в трассировке добавляется ссылка, кликнув на которую можно открыть файл на нужной строке прямо в вашей IDE. Но чтобы воспользоваться этой возможностью, сначала вам нужно настроить IDE. Symfony поддерживает множество разных IDE; я использую Visual Studio Code для данного проекта:

patch_file
1
2
3
4
5
6
7
8
--- a/config/packages/framework.yaml
+++ b/config/packages/framework.yaml
@@ -14,3 +14,5 @@ framework:
     #fragments: true
     php_errors:
         log: true
+
+    ide: vscode

Ссылка в имени файла появляется не только при генерации исключения. Так, например, контроллер на панели отладки может стать кликабельным, если настроить IDE.

Отладка в продакшене

Отладка на продакшен-серверах всегда сложнее. К примеру, в таком случае у вас нет доступа к профилировщику Symfony. А в логах не так много подробной информации. Но всё же можно посмотреть последние записи логов:

1
$ symfony logs

Вы даже можете подключиться через SSH из веб-контейнера:

1
$ symfony ssh

Не бойтесь — вы не сможете так просто всё сломать. Большая часть файловой системы доступна только для чтения. Поэтому сделать срочное исправление прямо на продакшене не получится. Однако вы узнаете про гораздо более подходящий способ сделать это позже в книге.


  • « Previous Шаг 4: Выбор методологии разработки
  • Next » Шаг 6: Создание контроллера

This work, including the code samples, is licensed under a Creative Commons BY-NC-SA 4.0 license.