Symfony2 su Google App Engine

Un tranquillo weekend di team building per fare hacking su qualcosa di nuovo: Google App Engine (GAE) per PHP.
Cosa facciamo? Installiamo Symfony2!
Problemino: il filesystem che GAE mette a disposizione è in sola lettura, alcune parti di Symfony2 e librerie di terze parti si aspettano di poter scrivere sul filesystem.
Si potrebbe usare Google Cloud Storage ma non sembra la soluzione corretta per dei dati di cache.


La versione estesa

Durante il primo (si spera di una lunga serie) #ideatocountry abbiamo sfruttato l’opportunità di aver accesso a Google App Engine per PHP e abbiamo organizzato un hackday. Visto che il framework con la S maiuscola è il nostro preferito e qualcuno lo aveva già fatto con Silex abbiamo pensato di provare a fare il deploy di una applicazione Symfony 2 su GAE.

Installazione dell’sdk e di symfony in locale

L’installazione in locale non ha grandi difficoltà rispetto ad una installazione Symfony2 standard. Ci sono alcuni step in più:

  • creare nella root di progetto un file app.yaml. Questo file contiene le informazioni di configurazione per App Engine. Nel nostro caso era qualcosa di simile a questo:
  • Configurare monolog: GAE si appoggia a syslog per registrare i log. I log registrati in questo modo saranno poi visibili nel pannello di amministrazione sezione Logs. Monolog supporta syslog nativamente quindi la configurazione è molto semplice, in app/config/config_prod.yml
  • Installare l’sdk: contiene anche un webserver per fare prove in  locale invocabile in questo modo 

In locale tutto ok, possiamo fare un deploy lanciando il comando

Aghr, ci sono un pò di problemi, tutti nella zona della directory app/cache.

Symfony2 e la directory cache

Al momento Symfony non ha una gestione uniforme del caching. I componenti e le librerie che fanno uso di caching hanno come unico punto in comune il fatto di scrivere nella directory cache. In una installazione base nella directory cache troverete:

  • il dump del DIC di Symfony
  • annotation
  • assetic
  • security
  • translation
  • proxy e repository di doctrine
  • twig
  • le sessioni utente

Questo è male! Symfony2, e alcune delle librerie che usa, si aspettano di poter scrivere sul filesystem! Per aggirare questo problema abbiamo pensato a quali di questi file potessero essere pregenerati

Molti dei dati devono comunque essere generati a runtime: per avere questa possibilità e ridurre al minimo l’impatto sul codice, abbiamo pensato di utilizzare uno stream che salvasse i dati in memoria al posto che sul filesystem. Per fare una prova rapida abbiamo utilizzato vfsStream.

GAE 1 Ideatos 0 (per ora)

Abbiamo quindi registrato un nuovo stream, aggiungendo la chiamata all’inizio del file bootstrap.php.cache

modificando le chiamate getLogDir e getCacheDir della classe Kernel.php (che sono hardcoded ed ignorano i valori in parameters.yml)

e modificando la configurazione della directory cache e log in parameters.yml.

Fail Again! Purtroppo la configurazione di PHP su GAE ha diverse restrizioni, alcune della quali possono essere aggirate creando un file php.ini nella root del progetto con il settings:

il settings che ci interessa invece, allow_url_include, è disabilitato e non è possibile modificarlo.

Conclusione

Anche se l’esperimento non è andato a buon fine siamo riusciti ad imparare diverse cose, sia su GAE che su symfony:

  • GAE è ancora acerba come piattaforma e con diverse scelte particolari rispetto ad altre soluzioni: il deploy ad esempio viene gestito dall’sdk e spesso è particolarmente lento, anche nel caso venga modificato un solo file. Git anybody?
  • su GAE PHP gira in un ambiente ristretto con diverse limitazioni. Questo può rappresentare un problema o meno a seconda del tipo di applicazione che state cercando di fare girare anche se una soluzione simile, nata garantire scalabilità, dubito che ospiterà applicazioni mignon.
  • Symfony ha la fama di essere estremamente configurabile e flessibile (alcuni direbbero, pure troppo :-)). Ci sono parti in realtà ancora strettamente legate al filesystem. In corso ci sono una serie di discussioni su un componente di caching che fornisca una interfaccia uniforme per tutte quelle parti di codice che hanno necessità di fare caching

Proseguiremo i nostri esperimenti per capire se Google Cloud Storage potrà risolvere i roadblock che si sono presentati.