6 ms·

While I love the idea of Dokku (and Flynn), I would warn those who have little to no dev-ops experience that this is not quite (yet) the silver bullet that it s

by kohanz 13y ago

While I love the idea of Dokku (and Flynn), I would warn those who have little to no dev-ops experience that this is not quite (yet) the silver bullet that it sometimes is marketed as. 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.

andrewmunsell 13y ago
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-ocean http://www.andrewmunsell.com/blog/dokku-tutorial-digital-oce...
- ochoseis 13y ago
  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/165, https://github.com/progrium/dokku/issues/202 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).
migrantgeek 13y ago
>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
lazerwalker 13y ago
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.
frio 13y ago
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 :).

by kohanz 13y ago

andrewmunsell 13y ago

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-ocean http://www.andrewmunsell.com/blog/dokku-tutorial-digital-oce...

ochoseis 13y ago
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/165, https://github.com/progrium/dokku/issues/202 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).

migrantgeek 13y ago

>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

lazerwalker 13y ago

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.

frio 13y ago

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 :).