The 12Factor Django App

Short talk I gave at the 2012 Chicago Barcamp

Transcript

1. The 12factor Django App Cezar Jenkins Sunday, September 23, 12
2. What is 12factor The twelve-factor app is a methodology for building software- as-a-service apps that Sunday, September 23, 12
3. Use declarative formats for setup automation, to minimize time and cost for new developers joining the project. Sunday, September 23, 12
4. Have a clean contract with the underlying operating system, offering maximum portability between execution environments. Sunday, September 23, 12
5. Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration. Sunday, September 23, 12
6. Minimize divergence between development and production, enabling continuous deployment for maximum agility. Sunday, September 23, 12
7. And can scale up without significant changes to tooling, architecture, or development practices. Sunday, September 23, 12
8. I. Codebase One codebase, tracked in revision control, many deploys. Sunday, September 23, 12
9. I. Codebase What have we been doing? Sharing code between apps. Factor it out and make a library Keeping our code in rsynced tarballs Keeping a development repo and a production repo. Sunday, September 23, 12
10. II. Dependencies Your dependencies should be spelled out. Sunday, September 23, 12
11. II. Dependencies Your dependencies should be spelled out. Never rely on a system dependency. E.g. , never assume Django is on the system. Sunday, September 23, 12
12. II. Dependencies Your dependencies should be spelled out. Never rely on a system dependency. E.g. , never assume Django is on the system. Virtualenv and pip are your friend. Sunday, September 23, 12
13. III. Config Never hard code configuration Sunday, September 23, 12
14. III. Config $ ls settings.py prod-settings.py dev-settings.py local-settings.py dev ≠ staging ≠ prod Sunday, September 23, 12
15. III. Config $ cat .env DATABASE_URL=postgres://user:pass@host/db SENTRY_URL=https://user:pass@host/key S3_BUCKET=mybucket S3_KEY=mykey S3_TOKEN=mytoken Sunday, September 23, 12
16. III. Config $ cat settings.py import os MY_SETTING = os.environ.get(‘SETTING’) Dev = Staging = Production Sunday, September 23, 12
17. III. Config How do you handle .env environment variables? Sunday, September 23, 12
18. III. Config How do you handle .env environment variables? Development: Sunday, September 23, 12
19. III. Config How do you handle .env environment variables? Development: $ touch project/.env $ echo "echo 'woah'" > project/.env $ cd project woah Autoenv: Sunday, September 23, 12
20. III. Config Sunday, September 23, 12
21. III. Config Production: Sunday, September 23, 12
22. III. Config Production: Use Honcho (python Foreman) Sunday, September 23, 12
23. III. Config Production: Use Honcho (python Foreman) web: python serve.py redis: redis-server Uses a Procfile Sunday, September 23, 12
24. IV. Backing Services Services should be swappable. Sunday, September 23, 12
25. V. Build, release, run Sunday, September 23, 12
26. V. Build, release, run The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches and vendors dependencies and compiles binaries and assets. Sunday, September 23, 12
27. V. Build, release, run The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches and vendors dependencies and compiles binaries and assets. The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment. Sunday, September 23, 12
28. V. Build, release, run The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches and vendors dependencies and compiles binaries and assets. The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment. The run stage (also known as “runtime”) runs the app in the execution environment, by launching some set of the app’s processes against a selected release. Sunday, September 23, 12
29. V. Build, release, run Heroku Sunday, September 23, 12
30. V. Build, release, run Heroku Capistrano Sunday, September 23, 12
31. V. Build, release, run Heroku Fabric Capistrano Sunday, September 23, 12
32. V. Build, release, run Heroku Fabric Capistrano Mash Sunday, September 23, 12
33. VI. Processes Execute the app as one or more stateless processes $ python manage.py Sunday, September 23, 12
34. VI. Processes Execute the app as one or more stateless processes $ python manage.py Processes share nothing Sunday, September 23, 12
35. VII. Port binding Export services via port binding. Sunday, September 23, 12
36. VII. Port binding Export services via port binding. ... run_gunicorn -b 0.0.0.0:$PORT Let nginx/apache handle routing to your app. Sunday, September 23, 12
37. VIII. Concurrency Scale out your application using the process model Sunday, September 23, 12
38. VIII. Concurrency The share-nothing, horizontally partitionable nature of twelve-factor app processes means that adding more concurrency is a simple and reliable operation. Sunday, September 23, 12
39. VIII. Concurrency Twelve-factor app processes should never daemonize or write PID files. Instead, rely on the operating system’s process manager. Supervisor is very common in the Django world. Sunday, September 23, 12
40. IX. Disposability The app should start quickly and shut down gracefully. Sunday, September 23, 12
41. IX. Disposability The app should start quickly and shut down gracefully. SIGTERM causes shutdown Shutdown is handled by the process manager (supervisor) Sunday, September 23, 12
42. IX. Disposability The app should start quickly and shut down gracefully. SIGTERM causes shutdown Shutdown is handled by the process manager (supervisor) The app should handle sudden death. Sunday, September 23, 12
43. X. Dev/prod parity Keep development, staging, and production as similar as possible. Failing to do so increases: the time gap, personnel gap, and the tools gap. Sunday, September 23, 12
44. X. Dev/prod parity Sunday, September 23, 12
45. X. Dev/prod parity Traditional app Twelve- factor app Time between deploys Weeks Hours Code authors vs code deployers Different People Same People Dev vs production environments Divergent As Similar as Possilbe Sunday, September 23, 12
46. XI. Logs App never concerns itself with routing or storage of its output stream. Sunday, September 23, 12
47. XI. Logs App never concerns itself with routing or storage of its output stream. Each process writes to stdout. Sunday, September 23, 12
48. XI. Logs App never concerns itself with routing or storage of its output stream. Each process writes to stdout. The Python logger will work just fine Sunday, September 23, 12
49. XI. Logs App never concerns itself with routing or storage of its output stream. Each process writes to stdout. The Python logger will work just fine Can see the whole ecosystem, searchable. Sunday, September 23, 12
50. XI. Logs App never concerns itself with routing or storage of its output stream. Each process writes to stdout. The Python logger will work just fine Can see the whole ecosystem, searchable. OS decides where they go. Loggly, etc. Sunday, September 23, 12
51. XI. Logs Event Stream Sunday, September 23, 12
52. XI. Logs 2012-02-22T19:56:40+00:00 [postgres]: .... 2012-02-22T19:56:40+00:00 [router]: GET mysite.com/ ... 2012-02-22T19:56:40+00:00 [nginx]: .... 2012-02-22T19:56:40+00:00 [worker]: .... Sunday, September 23, 12
53. XII. Admin processes One off processes: manage.py syncdb Sunday, September 23, 12
54. XII. Admin processes One off processes: manage.py syncdb Identical environment. Same code, config. Sunday, September 23, 12
55. XII. Admin processes One off processes: manage.py syncdb Identical environment. Same code, config. Shipped with code. Sunday, September 23, 12