Symfony2 deployment checklist

Symfony2 jest elastycznym i potężnym frameworkim ... przez co do najszybszych nie należy. Oczywiście środowisko produkcyjne jest dużo bardziej szybsze niż developerskie, ale czasami to nie wystarcza.

Aby przyspieszyć wersję produkcyjną aplikacji , jest bardzo zalecane ay zainstalować akcelerator PHP , taki jak np. APC

Na serwerze Dedykowanym (lub VPS )

Na Linuxie

Aby zainstalować APC na dystrybucji Debian , wykonaj polecenie:

apt-get install php-apc

Dla innych dystrybucji to polecenie może być inne

Na Window

Odkomentuj następującą linie w pliku konfiguracyjnym PHP t.j. php.ini:

extension=php_apc.dll

We wszystkich przypadkach

Po instalacji, należy jeszcze uruchomić zainstalowane rozszerzenie. Na końcu pliku php.ini dodaj :

[APC]
apc.enabled=1

Na współdzielonym hostingu

W większości przypadków na współdzielonym hostingu nie ma dostepu do SSH. W związku z czym z prośbą o instalację APC należy zwrócić się do administratora.

Upewnij się iż aplikacja na serwerze produkcyjnym używa innego niż domyślnego klucza Sprawdź w pliku app/config/parameters.yml :

secret:  please_use_a_real_secret_here

Domyślne hasło nie jest bezpieczne, koniecznie zmień je na losowo wygenerowane

Przed uruchomieniem aplikacji, należy sprawdzić czy serwer jest przygotowany do uruchomienia twojej aplikacji.

Przetestować serwer można na jeden ze 3 sposobów:

  1. Ręcznie uruchom polecenie php app/check.php i zobacz czy są problemy które trzeba rozwiązać;
  2. Wywołaj w przeglądarce internetowej plik config.phpznajdujący się w katalogu web .
  3. Jezeli nie masz jeszcze dostępu do serwera (np. dopiero planujesz go kupić), zawsze możesz sprawdzić wymagania w oficjalnej dokumentacji documentation reference page

Nie chcesz aby logo Symfony pojawiało się w przeglądarce odwiedzających. Dlatego właśnie należy zmienić domyślną favikonę na własną, przed uruchomieniem aplikacji.

Wystarczy zamienić plik web/favicon.ico.

Nową favikonę może uzyskać za pomocą:

  • Narzędzi online takich jak favicon.cc dzięki którym wygenerujesz plik .ico;
  • Urzyckia ikony PNG. W takim przypadku muszi zdefiniować odnośnik w HTML: <link rel="icon" type="image/png" href="TwojaFavIcona.png">

Komponent aplikacji generuący logi (dzienniki zdarzeń) jest jednym z głownych funkcji pozwalających utrzymać twoja aplikację. W przypadku Symfony 2 tym komponentem jest Monolog.

Domyślna konfiguracja jest poprawna dla środowiska developerskiego,ale jest niewystarczająca dla produkcyjnego. Aby to zmienić należy zrobić dwie rzeczy:

  • Przesłanie blędów na e-mail administratora (logi z poziomem błędu "error" );
  • Zapisywanie wszystkich uwierzytelnień - normalnie uwierzytelnienie ma poziom błędu "info" , i nie jest domyślnie zapisywane.

Poprawna konfiguracja Monologa powinna znajdować się w pliku config_prod.yml i wyglądać mniej-więcej tak:

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

I to wszystko!

W środowisku produkcyjnym jest wysoce polecane użycie Doctrine cache. Do dyspozycji są dwa typy cache.

Cache Zapytań i metadanych

  • Cache zapytań służy zapisywaniu w pamięci podręcznej transformacji zapytań DQL na odpowiadające im zapytania SQL.
  • Cache metadanych służy zapisywaniu w pamięci podręcznej zparsowanych metadanych z kilku rożnych źródeł, takich jak YAML, XML, Annotacje, itp.

