The 12Factor App

The 12Factor App

6fa1cdda524d49996a8bc6917328de3d?s=128

Damien Mathieu

October 30, 2014
Tweet

Transcript

  1. @dmathieu Software Engineer @heroku The 12Factor App 1

  2. Twelve Factor • Can apply to any language and platform!

    • Speeds up deployment! • Makes scaling easier! • Keeps apps clean 2
  3. Let’s take a look 3

  4. One codebase to rule them all 4

  5. Codebase Production Staging Feature A Feature B 5

  6. 6 Multiple codebases is a distributed system

  7. 7 Create libraries

  8. Explicitly declare and isolate dependencies 8

  9. 9 source 'https://rubygems.org' ! ruby '2.1.3' ! gem 'rails' gem

    'pg' gem 'puma'
  10. 10

  11. 11 curl imagemagick

  12. 12 Config never goes in source control

  13. Config Resource strings to databases Credentials to S3, Facebook, Twitter,

    … Security Tokens 13
  14. $ cat .env! AWS_TOKEN=QWERTYUIOP! AWS_SECRET=12345 ! GITHUB_APP_ID=1! GITHUB_SECRET=67890 14

  15. $ foreman run rails console! >> puts ENV[‘AWS_TOKEN’]! > “QWERTYUIOP”

    15
  16. You can use a yml config file* *Just don’t store

    it in source control
  17. Treat backing services as attached resources 17

  18. 18 DATABASE_URL= postgres://example.com:5032

  19. Production deploy PostgreSQL Email Service Amazon S3

  20. 20 One codebase per app Explicitly declare and isolate dependencies

    Don’t put config in source control Treat backing services as attached resources
  21. Build Release Run 21

  22. Codebase Build Run Config 22

  23. Codebase Build Run Config 23

  24. Execute the app as one or more stateless processes 24

  25. web.1 web.2 Database 25

  26. 26 No sticky sessions

  27. 27 Ephemeral filesystem

  28. 28 Export services via port binding

  29. 29 Self-contained app

  30. 30 An app can be the backing service for an

    other
  31. Scale out via the process model 31

  32. web.1 web.2 web.3 worker.1 worker.2 clock.1 32

  33. 33 You can still do your own internal multiplexing

  34. 34 Build, release, run One or more stateless processes Scale

    out via the process model Export services via port binding
  35. Maximize robustness with fast startup and graceful shutdown 35

  36. 36 Handle a request

  37. 37 60s to boot is a lot

  38. 38 Use the SIGTERM signal

  39. 39 Send jobs back to the queue

  40. 40 Build, release, run One or more stateless processes Scale

    out via the process model Fast startup
  41. Keep development, staging, and production as similar as possible 41

  42. 42 Use the same kind of machine

  43. 43 With the same OS version

  44. 44 And the same database server

  45. Logging 45

  46. 46 Production errors will happen

  47. 47 Tail logs to find the cause

  48. 48 Then use a logging service to dig in deeper

  49. action=create_user email=foo@bar.com action=log_user email=alice@heroku.com 49

  50. count#api-call-200=1 50

  51. Don’t write logs to a file 51

  52. Run admin/ management tasks as one-off processes 52

  53. 53 Not in your app’s main processes

  54. 54 Run console instances the same way

  55. 55 Keep all your environments as similar as possible Run

    management tasks as one-off processes Logging
  56. Do you like? • Minimizing new developer overhead?! • Running

    in multiple environments?! • Easily scaling without tooling, architecture or development headaches?! • Having the latest update available to users at a moments notice? Read more at 12factor.net 56
  57. Questions? damien@heroku.com 12factor.net 57 @dmathieu