Symfony2 deployment checklist

Symfony2 е гъвкав и мощен фреймуорк ... което води до дълго време за изпълнение. Разбира се, prod средата е много по-обърза от обичайната dev, но това не е достатъчно.

За да ускорите вашето приложение в production режим, силно се препоръчва да инсталирате PHP Акселератор, например APC.

На нает сървър

На линукс

За да инсталирате APC на debian-подобна дистрибуция, просто изпълнете:

apt-get install php-apc

Подберете командата според вашата дистрибуция.

На Windows

Махнете коментара на съответния ред в php.ini:

extension=php_apc.dll

Във всички случаи

След инсталацията, разширението трябва да бъде активирано. Това става, като добавите в края на вашия php.ini:

[APC]
apc.enabled=1

На споделен хостинг

Ако сте на споделен хостинг, обикновено нямате достъп по SSH. В този случай най-добре е да се свържете с администратора. Кажете му, че е в тяхна полза да имат инсталиран PHP Акселератор.

Уверете се, че вашият production сървър има персонален таен ключ. Проверете го в app/config/parameters.yml файла:

secret:  please_use_a_real_secret_here

Тайният ключ по подразбиране не е напълно таен, така че трябва да го смените с някакъв генериран по случаен начин.

Преди да започнете вашето приложение, първо трябва да проверите дали вашият production сървър изпълнява изискванията му.

Проверката може да бъде направена по един от следните три начина:

  1. Ръчно изпълнете php app/check.php и вижте какво трябва да се оправи;
  2. Заредете в браузъра config.php, разположен в папка web;
  3. Ако все още нямате достъп до вашия сървър (планирате да го закупите), можете да погледнете страницата в документацията

Вие не искате логото на Symfony да се появява в браузъра на посетителите. Затова, преди да стартирате официално, трябва да замените иконата иконата по подразбиране с ваша.

Просто подменете файла web/favicon.ico.

За да направите икона, можете да:

  • Използвате онлайн инструменти като favicon.cc, който ще генерира .ico файла;
  • Използвате PNG икона. В този случай в html файла трябва да дефинирате връзка: <link rel="icon" type="image/png" href="yourFavIcon.png">

Компонентът, генериращ логове на приложението ви, е от важно значение за управление на уеб платформата ви. Symfony2 работи с Monolog, който е посветен на тази задача.

Конфигурацията по подразбиране е добра за средата за разработване, но не достатъчно за продуктовата среда. Промените целят две неща:

  • Изпращане на грешките администратора на сайта по имейл (логове с ниво "грешка");
  • Дневник с всички автентикации, които са с ниво "info", и не се логват по подразбиране.

Да конфигурираме Monolog във файла config_prod.yml:

monolog:
    handlers:
        main:
            type:               fingers_crossed
            action_level:       error
            handler:            grouped
        grouped:
            type:               group
            members:            [streamed, swift]
        streamed:
            type:               stream
            path:               "%kernel.logs_dir%/%kernel.environment%.log"
            level:              debug
        swift:
            type:               swift_mailer
            from_email:         FQN@foo.com
            to_email:           webmaster@company.com
            subject:            "OOps"
            level:              debug
        login:
            type:               stream
            path:               "%kernel.logs_dir%/auth.log"
            level:              info
            channels:           security

Това е!

В production среда силно се препоръчва да използвате Doctrine cache. Има два вида кеширане.

Query и Metadata Cache

  • Кеширането на заявките цели кеширане на трансформацията от DQL в SQL еквивалента. В продуктова среда заявките няма да се променят много, така че защо да не ги кеширате.
  • Metadata Cache цели кеширането на обработената информация от няколко различни източника, като YAML, XML, Annotations и т.н..

Кеширането се постига чрез настройване на няколко параметъра във вашия production конфигурационен файл config_prod.yml:

doctrine:
    orm:
        auto_mapping: true
        query_cache_driver:    apc
        metadata_cache_driver: apc

Result Cache

