12 Factor Apps using Laravel and PHP

This is a talk I did for the Cape Town Laravel meetup group.

Transcript

1. 12 Factor Apps for scalability and DevOps bliss thanks Adam Wiggins and Heroku
2. Barry working at io as: developer (not so much anymore) devops (until I find someone else) and general manager of general things
3. Why these 12 Factors? Declarative formats for short setup time Maximum portability between environments Minimise divergence to enable continuous deployments and... We can *SCALE* significantly
4. 1 Codebase
5. One Repo == One App always a one to one correlation between the codebase and the app
6. One repo has many deploys this is a running instance of the app
7. Always use Revision Control git: github.com || bitbucket.com others are mercurial, subversion
8. Typically got deploys for production, staging, development app versions may differ
9. Many apps == a distributed system So then too if you have more than one repo you have more than one app
10. But I need to share code ? Boris, you’re my brother. So think like it! Get somebody else to manage your code dependencies !
11. 2 Dependencies
12. Must be specifically declared composer.json
13. Dependancy Declaration PHP node.js Ruby PERL Python C Composer npm Gems CPAN PIP Autoconf
14. Must be Isolated No system wide dependencies allowed Called “vendoring” or “bundling”
15. Dependancy Isolation node.js Ruby PERL Python C PHP nodeenv bundle exec pl env / Carton Virtualenv Static Linking ?
16. Dependency isolation in PHP / Laravel I’m not aware of any workable standard here https://github.com/phpenv/phpenv (only apache - not 12 factor) https://github.com/virtphp/virtphp (only php-cli - not 12 factor)
17. 3 Config
18. Strict separation from code Config varies across deploys, code does not
19. Config Examples Credentials to cloud services such as file storage or mail delivery Resource handles to backing services like your database, caching server or message queue Specific per deploy information such as canonical names
20. Configs are not stored in config files But what about /app/config ?
21. Use Environment Variables Easy to change across deploys with no code change They are language and OS agnostic
22. PHP: Use getenv()
23. ! Laravel: /bootstrap/start.php
24. Laravel: /app/config/database.php
25. Set env vars using deploy tools Set the var in bash for display purposes: export DB_URL=postgres://user:pass@io.co.za:5432/db Some common container tools: heroku config:add DB_URL=$DB_URL deis config:set DB_URL=$DB_URL docker run -e DB_URL=$DB_URL
26. 4 Backing Services
27. All must be treated as attached resources No distinction between local or 3rd party resources
28. Services such as: Datastores: mysql, orchestrate.io, mongodb, hadoop, cloudant, mantis Messaging/Queueing: RabbitMQ, Beanstalkd, IronMQ Binary Assets: CloudFiles, S3 SMTP: Postmark, Mailgun, Mandril Caching: Memcached, IronCache
29. Changing resource must be as simple as config Config using factor 3 that is
30. 5 Build, Release, Run
31. Strict separation between the 3 stages Cannot make changes to the code at runtime
32. Build Stage Converts the code repo into an executable bundle called a build Fetches and vendors dependencies - composer Compiles binaries and assets - artisan commands or gulp/grunt
33. Release Stage Combines the build and the config The resulting release is then ready for execution
34. Run Stage Runs the app in the execution environment for PHP in 12 factor it would use PHP-FPM
35. Should be able to roll back Releases have unique IDs They are immutable - if you want to change you need a new release Release Management
36. Builds happen with new code Process is complex and developer driven in case of any issues
37. Runtime is automated When a server crashes or is rebooted and might happen in the middle of the night Keep this stage simple!
38. 6 Processes
39. Processes are stateless They share nothing!
40. No sharing of ... Memory - NO Local sessions data Disk - User Uploaded Data
41. Use Factor 4 Store and ‘share’ using backing services
42. User content in cloud storage S3, CloudFiles, etc Public files should go onto a CDN
43. Laravel 5 native support for cloud file systems Laravel 4: https://github. com/thephpleague/flysystem
44. Sessions or not Save in attached storage or use JSON auth tokens instead Laravel has built in support for sessions in attached storage
45. Memory or disk may be used briefly Apps may be rebuilt or re-started at whim So even single process apps are not to share
46. Asset compilation that uses file system caches ? Done at build time - not run time
47. 7 Port Binding
48. No web server injection The app binds directly to a port
49. For PHP things are a bit different built in `php artisan serve` is meant for development only
50. PHP-FPM This *is* the language runtime We do need 2 though: PHP-CLI for composer and artisan commands You will also need nginx in front of it
51. Needs a routing layer Route public facing hostname to apps Deployment platform should handle this In dokuu for instance nginx is setup as the router
52. Not for http only Apps become backing services for apps
53. 8 Concurrency
54. Scale out via the process model Processes are a first class citizen
55. PHP-FPM is our process Its default setup will violate this factor
56. Never Daemonize, No PID Rely on the OS process manager (upstart or systemd) to manage output streams, crashes and user initiated shutdowns
57. Processes may handle their own internal multiplexing they may be threaded, they may have async event loops
58. 9 Disposability
59. Processes are disposable they may be started and stopped at a moment’s notice
60. Why ? Elastic Scaling Rapid code deployment, config changes Maximum robustness in production
61. Minimise Startup Time Quicker releases, quicker scaling
62. Shutdown gracefully Done when process receives SIGTERM Cease listening on port, allow current requests to finish
63. PHP-FPM yes, all is taken care of already thanks
64. 10 Dev/prod parity
65. Keep all environments as similar as possible Development, Staging, Production
66. So many gaps Time, People and Tooling
67. The time gap Continuous Deployment turns weeks into hours
68. The personnel gap Give devs the power to deploy
69. The tools gap Using tools like Vagrant / docker you now have the exact same invironments
70. Use Adapters Database: Eloquent / PDO Queue: Laravel Drivers / 3rd party Cache: Laravel Drivers / 3rd party
71. Porting Backing Services Painless You *still* have to use the same backing services in all environments
72. But I tested it locally Too much friction on continuous deployment
73. Homestead This is a pre-packaged vagrant box with all you need to start development Quick to get going but is most probably *not* the same as your staging / production environments
74. 11 Logs
75. Treat logs as event streams Stream of aggregated, time-ordered events from all processes and backing services
76. No concern in routing or storage of output stream Write unbuffered stream to `stdout` The execution environment takes care of routing, collation and storage
77. Laravel Logging built on the Monolog lib by default: /app/storage/log/laravel.log
78. Some open source log routers https://github.com/fluent/fluentd https://github.com/heroku/logplex http://www.elasticsearch. org/overview/logstash/
79. 12 Admin processes
80. Run as one-off processes They must run in an identical environment as the long running processes
81. Same release, codebase and config ship admin code with app code to avoid issues
82. Laravel - Use artisan `php artisan list` for built in commands You may also build custom
83. Thanks Any questions ?