Deploy, run and
manage Java application on Heroku:
- Application = source code for
application + web or application server framework + dependencies on third
party libraries + dependency description (pom.xml) that instructs a build
system (maven) to download the needed dependencies from a repository in
order to build the application + Procfile.
- Procfile - lists named
commands that you may want executed.
web: java -jar lib/foobar.jar
$PORT
queuty: java -jar lib/queue-processor.jar
Defines
a 'web' process type and provides a command that needs to be executed in order
to run it.
- Git - used as primary means
for deploying applications on Heroku platform. When application is created
on Heroku, a new git remote is associated typically named
"heroku" with the local git repository for your application. To
deploy, simply do a git push heroku
master. Thus git
acts as a transport mechanism to push local application to heroku platform
(remote).
- When Heroku platfrom receives
a git push, it builds the application - mvn clean install.
- Slug - a bundle of
application source code + dependencies + JRE + binary o/p from mvn
install. A slug is the application ready for execution.
- Dynos - Heroku executes the
applications by running a command you defined in Procfile on a dyno (unix
container like Docker) that has been preloaded with slug and config-vars
and add-ons (together called a release).
Each dyno gets its own ephemeral
filesystem - with a fresh copy
of the most recent release. It can be used as temporary scratchpad, but changes
to the filesystem are not reflected to other dynos.
- To retain state information
across dyno restarts use DB or message queues. The filesystem on a dyno
are temporary.
- User can control the number
of dynos: heroku ps:scale web=3 queuty=2 for example will run 5 dynos (3
for web and 2 for queuty process types).
- When a new version of
application is pushed to heroku platform, currently executing dynos are
killed and new ones are spawned to replace them with the new release.
- Application config-vars are
set as:
heroku config:set
ENCRYPTION_KEY= my_secret_launch_codes
These
are exposed to application as environment vars.
- Release = version controlled
ledger of (slug + config-vars + add-ons)
heroku releases - lists all changes deployed
with their version id (internally they might be mapping version ids to git SHA
ids)
Everytime
you deploy, new slug is created and a release is generated.
Its
thus very easy to rollback to a previous release.
Heroku releases:rollback v102
- Dyno manager - manages dynos
across all applications deployed on heroku platform.
- Add-ons - are pluggable
services like email service, Database service, queuing or caching services
etc.
For example, a REDISTOGO_URL will be automatically added to your application
when you provision the add-on. You can write code that connects to the service
through the URL, for example:
uri
= URI.parse(ENV["REDISTOGO_URL"])
REDIS
= Redis.new(:host => uri.host, :port => uri.port, :password =>
uri.password)
- Logplex automatically collates
log entries from all the running dynos of your app, as well as other
components such as the routers, providing a single source of activity.
- HTTP Routing:
Heroku’s HTTP routers distributes incoming requests for your
application across your running web dynos.