Резултатът от вашите куерита може да бъде кеширан с цел да не се пращат запитвания към базата данни отново и отново. Понеже това е фина настройка, тя не може да бъде направена глобално. Драйверът се настройва както преди:

doctrine:
    orm:
        auto_mapping: true
        result_cache_driver: apc

Но после във всички големи куерита изрично трябва да се укаже дали да се използва или не. Вижте Doctrine Result Cache документацията.

Уверете се, че Doctrine наистина използва вашия APC кеш

Вие конфигурирахте APC като кеширащ драйвер и това е велико. Но проблемът е, че Dependency Injection Container се генерира от интерфейс в командния ред, когато се създава кешът. И ако не нямате apc.enable_cli = 1 във вашия php.ini, тогава DIC ще използва FileCacheReader. Това не е това, което искаме.

За да проверите дали наистина използвате APC кеша, погледнете вашия app/cache/prod/appProdProjectContainer.php. Там трябва да има следното:

protected function getDoctrine_Orm_DefaultEntityManagerService()
{
    $a = $this->get('annotation_reader');
    $b = new \Doctrine\Common\Cache\ApcCache();
    $b->setNamespace('sf2orm_default_5cdc3404d84577b226d7772ca9818908');
    $c = new \Doctrine\Common\Cache\ApcCache();
    $c->setNamespace('sf2orm_default_5cdc3404d84577b226d7772ca9818908');

    // ...

    $g = new \Doctrine\ORM\Configuration();
    $g->setMetadataCacheImpl($b);
    $g->setQueryCacheImpl($c);

    // ...
}

Ако не откриете \Doctrine\Common\Cache\ApcCache, значи не използвате APC.

По подразбиране Composer генерира autoloader, който не е напълно оптимизиран. Наистина, ако имате много класове, autoloader-ът може да отнеме съществено време.

В production среда, autoloader трябва да бъде бърз. Composer може да генерира оптимизиран файл, който конвертира PSR-0 пакетите в такива, classmap, което подобрява изпълнението.

За да използвате оптимизирания autoloader, към Composer командата просто добавете опцията --optimize с dump-autoload:

php composer.phar dump-autoload --optimize

Разбира се, удължава размера на командата. Затова не е направена по подразбиране.

Компонентът за форми на Symfony2 автоматично добавя и валидира CSRF токени.

Уверете се, че сте персонализирали тайния си ключ, който се използва в токен генератора, във вашия app/config/parameters.yml файл:

secret:  please_use_a_real_secret_here

Освен това, можете да персонализирате токените форма по форма, което е още по-добре. Това става като дефинирате опцията intention във формите си:

namespace Acme\DemoBundle\Form;

use Symfony\Component\OptionsResolver\OptionsResolverInterface;

class TaskType extends AbstractType
{
    // ...

    public function setDefaultOptions(OptionsResolverInterface $resolver)
    {
        $resolver->setDefaults(array(
            // a unique key to help generate the secret token
            'intention'  => 'task_form',
        ));
    }

    // ...
}

Ако вече сте свикнали на страниците за грешки в "dev" средата, надяваме се не желаете това да виждат и бъдещите потребители. За целта трябва да промените различните страници за грешки, за да бъдат идентични с изгледа на сайта.

За щастие промяната наистина е лесна. Техните view-та са разположени в TwigBundle бъндъла, което ви дава насока как да ги припокриете с вашите. View-тата, които трябва да създадете са: Exception/errorXXX.html.twig, къдет XXX е номерът на грешката. Силно препоръчваме да промените поне грешки 404 и 500.

За да използвате вашите view-та има две възможни решения:

  1. Можете да създадете нов бъндъл, който разширява TwigBundle и да сложите в вашите view-та в папката Resources/views/Exception/errorXXX.html.twig. Това ще ви позволи да ги използвате и в други проекти, понеже това е reusable бъндъл;
  2. Ако view-тата ви са специфични за конкретния проект, можете просто да ги сложите в папката app/Resources/TwigBundle/views/Exception/errorXXX.html.twig, за да избегнете създаването на нов бъндъл специално за целта.