The Twelve-Factor AppA Case Study of Pivotal Tracker on Cloud Foundry

Glenn Oppegard goppegard@pivotal.io

Pivotal Tracker• Development started in 2006, when Pivotal Labs

was starting their Ruby practice

• Ruby 1.8.7 → Ruby 2.1

• Rails 2.3 → Rails 3.2

1. Codebase

• Single codebase

• Many deploys

Image from 12factor.net, MIT License

Tracker codebase• Single bosh release git repository

cf-tracker-release/ src/ cf-tracker/ memcached/ tracker/ tracker-frontend/ tracker-solr-home/

2. Dependencies• Explicitly declare and isolate dependencies

• Ruby: bundler and Gemfile

• Node: npm and package.json

Tracker dependencies• Bundler

• NPM

• Git sub-modules

• Single artifact containing all dependencies: BOSH final release tarball: cf-tracker-1.2.1.9.tgz

3. Config• Resource handles to the database, Memcached,

and other backing services

• Credentials to external services such as Amazon S3 or Twitter

• Per-deploy values such as the canonical hostname for the deploy

Tracker config• All config is centralized to a singleton object

• t2config(:smtp_host)

• Reads from environment variables, but also allows for computed values via Ruby

• Out of 200 config parameters, 25 apply to CF

• Created app_env gem to load static values from JSON files into environment

• Treat backing services as attached resources.

• The code for a twelve-factor app makes no distinction between local and third party services.

4. Backing Services

Image from 12factor.net, MIT License

Tracker services

5. Build, release, run• Strictly separate build and run stages

• Build: compile code, vendor dependencies, minify assets

• Release: combine build output with a deploy's config

• Run.

Tracker build stages• AWS: Continuous Integrations builds "frontend" assets,

stored in S3

• Local: bosh create release

• Strip code not needed on-premise

• Vendor dependencies (bundle install)

• Download frontend from S3

• CF: Ruby buildpack applied to app source

6. Processes• Execute the app as one or more stateless

processes

Tracker processes

7. Port binding• Export services via port binding

8. Concurrency• Scale out via the process model

• The unit of currency for a 12-factor app is the process

Tracker Processes• Web: horizontal scaleout

• Worker: split job-types

• Coming soon: CF Process Types

9. Disposability• Processes can be killed at any time

• Gracefully handle SIGTERM

• Minimize startup time

10. Dev/prod parity• Mac vs Linux

• SQLite vs MySQL

• In-memory cache vs Memcached

• Solr

• Coming Soon: Lattice Condenser

11. Logs• Don't write to disk

• Stream to stdout (or stderr on CF)

Tracker logs• rails_12factor.gem

• rails_stdout_logging.gem

12. Admin processes• Run admin/management tasks as one-off

processes

• Run tasks in an identical environment to the deploy (same build and same config → same release)

Tracker admin tasks• Restrict tasks to index 0 of app

• Future: diego one-off processes

Credits

• All 12-Factor App diagrams from 12factor.net, MIT License