Heroku is great! Until you want to build something mildly complex or off script.
It provides a great platform to quickly deploy prototypes witten in pretty much any langauge via git. This allows you to focus on your app and getting your ideas out there IRL. But as with most magic bullets you quickly start to run into their limitations.
- Heroku is expensive! 35 USD per dynamo after the free tier, that’s a lot of money, especially for my developing world budget.
- They don’t support long running, always up processes very well/at all. Not everything falls into web/worker dichotomy (web scraping).
Enter Dokku and Docker
Dokku is your very own PAAS in 200 lines of
bash. How on earth can you replicate Heroku with a couple of bash files? Simple,
by leveraging the awesome power of Docker to spin up
isolated application containers. Dokku simply provides some nice wrapper
functions around docker to help you manage your containers as if you were
deploying them to Heroku (git push deploy and all!).
Digital Ocean
Digital Ocean have a prebuilt application image with dokku installed, let’s spin up a 1GB VM (dokku needs a minimum of 1GB RAM) using the dokku application image.
Dokku
I’m going to try aviod repeating what is already covered in their excellent documentation.
One thing that took me a while to understand (cause I’m a little slow on the up
take some times), is that dokku is simply bash script sitting on a server. In
order to make use of it you need to fire up a bash session on that server. There
are a bunch of clients but all they do is wrap executing the dokku commands
over ssh. Personally I’ve not had a problem pushing via git and sshing onto
the server to interact with dokku.
ssh onto your newly provisioned VM and let’s have a look at dokku
$ dokku
Usage: dokku [--quiet|--trace|--rm-container|--rm|--force] COMMAND <app> [command-specific-options]
Primary help options, type "dokku COMMAND:help" for more details, or dokku help --all to see all commands.
Commands:
apps List your apps
certs Manage Dokku apps SSL (TLS) certs
checks Show zero-downtime status
config Display all global or app-specific config vars
docker-options Display app's Docker options for all phases (or comma separated phase list)
domains List domains
enter Connect to a specific app container
events Show the last events (-t follows)
help Print the list of commands
logs Show the last logs for an application
ls Pretty listing of deployed applications and containers
nginx Interact with Dokku's Nginx proxy
plugin Print active plugins
proxy Show proxy for app
ps List processes running in app container(s)
run Run a command in the environment of an application
shell Spawn dokku shell
storage Mount local volume / directories inside containers
tags List all app image tags
tar An alternative to using git. Apps are loaded via tarballs instead
trace Enable dokku tracing
url Show the first URL for an application (compatibility)
urls Show all URLs for an application
version Print dokku's version
Cool, now that we’ve verified that we’ve got a working copy of dokku on a server.
Application Architecture Philosophy
Now for some application architecture philosophy. Dokku is a open source Heroku clone, Heroku forces a certian application architecture style based off the ideas laid down by the 12 Factor App which was written by one of the Heroku co-founders. This has a couple of very direct implications on how you as a developer build your appliction.
- Version Control: Your codebase is tracked by and deployed via version control.
- Dependencies: Explicitly declare and isolate dependencies, basically just make use of a package manager to handle your dependencies.
- Backing Services: Any servive the app accesss over the network, database, cache, message queue is considered a backing service. There is no disdiction between local and 3rd party services, both are accessed via values stored in config.
- Configuration: An apps config is everything that is likely to vary between deploys. All config should be stored in the envonment, in our case system environment variables.
I highly recommend you read the full thing online, it has played a fundamental role in the development of the whole microservices movement.
Dokku allows you to deploy your applications using Heroku build packs , exactly as if you were deploying directly to Heroku. And using Dockerfiles , which allows you to leverage the full power of the docker universe.
Docker, so what?
The whole point of this exercise; is that I’m disatisfied with the existing
options provided by Heroku. This is where docker comes into play. Docker
allows you to quickly spin up fully fledge linux environment at a fraction of
the cost of a VM. This means I’m no longer tied to their existing web / worker
dichotomy enforced by most PAAS providers. Which while it covers most web
related server roles, it does negelect two rather important server workloads.
Namely scheduled tasks and always up jobs.
Push vs Pull workloads
I like to think of the two types of jobs falling into two different categories,
a push workload where requests are “pushed” to a queue for processing and pull
workload where the server is responsible to go out and find work to “pull” in
for processing. Push workflows are well covered by the web / worker process
types provided by existing PAAS providers, what I find lacking is a good PAAS
solution for pull workflows. This is where docker and dokku really find the
niche I’ve been trying to full for so long.
I mean AWS still doesn’t have any sort of scheduled task service, your best option is still auto-scaling groups , which I find absolutely ridiculous TBH.
Conclusion
Dokku provides an easy way to build the missing piece of the PAAS puzzle that
I’ve been searching for, for all these years. Next up, write up the Twitter
scrapper I’ve built and deployed to dokku, giving a conrete demonstration of
all the wonderful problems solved by dokku and docker.