Чеклист: готов ли ваш symfony проект к развертыванию (часть 3)

По мотивам 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>

Это решение позволит ускорить процесс маршрутизации, но сделает представление ссылок в коде менее читабельным.