Установка и настройка Symfony2
С момента выхода Symfony 2.0 процесс инсталляции и нужные для этого инструменты менялись и улучшались несколько раз. В данной статье мы рассмотрим, что нужно сделать для того, чтобы установить и настроить Symfony2-приложение.
Актуальным инструментом для создания нового Symfony-приложения на данный момент является одноименная консольная утилита. В Linux или Mac OS X ее можно установить из консоли:
$ sudo curl -LsS https://symfony.com/installer -o /usr/local/bin/symfony $ sudo chmod a+x /usr/local/bin/symfony
Единственное условие для работы этой утилиты — у вас должен быть PHP версии 5.4 и выше. Если вы все еще пользуетесь PHP 5.3, то в статье также будет показан и второй вариант установки.
Консольная утилита symfony имеет несколько доступных команд для выполнения. Чтобы просмотреть список доступных команд, запустите:
$ symfony list
Список небольшой, вот доступные команды:
aboutdemohelplistnewself-updateselfupdate
Команда symfony about показывает информацию о текущей версии инсталлера, кстати, эту же информацию можно посмотреть, запустив утилиту symfony без каких-либо параметров. Инсталлер Symfony регулярно дописывается, выходят его новые версии. Установив его один раз глобально, в дальнейшем вы можете его обновлять одной из команд self-update или selfupdate (аналогично с Composer).
$ symfony self-update $ symfony selfupdate
Рекомендую периодически обновляться либо же делать обновление непосредственно перед использование консольной команды. Если вам нужно больше информации по какой-либо консольной команде, то используйте команду help или опцию --help.
$ symfony help demo $ symfony demo --help
Symfony предоставляет возможность очень легко поднять и запустить демо-приложение (тут, опять же, будет нужна версия PHP от 5.4). Для этого выполните следующие команды:
$ symfony demo new_directory_name $ cd new_directory_name/ $ app/console server:run
Далее откройте в браузере страницу по адресу https://localhost:8000. Вам доступен элементарный блог с фронт- и бекенд-частью. Также сразу включен и доступен Symfony Debug Toolbar внизу страницы. Ну и конечно же, есть готовый пример кода, который можно изучить и использовать.
Установка Symfony2 с помощью стандартного установщика
Для создания нового приложения используется команда new. Ее синтаксис:
$ symfony new directory_name [version]
Название директории обязательно, версия — опциональна. Вот пример возможных вариантов запуска команды:
# создать проект на основе последней актуальной стабильной версии $ symfony new my_project_name # можно указать версию, тогда подтянется последний стабильный релиз данной версии $ symfony new my_project_name 2.3 $ symfony new my_project_name 2.5 $ symfony new my_project_name 2.6 # можно указать конкретную версию $ symfony new my_project_name 2.3.26 $ symfony new my_project_name 2.6.5 # можно указать последнюю LTS версию, на данный момент это 2.7 $ symfony new my_project_name lts
Теперь нужно открыть файл my_project_name/app/config/parameters.yml и внести необходимые изменения в параметры приложения.
Создание приложения без установщика Symfony
До появления установщика Symfony рекомендованным вариантом создания нового приложения было создание проекта через Composer. При желании можете пользоваться этим вариантом, но если у вас PHP 5.3, то, к сожалению, вы только им и сможете пользоваться. Для начала установите Composer глобально. Создание Symfony-приложения последней стабильной версии делается так:
$ composer create-project symfony/framework-standard-edition my_project_name
Или, если нужно указать конкретную версию:
$ composer create-project symfony/framework-standard-edition my_project_name "2.7.*"
Минус этого способа в том, что он не воспринимает «lts» в качестве версии, нужно указывать только цифрами.
После выполнения этой команды будет закачана заготовка нового проекта и все необходимые зависимости. После чего из консоли в интерактивном режиме нужно будет ввести параметры переменных для файла parameters.yml
Встроенный веб-сервер
Начиная с версии 5.4, в PHP появился встроенный веб-сервер. В принципе, его достаточно для запуска Symfony-приложения из коробки. Делается это через консоль Symfony, которая предоставляет 4 команды для работы с веб-сервером:
$ php app/console server:run $ php app/console server:start $ php app/console server:stop $ php app/console server:status
Разница между server:run и server:start, в том, что первая после выполнения будет висеть в консоли, и остановить сервер можно будет с помощью Ctrl+C. Вторая запускает веб-сервер в фоне, и для остановки нужно будет выполнить команду server:stop.
По умолчанию веб-сервер запускает выбранное приложение по адресу https://127.0.0.1:8000/
Если у вас несколько Symfony-проектов локально, то их можно запускать на разных портах:
$ app/console server:run 127.0.0.1:8000 $ app/console server:run 127.0.0.1:8001 $ app/console server:run 127.0.0.1:8002
Подробнее можно почитать об встроенном веб-сервере на сайте PHP. Если для разработки вы используете Apache или nginx, то вам нужно будет самостоятельно настроить виртуальные хосты для локальной разработки. Примите во внимание, что встроенный веб-сервер применяется только для разработки и использовать его в продакшен-режиме не рекомендуется.
Конфигурация
Фреймворк предоставляет визуальный тестер конфигурации, доступный по адресу https://localhost:8000/config.php, он проверит наличие всех необходимых опций для старта приложения, а также позволит заполнить или изменить значения конфигурации Symfony2 через веб-интерфейс. Честно говоря, я никогда не заполняю конфиги через веб-интерфейс, мне удобнее редактировать их в файле.
Проверить конфигурацию системы для использования Symfony можно также с помощью консольного скрипта:
$ php app/check.php
Он проверит наличие всех требований к системе для работы Symfony, и, если чего-то недостает, то выдаст предупреждение и подскажет, что нужно сделать. Например, может не хватать какого-то расширения PHP, обязательного для Symfony или отсутствовать необходимая опция. Консольная версия PHP может иметь отдельную от веб-версии конфигурацию. Потому, когда вносите какие-то важные изменения, делайте это и для веб-версии, и для консольной версии. Также есть команда Symfony для проверки безопасности вашего приложения:
$ app/console security:check
Она проверяет зависимости из файла composer.lock. Если у вас используется версия вендора, которая имеет известную уязвимость, то скрипт даст вам об этом знать. База небезопасных вендоров — это наработка SensioLabs, доступная по адресу https://security.sensiolabs.org/database.
Права доступа на директории
В Symfony папки app/cache и app/logs должны иметь права доступа и для веб-сервера, и для пользователя командной строки. Поэтому этим директориям нужно дать соответствующие права. Делается это одним из доступных способов.
Использование одного и того же пользователя для веб-сервера и консоли
Для этого нужно в конфигурации веб-сервера указать того же пользователя, что и для консоли. Например, для Apache это делается в файле httpd.conf (или apache2.conf).
Использование ACL в системе, которая поддерживает chmod +a
$ rm -rf app/cache/* $ rm -rf app/logs/* $ HTTPDUSER=`ps aux | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1` $ sudo chmod +a "$HTTPDUSER allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs $ sudo chmod +a "`whoami` allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
Если этот способ выдает ошибку, попробуйте следующий:
Использование ACL в системе, которая не поддерживает chmod +a
$ HTTPDUSER=`ps aux | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1` $ sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs $ sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs
Если это не сработает, попробуйте добавить опцию -n
Без использования ACL
Если ни один из предыдущих методов вам не подошел, то измените umask таким образом, чтоб директории cache и log были доступными на запись группе или всем (в зависимости от того, находятся пользователи веб-сервиса и командной строки в одной или разных группах). Для этого нужно разместить следующую строку в начале файлов app/console, web/app.php и web/app_dev.php:
umask(0002); // Выставить права 0775 // или umask(0000); // Выставить права 0777
Дистрибутивы Symfony
В примерах, описанных выше, используется сборка Symfony Standard Edition. В нее входит скелет Symfony-приложения и composer.json со всеми необходимыми зависимостями. Эта сборка наиболее популярна и лучший выбор для создания нового приложения. Кроме того, есть и другие сборки:
- Symfony CMF Standard Edition — кастомная сборка на основе Symfony CMF, предоставляет возможность легко добавлять функциональность CMS в свой проект.
- Symfony REST Edition — сборка для организации RESTful API сервера на базе Symfony и FOSRestBundle.
Symfony и ее составляющие компоненты регулярно обновляются. Обновить свой проект можно с помощью команды
$ composer update
Если вы переходите не на мажорную версию Symfony, тогда в большинстве случаев у вас не возникнет проблем с вашим кодом. Для перехода на мажорную версию (например, с 2.* на 3.0) нужно будет прочитать инструкцию. Если какой-то сторонний бандл имеет зависимость на определенную версию Symfony, то Composer выдаст вам предупреждение и не продолжит работу, пока вы не разрешите проблему.
Чтобы быть в курсе всех обновлений и изменений, читайте официальный блог Symfony.
Также инструкции по обновлению с версии на версию можно найти в репозитории, файлы UPGRADE.
Другие советы по работе над новым Symfony-приложением
Если вы разобрались с инструкциями по установке Symfony и у вас уже есть костяк вашего будущего приложения, то вам остается только наполнять его бизнес-логикой и расширять с помощью сторонних бандлов. Если вы новичок, то вам, конечно же, поможет документация по Symfony2 с официального сайта. Также много полезного есть в CookBook.
После создания заготовки нового проекта я также делаю несколько дополнительных конфигураций. Например, я правлю конфиг для PHPUnit в файле app/phpunit.xml.dist, исключаю некоторые директории и файлы, которые не будут покрываться тестами (например, классы с фикстурами), если этого не сделать, тогда они будут влиять на test coverage. Если проект размещается на GitHub как open-source, то с самого начала я подключаю его к сервисам оценки качества кода. Есть еще сервис Insight от SensioLabs, о котором я писал в той же статье. Ради эксперимента я натравил его на чистый Symfony Standard Edition, чтоб узнать что он найдет в коде Symfony из коробки. Я создал чистый проект Symfony командой:
$ symfony new test
Актуальная версия на момент написания статьи оказалась 2.7.1. После чего, не делая ни единого изменения, я отправил проект в публичный репозиторий на GitHub и сделал проверку с помощью SensioLabs Insight. И вот результат.
Проверка нашла ошибки, давайте рассмотрим их.
Первая критическая ошибка в том, что после создания нового проекта я не изменил security secret в файле app/config/parameters.yml.dist. Однозначно нужно прописывать свою секретную фразу. Но в данном конкретном примере оно бессмысленно. Вы можете всего лишь изменить значение по умолчанию, которое будет использоваться, когда кто-то будет с нуля разворачивать ваш проект. Это ведь не означает, что на продакшен-сервере будет использоваться такое же значение. Тем не менее, чтоб убрать это предупреждение, просто замените стандартную секретную фразу ThisTokenIsNotSoSecretChangeIt на что-то свое.
Symfony идет с невалидным файлом composer.json :) , потому что не хватает поля описание (description), которое является обязательным.
Не удален файл config.php, тот, который используется для проверки требований Symfony в веб-окружении и установки параметров. Insight советует его удалить из репозитория, так как он не должен попадать на продакшен.
Далее Insight советует убрать закомментированный и неиспользуемый код. Еще один совет — это изменить название переменной cookie для PHP сессии, его можно задать в файле config.yml в поле framework.session.name.
Далее идут информативные сообщения. Insight предлагает удалить все .htaccess файлы, чтоб все необходимые настройки делать в глобальных конфигах веб-сервера. Также кастомизировать страницы для ошибок 404 и 500. Рекомендует каждому экшену (роуту) в контроллере с помощью аннотаций всегда указывать методы, которые должны поддерживаться. Ну и не забудьте поменять стандартную фавиконку.
Вот такие рекомендации дает нам робот. Некоторые из них спорные, но если они есть, значит кто-то эти правила вносил в базу. В любому случае, знать о них не помешает.
