The Twelve-Factor App

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