Cacheowanie tych informacji należy uruchomić poprzez zmianę paru parametrów w produkcyjnym pliku konfiguracyjnym config_prod.yml:

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

Cache Wyników

Wyniki zapytań mogą być zapisywane w pamięci podręcznej, po to aby nie odpytywać ciągle bazy danych . Opcji tej nie można uruchomić w całej aplikacji. W obrębie całej aplikacji,podobnie jak w poprzednim przykładzie, ustawiamy tylko konfigurację :

doctrine:
    orm:
        auto_mapping: true
        result_cache_driver: apc

Natomiast sam decydujesz w którym miejscu aplikacji używasz cacheowania wyników zapytań, użycie tego typu pamięci podręcznej odbywa się poprzez zdefiniowanie nazwy i długości życia dla każdego zapytania które chcesz cacheować. Zobacz Doctrine Result Cache documentation.

Upewnij się że Doctrine używa APC

Sama konfiguracja w config_prod jest prosta,ale czasami niewystarczająca . Problemem jest fakt iż kontener Dependency Injection jest generowany za pomocą linii poleceń . Jeżeli nie masz ustawione apc.enable_cli = 1 w pliku php.ini, wtedy kontener DI użyje FileCacheReader Zamiast APC .

Aby sprawdzić czy twoja aplikacja rzeczywiście używa APC, zobacz na app/cache/prod/appProdProjectContainer.php. Powinieneś zobaczyć :

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);

    // ...
}

Jeśli nie możesz tam znaleźć \Doctrine\Common\Cache\ApcCache, oznacza to że APC nie jest używane.

Domyślnie Composer zrzuca(tworzy) autoloadera który nie jest w pełni zoptymalizowany. W przypadku gdy używasz większej ilości klas, może to rzutować negatywnie na wydajność...

W środowisku produkcyjnym zależny nam jednak na możliwie zoptymalizowanym autoloaderze. Composer może zrzucić zoptymalizowany autoloader który konwertuje paczki PSR-0 w "mapę klas" - co korzystnie wpływa na wydajność.

Aby użyć zoptymalizowanego autoloader użyj opcji --optimize na dump-autoload . Polecenie Composera :

php composer.phar dump-autoload --optimize

Oczywiście polecenie to wykonuje się dłużej niż normalnie. Dlatego też nie jest domyślnie wykonywane.

Symfony2 Form Component automatycznie załącza i sprawdza tokeny CSRF .

Upewnij się iż zmieniłeś domyślny klucz, który jest używany przy tworzeniu tokenów.Znajduje się on w pliku app/config/parameters.yml :

secret:  please_use_a_real_secret_here

Standardowe strony błędów wyświetlane w środowisku developerskim nie są, na szczęście, wyświetlane w środowisku produkcyjnym. Dlatego też należy stworzyć swoje własne strony błędów - dostosowane do wyglądu aplikacji .

Stworzenie własnych stron błędów jest bardzo proste. Widoki stron błędów znajdują się w paczce TwigBundle, co daje bezpośrednia możliwość zastąpienia ich swoimi. Widoki powinny się znajdować : Exception/errorXXX.html.twig, gdzie XXX to numer błędu. Zaleca się przede wszystkim zmodyfikować/zastąpić widoki dla błędów 404 (nie znaleziono) i 500 (błąd serwera).

Użyć własnych widoków błędu można na dwa sposoby:

  1. Stworzyć nową paczkę która rozszerza TwigBundle, i umieścić widoki w Resources/views/Exception/errorXXX.html.twig. Takie rozwiązanie umożliwia wielokrotne użycie tych samych widoków w wielu projektach ( poprzez użycie tej paczki w projektach) .;
  2. Możesz po prostu umieścić widoki w app/Resources/TwigBundle/views/Exception/errorXXX.html.twig. To rozwiązanie pozwala używać widoki błędu dostosowane do konkretnego projektu, bez tworzenia nowej paczki(bundla) .