heroku architecture and usage
DESCRIPTION
Heroku Architecture and usageTRANSCRIPT
Introduc)on to Heroku By Bhagwat Kumar
Agenda
• What and why Heroku? • Dynos. • Process Model. • Deploy and manage your app. • Advance features of Heroku. • Restric@ons by Heroku • Case study
How do you manage your QA/Prod servers • Install java run-‐@me • Install tomcat / setup webapp-‐runner • setup services that you want to manage yourself
– Mysql/Postgres/Mongodb/Redis/Memcache/RabbitMQ etc • Install OS tools that your app depends on.
– ImageMagic/curl/wget etc • Setup version control if planning to build war here • Write deploy script which
– Download latest war/ build war – Stop tomcat and copy war file to tomcat/webapp – Restart tomcat
• Write monitor script for restar@ng crashed services • Write script for data and logs backup
What and why Heroku?
• A polyglot cloud applica@on plaLorm. • Spend 100% of your @me on applica@on code in language of
your choice. • Forget managing servers, deployment, ongoing opera@ons, or
scaling.
How it works?
• Deploy – Just a git push
• Connect – Add 3rd party resources
• Command – Use CLI/Web interface
• Observe – All ac@vi@es logged using Logplex
• Scale – Independent scaling of components
• Relax – Takes full responsibility for your app's health
What happens when you git push to Heroku remote?
• It ini@ates a build of the source applica@on. • Installs language and framework needed to build the app • retrieves the specified dependencies and caches it • create necessary assets e.g. compile code or do compression • All these are assembled into a slug
– a bundle of generated code – Dependencies – Language run@me – Compiled/generated output of the build system – Procfile defining process types
Running applica@on on Dynos
• Dynos are isolated, virtualized unix containers • It provides required environment to run the app • A dyno runs a single user-‐specified command/process • Currently 3 types of Dynos are available(27-‐Jul-‐2014):
Size RAM CPU share Price/dyno hour
1X 512 MB 1x $ 0.05
2X 1 GB 2x $ 0.10
PX 6 GB 100 % (8 core) $ 0.80
Dyno Manifold
• Provides an environment for your app's dynos – Distributed – Fault tolerant – Horizontally scalable
• Tasks – Restar@ng faulty dyno – Checking for idle dyno – Restar@ng on config changes – Restar@ng on new releases
Process Model
• The prototype using which one or more dynos are instan@ated • Define Process types using Procfile • A process type has a name and a command • "Web" process type is special
– Heroku router routes HTTP requests to Web dynos only.
Procfile examples
web: java -‐jar server/webapp-‐runner.jar -‐-‐port $PORT target/*.war worker: java -‐jar server/webapp-‐runner.jar -‐-‐port $PORT target/*.war
web: node app.js worker: node workerApp.js scheduler: node schedulerApp.js
Demo • Create and deploy heroku app
– heroku create mysample-‐app -‐-‐remote staging – git push staging master
• Monitor logs – heroku logs –t – heroku logs –t –p
• Watch processes – heroku ps
• Rescale – heroku scale web=2 worker=1
• Play with configura@on – heroku config – heroku config:set KEY=VALUE
• Releases and rollback – heroku releases – heroku rollback
Advance features
• Blue green deployment • Monitor CPU and memory usages • Fork exis@ng Heroku app • Managing mul@ple environments • Pipeline push among various apps/environments
Blue green deployment
• hops://devcenter.heroku.com/ar@cles/labs-‐preboot • heroku labs:enable preboot
Monitor CPU and memory usages
• hops://devcenter.heroku.com/ar@cles/log-‐run@me-‐metrics • heroku labs:enable log-‐run@me-‐metrics
Fork exis@ng Heroku app
• hops://devcenter.heroku.com/ar@cles/fork-‐app • heroku fork -‐a sourceapp targetapp
– #remote of new app not added automa@cally
• heroku info -‐a targetapp – #to know git remote
• git remote add forked [email protected]:targetapp.git
Managing mul@ple environments : staging/uat/prod
• hops://devcenter.heroku.com/ar@cles/mul@ple-‐environments • heroku create staging-‐todo -‐-‐remote staging • heroku create prod-‐todo -‐-‐remote produc@on • heroku logs -‐t -‐r produc@on
– You must specify heroku app remote or app name using –a flag
• git config heroku.remote staging – Make staging as default heroku app for heroku commands
Pipeline push among various apps/environments
• hops://devcenter.heroku.com/ar@cles/labs-‐pipelines • heroku labs:enable pipelines • heroku plugins:install git://github.com/heroku/heroku-‐
pipeline.git • heroku pipeline:add myapp
– #add target app for pipeline, source is current app • heroku pipeline:diff • heroku pipeline:promote
– No build phase is required on target app.
Heroku restric@ons to make it a beoer app
• Build must complete within 15 minutes. • Web process must start listening to specified port within 60
seconds. • Request @meout page shown if request takes more than 30
seconds to process. (Actual thread keeps running though). • Max 100 dynos for 1x/2x process types and max 10 dyno per PX
process types. • Dynos are cycled at least once per day. • If there are only one web dyno running, it will be idled out auer
one hour of inac@vity
Checklist for Heroku ready apps
• Dynos execute in complete isola@on from one another • File system dependency • OS tools dependency • Hop sessions • Database connec@on pool • Cache services • Jobs
Case studies
• Mat.se – www.mat.se grails
• Swedeponic.se – hop://www.swedeponic.se nodejs
• Mewithyou.com – www.mewithyou.com nodejs
• Stoot pusher service – hop://stoot.herokuapp.com nodejs
Ques:ons?
Thank you. [email protected]