Your own mini-Heroku for $5/month(blog.rajivm.com)
blog.rajivm.com
Your own mini-Heroku for $5/month
http://blog.rajivm.com/your-own-mini-heroku-for-5-dollars-per-month.html
14 comments
I'd be curious to see why you're having issues setting up Dokku on Digital Ocean. They provide a one click image, so you should be able to just deploy the new instance, setup DNS (the two A records-- one of them is a wildcard), visit the instance's IP address and click Finish Setup, and then deploy your application.
Have you tried doing a really simple sample app? It may take some coercing to get an existing Heroku app to run (there's some differences between Heroku's buildpacks and Dokku, like in the PHP buildpack). I did write a blog post on the topic of DO-with-Dokku specifically not too long ago, which goes over deploying a "hello world" Node app: http://www.andrewmunsell.com/blog/dokku-tutorial-digital-oce...
Have you tried doing a really simple sample app? It may take some coercing to get an existing Heroku app to run (there's some differences between Heroku's buildpacks and Dokku, like in the PHP buildpack). I did write a blog post on the topic of DO-with-Dokku specifically not too long ago, which goes over deploying a "hello world" Node app: http://www.andrewmunsell.com/blog/dokku-tutorial-digital-oce...
I've had the same overall experience as kohanz with Rails. Little toy apps do work but details are sparse while trying to troubleshoot things. I'd probably wait for Flynn to mature and look at that before investing much more time in Dokku.
Of note for anyone reading: 1. Since the buildpacks are based on Heroku, if you're having trouble try seeing what it'd take to get your app deployed there. For example with Rails 3.2, if you pre-compile your assets on the production server while deploying an app it will try to instantiate your app and test a database connection; however, Dokku doesn't provide the database configuration until after this step of the deployment so your deploy will fail. This is fixed by either pre-compiling locally or changing a setting in application.rb. In Rails 4 I believe you just have to precompile your assets and check them along with the manifest into your repo. (Ref: https://github.com/progrium/dokku/issues/165, https://github.com/progrium/dokku/issues/202)
2. It's probably easier to just set up a separate database rather than relying on one of the project's plugins. Right now they're just a little too obfuscated and hard to troubleshoot (the dokku-postgresql plugin I used would lose its persistent volume on server reboot).
Of note for anyone reading: 1. Since the buildpacks are based on Heroku, if you're having trouble try seeing what it'd take to get your app deployed there. For example with Rails 3.2, if you pre-compile your assets on the production server while deploying an app it will try to instantiate your app and test a database connection; however, Dokku doesn't provide the database configuration until after this step of the deployment so your deploy will fail. This is fixed by either pre-compiling locally or changing a setting in application.rb. In Rails 4 I believe you just have to precompile your assets and check them along with the manifest into your repo. (Ref: https://github.com/progrium/dokku/issues/165, https://github.com/progrium/dokku/issues/202)
2. It's probably easier to just set up a separate database rather than relying on one of the project's plugins. Right now they're just a little too obfuscated and hard to troubleshoot (the dokku-postgresql plugin I used would lose its persistent volume on server reboot).
Part of that, for me at least, was dokku's eternally moving goalposts. It's been under pretty heavy development, and APIs/setup methods changed pretty rapidly. I'd get it going one week, come back in a month, and enough would have changed that I'd have to reinstall.
Now that releases are being tagged (0.2.0, for instance), using it in a semi-stable manner should be easier :).
Now that releases are being tagged (0.2.0, for instance), using it in a semi-stable manner should be easier :).
>Part of the big ease of Heroku is, that you don't have to create Heroku before you use it.
I agree. It defeats the purpose of services like Heroku where users want a place to upload code and have it just work.
You also make a good point on maturity. It took many engineers years to make Heroku a mature product and keep it humming.
I do think this stuff is cool though. There's definitely a place for this sort of thing but I don't know if it should be marketed as PaaS. As soon as something becomes DIY, I would stop considering it SaaS or PaaS.
Full disclosure: I'm an Engineer at Salesforce which owns Heroku
I agree. It defeats the purpose of services like Heroku where users want a place to upload code and have it just work.
You also make a good point on maturity. It took many engineers years to make Heroku a mature product and keep it humming.
I do think this stuff is cool though. There's definitely a place for this sort of thing but I don't know if it should be marketed as PaaS. As soon as something becomes DIY, I would stop considering it SaaS or PaaS.
Full disclosure: I'm an Engineer at Salesforce which owns Heroku
One advantage I can see to something like this is that unlike Heroku, it could be made suitable for enterprise companies scared of the idea of having your software/data on hardware you don't own.
That being said, I agree 100% for pretty much every other use case.
That being said, I agree 100% for pretty much every other use case.
This is a mini-Heroku until you hit some database or routing issues. Then it is just another server you have to manage yourself.
Curious what sort of database or routing issues did you run into?
My point is that you still not to manage this. Heroku does that for you.
Like Heroku failed: https://blog.heroku.com/archives/2013/4/3/routing_and_web_pe...
Has anyone used Elastic Beanstalk?
It seems like that is always missing from these conversations. Maybe it has a bad price point or something? I'm going to look into it soon... Seems to me that standard EB + RDS + ElastiCache would make a lot more sense than these single server not-proven-scalable setups. I can't run a real production Rails app with this Dokku setup it seems...
And then if I need Solr or something extra I could stick it on the EB instance or spin up a new EC2 for services. Heroku add-on services cost so much that I bet running a micro instance is cheaper than paying the monthly fee for the add-on, plus you could stick a few on 1 box since you're limited only by bandwidth/CPU.
It seems like that is always missing from these conversations. Maybe it has a bad price point or something? I'm going to look into it soon... Seems to me that standard EB + RDS + ElastiCache would make a lot more sense than these single server not-proven-scalable setups. I can't run a real production Rails app with this Dokku setup it seems...
And then if I need Solr or something extra I could stick it on the EB instance or spin up a new EC2 for services. Heroku add-on services cost so much that I bet running a micro instance is cheaper than paying the monthly fee for the add-on, plus you could stick a few on 1 box since you're limited only by bandwidth/CPU.
> single server not-proven-scalable setups
Using AWS Micro instances will not solve your problem, no matter how many you have. It's also worth noting that AWS costs around 5x more than a good dedicated server, which is a factor for many people.
Using AWS Micro instances will not solve your problem, no matter how many you have. It's also worth noting that AWS costs around 5x more than a good dedicated server, which is a factor for many people.
Ah the 5x multiplier i understand...
But as far as AWS micro is concerned, it was an example for starter size. These are easily scalable I believe either through Elastic Beanstalk tools or manually. On RDS for example (which I am more familiar with) if you have a small DB instance that is hitting CPU limits, you right click & hit modify... about a minute later it is now whatever size you want. And I think their instances get large enough that you would have to be running a reallll heavily-trafficked app to actually hit a wall. (I haven't read enough about EB which is why I asked the question but I think it is auto-scaling)
Again, maybe not as cost effective as dedicated but I think at this point it may be a good compromise between the two while the container community works out some deployment hurdles.
But as far as AWS micro is concerned, it was an example for starter size. These are easily scalable I believe either through Elastic Beanstalk tools or manually. On RDS for example (which I am more familiar with) if you have a small DB instance that is hitting CPU limits, you right click & hit modify... about a minute later it is now whatever size you want. And I think their instances get large enough that you would have to be running a reallll heavily-trafficked app to actually hit a wall. (I haven't read enough about EB which is why I asked the question but I think it is auto-scaling)
Again, maybe not as cost effective as dedicated but I think at this point it may be a good compromise between the two while the container community works out some deployment hurdles.
AWS micro instances are heavily throttled CPU wise, and can only burst for extremely short periods of time. RDS can take upwards of 5-10 minutes to come back after you've changed the database instance type and restarted.
We use Elastic Beanstalk + RDS in a production environment. Its okay, but expensive and the performance is lackluster. We'll be moving to physical hardware shortly.
We use Elastic Beanstalk + RDS in a production environment. Its okay, but expensive and the performance is lackluster. We'll be moving to physical hardware shortly.
How is the performance relative to Heroku though? I have a lot of terrible, inexplicable problems with Heroku (random huge amounts of request queue-ing even at times when our site is below normal load).
I think these are all "noisy neighbor" issues and I would gladly leapfrog up from one host to another so long as the process isn't much more complicated and the performance is more reliable.
I think these are all "noisy neighbor" issues and I would gladly leapfrog up from one host to another so long as the process isn't much more complicated and the performance is more reliable.
Can somebody tell me the difference between using this and, say, a normal http-server+virtualenv+database set up?
Containers are easier to deploy when you have more than a couple of servers, they provide better separation between services, are simpler to move, and you can have the same containers in testing as you will later use in production. All that without the performance penalty of virtualization.
I haven't used dokku and don't know what it specifically adds.
I haven't used dokku and don't know what it specifically adds.
Dokku lets you push apps to your docker server through git,
and sets up a subdomain to point to that container.
Just read a few paragraphs on Dokku and Docker to get an idea. He has included these convenient things called "hyperlinks" for those topics in the article. Those solutions aren't particular to Python, for starters.
If you're looking for a private Heroku that's multi-host, check out http://deis.io/. We are about to announce our 0.3 release which features team support (e.g. deis sharing:add <user>)
I use this myself to host my website. I've forked it and added buildpacks for Jekyll and Octopress (one of the recent commits broke Octopress) for anyone who's interested and although I haven't cleaned it up enough to submit a pull request, it works perfectly. May take a look at sending one over the holidays
Octopress bare repo: https://github.com/rodeva/octopress-dokku-bare
Dokku fork for Jekyll and Octopress: https://github.com/rodeva/dokku
Octopress bare repo: https://github.com/rodeva/octopress-dokku-bare
Dokku fork for Jekyll and Octopress: https://github.com/rodeva/dokku
I used this (dokku on DigitalOcean as described) in production for several months for NodeJS - unfortunately some of the containers crashed every now and then and did NOT restart - a manual intervention was necessary. It does, however, work perfectly for PHP & Ruby. And if you know a bit of nginx-config-magic, you can even use multiple domains on the system :)
If you have already used Chef, Puppet or something else to automate your deployment, you probably don't need this.
CAAS (Container As A Service !!)
http://blog.copper.io/stackdock-blazing-fast-docker-as-a-ser...
Ah, this is cool. I really hope something like this grows/stabilizes and becomes the de-facto for web.
I think it takes 2 things... 1. Simple deploy of languages/services. 2. Scalability solutions (processing power / RAM / network interactivity).
I bet #1 is possible here, #2 seems less clear to me. any knowledge off the top of your head?
I think it takes 2 things... 1. Simple deploy of languages/services. 2. Scalability solutions (processing power / RAM / network interactivity).
I bet #1 is possible here, #2 seems less clear to me. any knowledge off the top of your head?
Digital Ocean comes with an option to build dokku on creation
Mini-Heroku for $5/Month and many hours of update the system, find errors, analyse logs, ...
For a small test system ok / or hobby project, but not for a productive usage.
For a small test system ok / or hobby project, but not for a productive usage.
It really depends how you set it up, though-- for example, Digital Ocean provides their own image (http://www.andrewmunsell.com/blog/dokku-tutorial-digital-oce...) that provides a one-click deployment of Dokku, including all of the SSH key setup and stuff. Minimally, this makes it easier to start up a new Dokku instance on a new version and push your apps to the new instance before you destroy the old one. In my experience, Dokku has been fairly easy to use (minus a weird Nginx related issue I had that was a side effect of the length of my app names).
Docker (as well as Dokku) still aren't 1.0 or deemed production ready by their respective authors, so you still should always investigate both products before using them. But it is really cool to see products like Dokku and Flynn being created and maintained, since it makes deploying apps so much easier.
Docker (as well as Dokku) still aren't 1.0 or deemed production ready by their respective authors, so you still should always investigate both products before using them. But it is really cool to see products like Dokku and Flynn being created and maintained, since it makes deploying apps so much easier.
[deleted]
not that I have tried, but I was always wondering how Cloud66 compares https://www.cloud66.com/
Cloud66 is Rails-only, whereas Dokku can use Heroku style buildpacks for any language of combination of processes.
Bla
I am a long-time non-web developer who has been doing a Rails side-project for the past year or so. I was using Heroku for free hosting, which was a breeze when I came across the first of these "$5 Heroku" posts (I have seen at least 5 or 6 prior to this one). Since then I've followed at least 5 different tutorials from start to finish trying to get Dokku up on DigitalOcean. So far, no successes.
Now, this is largely my fault (I'm a beginner in this realm), but I also think the technology is not as mature as a "mini-Heroku" would suggest. Part of the big ease of Heroku is, that you don't have to create Heroku before you use it.