SfPot Lille 07/2015 - Utiliser Symfony sur des environnements Heroku-like
Télécharger en tant que ODP, PDF0 j'aime1,140 vues
Le document traite de l'utilisation de Symfony sur des environnements similaires à Heroku pour gérer un site de vente en ligne. Il décrit les défis rencontrés par une entrepreneuse lors des soldes, notamment la surcharge du serveur, et propose des solutions basées sur la méthodologie des 'twelve-factor app' pour adapter l'infrastructure au trafic. Les recommandations incluent l'utilisation de services externalisés, la gestion de la configuration via l'environnement, et des pratiques de déploiement efficaces.
SfPot Lille 07/2015 - Utiliser Symfony sur des environnements Heroku-like
- 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
- 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
- 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
- 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