-
Notifications
You must be signed in to change notification settings - Fork 8
/
twelve-factor.slide
174 lines (116 loc) · 4.97 KB
/
twelve-factor.slide
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
Twelve-factor app
Fri Apr 29 2016
Kwok-kuen Cheung
Oursky
@cheungpat
* What is twelve-factor app?
- methodology for building web apps
- a clean contract between your app and the underlying operating system
- make your app portable—run anywhere between local development and cloud platforms
- good for any programming languages
* What can you do with twelve-factor?
- helps you setup automation
- enabling continuous deployment
- make your app easy to scale up
- make your app portable
- minimize time for new developers to join the project (and others to help you)
* What are the factors?
1. Codebase
2. Dependencies
3. Config
4. Backig services
5. Build, release, run
6. Processes
7. Port binding
8. Concurrency
9. Disposability
10. Dev/prod parity
11. Logs
12. Admin processes
* 1. Codebase
“One codebase tracked in revision control, many deploys”
- you app is tracked in a single repo known as a codebase
- there should be only one codebase per app, and vice versa
- the same codebase is deployed to multiple environment (e.g. development, production, etc)
.image twelve-factor/codebase-deploys.png
* 2. Dependencies
“Explicitly declare and isolate dependencies”
- explicitly declare all dependencies in a manifest (e.g. Gemfile, requirements.txt, etc)
- e.g. `requests==2.4.3`
- do not assume dependency or tools installed by operating system
- e.g. Python `requests` package is usually installed in Ubuntu, but it is not part of the standard library
* 3. Config
“Store config in the environment”
- database password, third-party access tokens, etc are examples of config
- config vary for different deploys
- config comes from environment (in the form of environment variable)
- bad practice: need to modify config file when deploying the app
* 4. Backing services
“Treat backing services as attached resources”
- backing services are consumed by your app over the network
- e.g.: database, Amazon S3 and third-party APIs
- able to swap backing service without changing the code
- e.g.: use different database in different environment
- e.g.: use sandbox API in staging environment
* 5. Build, release, run
“Strictly separate build and run stages”
Three stages two transform a codebase into a running app:
- build: transform codebase to executable
- release: combine executable and config
- run: launching a release
* 5. Build, release, run
“Strictly separate build and run stages”
- these three stages do not allow modifying code at runtime
- a release has everything the server need to run the app
- deployment tool should be able to rollback release
.image twelve-factor/release.png
* 6. Processes
“Execute an app as one or more stateless processes”
- process should be stateless
- process should share-nothing
- process can only use memory or filesystem as cache (do not expect data to be always there)
- process should save persistent state in a backing service
* 7. Port binding
“Export services via port binding”
- web apps should expose a HTTP port (e.g. `http://0.0.0.0:5000`)
- an external proxy route web traffic to your port
- do not assume you can listen at a specific port (should be configurable)
* 8. Concurrency
“Scale out via the process model”
- if your app has a diverse workload, define process type for each workload
- e.g.: web process serving web request, worker process serving background jobs
- scale out by launching process concurrently for different workload
.image twelve-factor/process-types.png
* 9. Disposability
“Maximize robustness with fast startup and graceful shutdown”
- processes are disposable—they can be started and stopped anytime
- process should gracefully shutdown when it receive SIGTERM
- e.g. cleanup running job when exiting
- process should be robust against sudden death
- e.g. unfinished job can be picked up by other process
* 10. Dev/prod parity
“Keep development, staging, and production as similar as possible”
Time gap
- how much time since last deployment?
- minimize time between deploys—continuous deployment
Personnel gap:
- is the person who develop the app also the person who deployed it?
- developer should also be involved in deploying and monitoring the app
Tools gap:
- is the same tool used in development and production?
- should use the same tool for development and production (e.g. SQLite in dev vs PostgreSQL in prod)
* 11. Logs
“Treat logs as event streams”
- logs are a stream of events collected from all running processes
- the app should not be concerned about storing the log
- write log to stdout
- the execution environment is responsible for processing the log
- e.g. supervisord can collect app log and write the log to files
* 12. Admin processes
“Run admin/management tasks as one-off processes”
- commands for one-off maintenance tasks (e.g. `python manage.py migrate`)
- commands must be shipped with the code
- commands should be run in the same environment of the running app, such as using the same build, config and release
* See also
- http://12factor.net