Cette présentation introduit le concept proposé par la 12factor app et aborde une mise en pratique avec Symfony2.

1. Utiliser Symfony sur des environnementsUtiliser Symfony sur des environnements
Heroku-likeHeroku-like
Utiliser Symfony sur des environnementsUtiliser Symfony sur des environnements
Heroku-likeHeroku-like

2. Remerciements

3. Il était une fois
● Madame Michu est chocolatière.
● Elle vend sur Internet ses produits.
– Site en Symfony2, respectueux des pratiques.
– Une base de données.
– Des sessions stockées sur le système de fichiers.
– Un serveur de websockets pour un service assistance.
● Codé dans une commande : php app/console support:run
● Les affaires marchent très bien !

4. Quand tout à coup, les soldes !

5. BAOUM.
● Sous la charge, le site se met à « ramer ».
– Load average : 481,42
– Impossible de reprendre la main en SSH.
– Les pages s'affichent en 45 secondes.
● C'est dramatique, Madame Michu aurait pu
gagner beaucoup d'argent !

6. Solutions
● Ne rien faire.
+ Ne coûte pas plus cher.
+ La présentation est finie.
- Perte d'argent et de notoriété lors des soldes.
● Acheter un plus gros serveur.
+ Résout le problème des soldes.
- Coûte plus cher le reste de l'année.

7. Ou alors ...
● Adapter l'infrastructure au trafic.
● Ajouter de la puissance la veille des soldes.
● Et la retirer ensuite.

8. L'objectif
But du jeu
– Passer de gauche à droite.
– Pouvoir rajouter des instances à chaud en quelques
secondes.

9. The twelve-factor app
●
Une méthodologie pour fournir une application en tant que service.
– Automatisable
– Portable
– Adaptée au cloud
– Scalable
●
Écrit par Adam Wiggins.
– Cofondateur de Heroku.
●
Disponible sur http://12factor.net

10. I. Codebase
● « One codebase tracked in revision control,
many deploys »
– Toutes les versions de l'application sont sur un seul
repository.
– C'est une pratique courante dans la communauté
Symfony.

11. II. Dependencies
● « Explicitly declare and isolate dependencies »
– Grâce à Composer, c'est déjà le cas.

12. III. Config
● « Store config in the environment »
– Séparation du code et de la configuration.
– Au déploiement, la configuration n'est plus un
souci.

13. III. Config

14. III. Config
SYMFONY_ENV=prod
SYMFONY__DATABASE_USER=myuser
SYMFONY__DATABASE_NAME=myshop

15. IV. Backing Services
● « Treat backing services as attached
resources »
– La base de donnée est une ressource.
– Attention ! Les sessions aussi !

16. IV. Backing Services
● Pour doctrine, c'est natif.
– Tout est paramétrable via le parameters.yml.
– Et donc via l'environnement.
● Centralisons nos sessions dans Redis.
● Il y a un bundle pour ça.
– https://github.com/snc/SncRedisBundle

17. IV. Backing Services
● Dépendances
– snc/redis-bundle: ~1.1
– predis/predis: ~0.8
● Configuration

18. V. Build, release, run
● « Strictly separate build and run stages »
– Build
● Composer install
● Inclure tous les binaires (apache / nginx, php / hhvm).
– Run
● Démarrer apache / nginx.

19. V. Build, release, run
● Hein ?! Packager php avec le projet ?
● Avec un buildpack, c'est facile !
● git clone https://github.com/heroku/heroku-buildpack-php
● cd heroku-buildpack-php
● ./bin/compile /path/to/the/app /tmp/cache /path/to/env
● ./bin/release /path/to/the/app
● On zippe le résultat.

20. V. Build, release, run

21. VI. Processes
● « Execute the app as one or more stateless processes »
● Stateless
– Déjà fait !
● Backing Services
● Config via environnement
● One or more ?
– Le site = un process
– Le serveur de websockets = un process

22. VI. Processes
● Utiliser un Procfile.
web: bin/heroku-php-nginx -C conf/nginx.conf web/
support: php app/console support:run

23. VII. Port binding
● « Export services via port binding »
– Base de données : 192.168.1.12:5210
– Instance « web 1 » : 192.168.1.22:6597
– Instance « web 2 » : 192.168.1.25:7851
– …
● La configuration pour relier les services.

24. VIII. Concurrency
● « Scale out via the process model »
– Notre application est stateless.
– Alors on peut en avoir 1, 10 ou 1000 sans altérer
son fonctionnement.

25. IX. Disposability
● « Maximize robustness with fast startup and
graceful shutdown »

26. X. Dev/prod parity
● « Keep development, staging, and production
as similar as possible »
– Merci docker !

27. XI. Logs
● « Treat logs as event streams »
– Beaucoup de machines.
● Un même visiteur peut passer sur plusieurs serveurs.
● Il faut centraliser.
– Les applications sont stateless.
● On n'écrit pas de log sur la machine.
● Tout est redirigé vers stdout / stderr.

28. XI. Logs
● Heureusement, Monolog est là !

29. XII. Admin processes
● « Run admin/management tasks as one-off processes »
– Comment créer la base de données ?
– Certainement pas sur une instance existante
● On démarre une nouvelle instance en mode REPL
– REPL : read–eval–print loop
– En gros : SSH
– A la fin de l'opération : l'instance est détruite

30. XII. Admin processes

31. Mais qui s'occupe de collecter les logs, de
démarrer les machines avec les bonnes variables
d'environnement, d'automatiquement exposer les
services entre eux ?

33. Démo time !
● Amusons nous avec Flynn
– https://flynn.io/
– Gratuit, open source
– Facile à utiliser en local

34. Merci pour votre attention