Post on 17-Jan-2017
No more Deployment PainPaaS with Heroku
Content
- SaaS < PaaS < IaaS
- Toolchain as a Service
- About Heroku
- The Twelve Factor App
- Heroku architecture
- Terminology- Heroku Toolbelt
- Buildpack
- Confix vars
- Dyno
- Logplex
- Add-ons
- Preboot
- Pipelines
- Demo
SaaS < PaaS < IaaS
Software as a Service
Platform as a Service
Infrastructure as a Service
Toolchain as a Service- Manage your project
- Trello, Jira, PivotalTracker, ...
- Creating your code- Koding.com, ...
- Host your code- GitHib, BitBucket, ...
- Build you code- Travis CI, GreenHouse, ...
- Test your code- BrowserStack, Souce Labs, Blitz, ...
- Distribute your code- Maven Central, Docker Hub, npm, Bintray, ...
Heroku
- Developed since 2007- acquired by Salesforce.com in 2010
- One of the first PaaS providers
- Built on top of Amazon`s IaaS
- Started as Ruby platform- currently a polyglot platform
- Base OS started with Debian- currently runs Ubuntu stack
- Wide variety of add-ons- data tores, cachking, logging, monitoring, hypermedia processing, payments,...
Heroku Terminology- Application
- Procfile
- Deployment
- Buildpack
- Slug
- Dyno
- Config var
- Release
- Add-on
- Logplex
Heroku architecture- Reverse Proxy by nginx
- terminates SSL
- forwards to cache layer
- HTTP Cache by Varnish- returns cached pages immediately
- forwards to routing mest
- Routing Mesh written in Erlang- routes to an existing dyno
- spawns a dyno if none available
- Dyno Grid (‘railgun’ servers)- AWS hosted EC2 instances
- multiple dynos per server
Set up Heroku
Set up Heroku
Heroku Toolbelt- Heroku Client
- CLI tool for creating and managing Heroku apps
Stack, Buildpack, Slug compiler- Stack
- Operating System image (Ubuntu)
- Buildpack- collection of scripts, knows how to build and execute your app
- Slug compiler- build you app with buildpack, on the given stack
- creates slug, an image / binary, ready to be executed on Dyno
Config variables- Variable configuration between environments
- never store sensitive configuration in source repository
- Will be exposed as environment variables at runtime
- All dynos see the exact same set of variables at runtime
- Add-ons might expose config vars
- Dyno is an isolated lightweight Linux container
- Three types of dynos- web dyno, can receive HTTP traffic
- worker dyno, used for background, queuing and timed jobs
- one-off dyno, can run a command in a temporary dyno
- Dynos are ephemeral- shared state requires external data store
- Dyno manager- managed running dynos according to the defined ps
- sleeps dyno after 1 hour of inacitivity (for single 1X and 2X)
Dyno and Dyno Management
Logplex- Collates and distributes log entries
- all application dynos
- add-ons and other components
- Routes messages from sources to drains- source: any process that might want to emit log entries
- drain: any network service that want to consume log entries
- Limited log entry buffer- integrate to log-processing and managent add-ons
Add-ons
- Provided as services by Heroku and third parties
- add-ons available from market place
- starting from free plans to monthly subscriptions
- Add-on providers are responsible for their add-ons
- integrate via config vars
- some contain external web user interface
Preboot
Production cloud application without zero downtime deployments...- Changes the dyno start behavior to `blue - green`
- ensures new dynos are started and ready to receive traffic
- requires at least 2 dynos
- two versions of application dynos running at the same time
Pipelines
- Pipelines help to solve complexity of multi-environment- dev, test , staging, production, …
- Pipeline manages application slug- diff between current and downstream app
- promote slug to downstream target
- I. Codebase - One codebase tracked in revision control, many deploys
- II. Dependencies - Explicitly declare and isolate dependencies
- III. Config - Store config in the environment
- IV. Backing Services - Treat backing services as attached resources
- V. Build, release, run - Strictly separate build and run stages
- VI. Processes - Execute the app as one or more stateless processes
- VII. Port binding - Export services via port binding
- VIII. Concurrency - Scale out via the process model
- IX. Disposability - Maximize robustness with fast startup and graceful shutdown
- X. Dev/prod parity - Keep development, staging, and production as similar as possible
- XI. Logs - Treat logs as event streams
- XII. Admin processes - Run admin/management tasks as one-off processes
The Twelve-Factor App - 12factor.net
Demo - Deploy BrainDev Spring Boot app
1. Create App Heroku
a. heroku apps:create braindev-demo-staging --remote staging ---buildpack https://github.com/heroku/heroku-buildpack-scala
b. git remote add staging https://git.heroku.com/braindev-demo-staging.git
2. Publish
a. git push staging master
3. See log
a. heroku logs -t
4. Set config
a. heroku config:set MY_ENV=staging -a braindev-demo-staging
b. heroku config:set MY_ENV=prod -a braindev-demo-prod
5. Pipeline
a. heroku plugins:install heroku-pipelines
b. heroku pipelines:create -a braindev-pipeline
c. heroku apps:create braindev-demo-prod --remote prod
d. heroku pipelines:add -a braindev-demo-prod braindev-pipeline
Thank you