Downloaded 79 times
Uploaded byLuís Bianchin
12 factor app
The document outlines the 12-factor app methodology for building and deploying portable, scalable applications on cloud platforms. It emphasizes best practices such as managing codebase, dependencies, configuration, and services to ensure continuous deployment and operational efficiency. Key principles include separating build, release, and run stages, treating logs as event streams, and maintaining development and production parity.
More Related Content
12 factor app
- 1. 12 Factor App Buildingand releasing at the web-scale 1 / 17
- 2. Motivation Heroku PaaS withCedar stack as way of building portable apps Easy to deploy and scalable, for any language IaaS => Infra, PaaS => Apps Docker, CoreOS, Dokku, Flynn, Deis, ... 12 Factor: Best practices on how PaaS apps should architected PaaS-friendly apps need to not care where they are 2 / 17
- 3. Introduction Declarative formats forsetup automation Maximum portability between execution environments Deployment on modern cloud platforms Minimize divergence between prod/dev Enables continuous deployment Scale up easily 3 / 17
- 4. I. Codebase One codebasetracked in revision control, many deploys Single app per codebase 4 / 17
- 5. II. Dependencies Explicitly declareand isolate dependencies Never rely on the implicit existence of any system tools Supports reproducible builds Examples of tools: gem/bundle, pip/virtualenv, autoconf, ... HIGH importance 5 / 17
- 6. III. Config Store configurationin the environment (NOT code) Config is anything that may vary between deploys: Resource handles Credentials Canonical hostname for the deploy Strict separation of config from code Does not include internal application config (like Spring) 6 / 17
- 7. IV. Backing services Treatbacking services as attached resources No distinction between local and third party services Allows great flexibility Loose coupling to the attached deploy Resources can be attached and detached to deploys at will, no code changes 7 / 17
- 8. V. Build, release,run Strictly separate build, release and run stages Build : Converts code repo into an executable bundle Release : Build with deploy's current config, ready for immediate execution Run : Launches a set of app's processes against a selected release 8 / 17
- 9. VI. Processes Execute theapp as one or more stateless processes Stateless and share-nothing Session data should be stored with a time-expiration, e.g. Memcached or Redis Stateless means: More robust Easier to manage Incurs fewer bugs Scales better 9 / 17
- 10. VII. Port binding Exportservices via port binding Exports HTTP as a service by binding to a port Routing layer to handle requests routing to a hostname Uses Webserver libraries such as Jetty for JVM or Thin for Ruby One app can become the backing service for another app 10 / 17
- 11. VIII. Concurrency Scale outvia the process model Processes are a first class citizen Never daemonize or write PID files Relies on OS process manager (upstart, systemd, launchd, foreman, ...) to: Manage output streams Respond to crashed processes Handle restarts and shutdowns 11 / 17
- 12. IX. Disposability Maximize robustnesswith fast startup and graceful shutdown Can be started or stopped at a moment’s notice Maximize robustness with fast startup and graceful shutdown Gracefully shut down when receiving a SIGTERM signal Processes should be robust against sudden death 12 / 17
- 13. X. Dev/prod parity Keepdevelopment, staging, and production as similar as possible Designed for continuous deployment Keep the gap between development and production small: Time gap: long time to prod Personnel gap: developers code, ops deploy Tools gap: different stack Resists to use different backing services between dev and prod 13 / 17
- 14. XI. Logs Treat logsas event streams Event stream is written to STDOUT Use log routers (such as Logplex and Fluent) 14 / 17
- 15. XII. Admin processes Runadmin/management tasks as one-off processes Run against a release: same code and config as any process run against that release Must ship with application code to avoid synchronization issues e.g. Database migration 15 / 17
- 16.
- 17.