The Twelve-Factor App

http://12factor.net/ - what, why, how

From PyCon UK 2014

Transcript

1. The Twelve-Factor App Kristian Glass @doismellburning http://www.doismellburning.co.uk/talks/django12factor 1
2. •I do development •I do operations •I write code and care how it runs 2
3. What is Twelve Factor? “A methodology for building web apps” 3
4. Core Concept Clean interface between app and underlying system 4
5. #1 One code repository, many deploys 5
6. #2 Explicitly declare and isolate dependencies 6
7. So, virtualenv and requirements.txt ? 7
8. $ pip install -r requirements.txt! # …! Downloading/unpacking gevent! Running setup.py egg_info for package gevent! # …! gevent/libevent.h:9:19: error: event.h: No such file or directory! # …! error: command 'gcc-4.2' failed with exit status 1 8
9. So how? •Containers/VMs •OS packages (ish) 9
10. #3 Read config from the environment 10
11. What is Config? Everything likely to vary between deploys 11
12. Config Examples •Service URLs (Database, mail, etc.) •Service credentials •Debug flag 12
13. Why do this? •Separation of responsibility •Language and framework independent •Avoid leakage of secrets 13
14. But config files? •Apps read from environment •Environment may come from files 14
15. How do I populate the environment? • foreman • honcho • envdir • supervisor • bash scripts • and more… 15
16. Using Django? https://github.com/doismellburning/ django12factor 16
17. #4 Treat backing services as attached resources 17
18. Attached Resources •No distinction between local/external resources •Loose coupling 18
19. #5 Distinct build/ release/run stages 19
20. Build / Release? build :: Code -> Executable! ! release :: Config -> Executable -> Release Artefact 20
21. Example: Building a Django Project $ git clone! $ virtualenv! $ pip install -r requirements.txt! $ manage.py collectstatic ! $ fpm 21
22. Releases •New config? New release •New code? New build, new release 22
23. Run stage As simple as possible 23
24. Why? •Do hard work in advance •Optimise the common case 24
25. #6 Run as stateless process(es) 25
26. Stateless Processes •Persist data to external services •Assume nothing about RAM/ disk •No sticky sessions 26
27. #7 Export services via port binding 27
28. What does this mean? •Your app should offer its services by some protocol on some port •Self-contained services: run and go 28
29. #8 Scale out with processes 29
30. Process model •More load? More processes •Background jobs? Worker processes •Don’t daemonise, that’s manager’s job 30
31. #9 Start quickly, stop nicely 31
32. Start quickly, stop nicely •Disposable apps •Auto-scale easily •Deploy quickly and easily 32
33. #10 Keep environments as similar as possible 33
34. Three prod/dev gaps •Time gap •People gap •Tools gap 34
35. Time gap •“Production is weeks behind dev” •Solution: Deploy more 35
36. People gap •“Developers write code, Ops run it” •Solution: DevOps 36
37. Tool gap •“It works on my machine” •Solution: Use the same tools everywhere 37
38. #11 Treat logs as event streams 38
39. Logs as event streams •No logfile / routing / storage handling •Spit logs out to stdout •One event, one line 39
40. #12 Admin tasks as part of your app 40
41. What does that mean? •Django management commands are a great example •$ python manage.py syncdb! •No private folders of “useful snippets” •Keep them with the app 41
42. Recap 1. One codebase 2. Dependencies 3. Config in environment 4. Backing Services 5. Build, release, run 6. Stateless processes 7. Port binding 8. Scale with processes 9. Disposability 10. Dev/prod parity 11. Logs as event stream 12. Admin processes 42
43. Recap •It does not matter what language •It does not matter what framework 43
44. Questions? http://www.doismellburning.co.uk/talks/django12factor 44