По мотивам Check if your symfony application is ready for deployment
Небольшой сборник рецептов (или же мини тестов), которые желательно выполнять перед развертыванием symfony-проектов. Часть 3-я.
Удалите .htaccess, везде где это возможно
Файлы .htaccess как правило очень удобны – гибкие, работают везде, изменения можно протестировать тут же. Но обратная сторона медали в том, что правила из .htaccess не могут быть закешированы на уровне apache, сервер вынужден сканировать файловую систему проекта (docroot) для каждогозапроса.
Если вы переместите правила из .htaccess в конфигурацию виртуального хоста в httpd.conf (или подлинкованном к нему файле с виртуальными хостами), эти правила будут кэшироваться apache, что увеличит производительность.
К сожалению, не всегда имеется доступ к конфигурации apache. В частности, на виртуальном shared-хостинге, вот почему symfony по умолчанию использует .htaccess файл по-умолчанию.
Так что, извините, этот совет можно применить только на dedicated сервере (VPS/VDS тоже в доле).
Итак, откройте ваш конфиг с виртуальными хостами:
Часто, конфигурации виртуальных хостов помещают в конце httpd.conf (или делают Include отдельного файла, например vhosts.conf или conf.d/vhosts.conf).
Ваш виртуальный хост может выглядеть примерно так:
<VirtualHost *:80>
ServerName my-symfony-project.com
DirectoryIndex index.php
DocumentRoot "/path-to-your-sf-project/web"
<Directory "/path-to-your-sf-project/web">
AllowOverride All
Allow from All
</Directory>
Alias /sf /path-to-your-sf-project/lib/vendor/symfony/data/web/sf/
<Directory "/path-to-your-sf-project/lib/vendor/symfony/data/web/sf/">
AllowOverride All
Allow from All
</Directory>
</VirtualHost>
Вам нужно добавить ваши правила в секцию <Directory “/path-to-your-sf-project/web”>
<Directory "/path-to-your-sf-project/web">
AllowOverride None
Allow from All
Options FollowSymLinks ExecCGI
RewriteEngine On
# uncomment the following line, if you are having trouble
# getting no_script_name to work
#RewriteBase /
# we skip all files with .something
#RewriteCond %{REQUEST_URI} ..+$
#RewriteCond %{REQUEST_URI} !.html$
#RewriteRule .* - [L]
# we check if the .html version is here (caching)
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
# no, so we redirect to our front web controller
RewriteRule ^(.*)$ index.php [QSA,L]
</Directory>
Сохраните конфиг и удалите ваш .htaccess файл – если вы не модифицировали этот файл под ваши нужны, он теперь не нужен.
Тестирование изменений и рестарт apache
Apache имеет встроенный инструмент тестирования конфигурации на предмет синтаксических ошибок: configtest.
На большинстве linux-серверов вы можете запустить утилиту управления apache следующим образом:
/etc/init.d/apachectl configtest или /etc/init.d/httpd configtest
Документируйте!
Ваш проект должен иметь как минимум один README файл, где вы можете описать особенности настройки проекта и вебсервера.
Этот совет был предложен Jérôme Macias тут http://forum.symfony-project.org/index.php/m/81968/#msg_81968
Логгирование ошибок
Логгирование ошибок – это точнейший инструмент, который позволит вам понять, что и где пошло не так на продуктовом сервере.
В apps/frontend/config/settings.yml активируйте опцию:
prod:
.settings:
logging_enabled: true
Потом, в apps/frontend/config/factories.yml внесите следующий изменения:
prod:
logger:
class: sfAggregateLogger
param:
level: err
loggers:
sf_file_debug:
class: sfFileLogger
param:
level: err
file: %SF_LOG_DIR%/%SF_APP%_%SF_ENVIRONMENT%.log
И очистите кэш:
php symfony cc
Не забудьте настроить cron-job для логгирования логов (можете посмотреть в сторону logrotate). Документация по логгированию: http://www.symfony-project.org/jobeet/1_4/Doctrine/en/22#chapter_22_sub_logging.
Правка deployment списков
Скрипты для тестового окружения в продуктовую среду попасть не должны!
Для того чтобы на продуктовый сервер попали только продуктовые скрипты, symfony предоставляется два инструмента для этого:
- команду
php symfony project:clear-controllers - файл
myproject/config/rsync_exclude.txt
rsync_exclude.txt по-умолчанию фильтрует скрипты, относящиеся к dev-окружению. Но вы также можете добавить свои исключения:
/web/*_cache.php /web/*_test.php
Также можете добавить такие некритичные файлы:
Thumbs.db .DS_Store
Не забудьте также защитить продуктовую БД
Вы также можете добавить следующие файлы в rsync_exclude.txt:
/config/databases.yml /data/sql/schema.sql
Escaping для шаблонов
Бесполезно для проектов на symfony 1.3/1.4
По-умолчанию, output escaping отключен. В файле /apps/frontend/config/settings.yml добавьте:
all:
.settings:
# Output escaping settings
escaping_strategy: true
escaping_method: ESC_SPECIALCHARS
Защита форм
Бесполезно для проектов на symfony 1.3/1.4
symfony имеет возможность защищать каждую форму в приложении от CSRF атак. Для того чтобы подключить эту возможность, вы должны указать csrf ключ в apps/frontend/config/settings.yml
all:
.settings:
csrf_secret: chooseYouOwnSecretKey
Эта функция будет внедрять в каждую форму токен, уникальный для каждого пользователя и каждой формы. Но будьте осторожны, формы с протекцией больше нельзя кэшировать.
Отображайте сообщение “Сайт недоступен” на время работ
Чем больше ваш сайт, тем медленне работают некоторые таски symfony. В некоторых случаях, эти операции могут значительно замедлить ваше приложение и помешать нормально работе пользователей.
Отображать некую страницу, которая будет предупреждать пользователя о ведущихся на сайте работах, это наилучший выход в данной ситуации.
Для того чтобы настроить перенаправление пользователей на страницу unavailable.php, в то время когда вы выполняете так типа php symfony cc, внесите изменения в apps/frontend/config/settings.yml:
all:
.settings:
check_lock: true
Оптимизация маршрутизации
Система маршрутизации symfony – это одна из убийственных фич этого каркаса.
<p>Please have a look on <php echo link_to('our products', 'product/index') ?>.</p>
Укажите в вашем шаблоне, какие модуль/действие вам нужны и предоставьте маршрутизатору сделать все остальное.
Вы можете использовать правило по-умолчанию:
default: url: /:module/:action/*
Или добавить свое собственное
product_list:
url: /our-products
param: { module: product, action: index }
Очистите кэш и все соответствующие ссылки и URI будут изменены.
Выглядит как магия, но маршрутизация имеет свою цену.
Каждый раз, когда при обработке запроса в шаблоне встречается product/index, symfony сканирует все правила, определенные в routing.yml и определяет, какое из них будет обрабатывать запрос: правило по умолчанию? или какое-то другое?
Этот процесс повторяется для каждой ссылки…
Если у вас много страниц и много правил маршрутизации, вы можете увеличить производительность вашего приложения, используя метки маршрутов, вместо пары module/action:
<p>Please have a look on <php echo link_to('our products', '@product_list') ?>.</p>
Это решение позволит ускорить процесс маршрутизации, но сделает представление ссылок в коде менее читабельным.