Установка и настройка Symfony2

С момента выхода Symfony 2.0 процесс инсталляции и нужные для этого инструменты менялись и улучшались несколько раз. В данной статье мы рассмотрим, что нужно сделать для того, чтобы установить и настроить Symfony2-приложение.

Актуальным инструментом для создания нового Symfony-приложения на данный момент является одноименная консольная утилита. В Linux или Mac OS X ее можно установить из консоли:

$ sudo curl -LsS http://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

Список небольшой, вот доступные команды:

  • about
  • demo
  • help
  • list
  • new
  • self-update
  • selfupdate

Команда 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

Далее откройте в браузере страницу по адресу http://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.

По умолчанию веб-сервер запускает выбранное приложение по адресу http://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, то вам нужно будет самостоятельно настроить виртуальные хосты для локальной разработки. Примите во внимание, что встроенный веб-сервер применяется только для разработки и использовать его в продакшен-режиме не рекомендуется.

Конфигурация

Фреймворк предоставляет визуальный тестер конфигурации, доступный по адресу http://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. И вот результат.

Проверка с помощью 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. Рекомендует каждому экшену (роуту) в контроллере с помощью аннотаций всегда указывать методы, которые должны поддерживаться. Ну и не забудьте поменять стандартную фавиконку.

Вот такие рекомендации дает нам робот. Некоторые из них спорные, но если они есть, значит кто-то эти правила вносил в базу. В любому случае, знать о них не помешает.

Об авторе

Back-end разработчик
Артем работает с PHP с 2010 года и участвовал в разработке MeinFernbus. На ты с фреймворком Symfony2 и 3. Вносит вклад в развитие open source.

Похожие статьи

Вернуться к списку записей К списку записей