Live data from Hacker News

Why I left Heroku, and notes on my new AWS setup

holovaty.com

221–230 of 231 posts

Re: Why I left Heroku, and notes on my new AWS setup

#221

Earlier quoted context omitted.

I have tried ansible and love it. I invested the time (a few hours) to get a script working for my stack, and now I have a 70ish line script that will provision a server or VM (with a shared code directory in the VM), from clean installation to the codebase up and running in its production state, in one command. New project? I just copy the script, change a few variables (names and packages it needs), and I get deplo…

Sounds interesting. Any possibility that you could anonymize the script and paste a link to a gist of it? would be interesting to see some real-world Ansible examples.

Sure: http://pastebin.com/KPrm3Zky

It could use variables a bit more, I think, but there were a few bugs with expanding them, so I didn't use them. I'll fix them later on, though.

Re: Why I left Heroku, and notes on my new AWS setup

#222
post #57

This really resonates with me. I have been having identical issues with Dotcloud, a Heroku competitor. There's nothing worse than wondering if deploying your stupid one-character typo fix will hang or leave the app in an incomplete state. I myself am working on setting up salt stack for deployments. I like that all of it is in python, and after a couple of days I've begun to make progress. I am migrating things slowl…

[deleted]

Re: Why I left Heroku, and notes on my new AWS setup

#223
post #141

We're working on solving these sorts of devops problems in Ubuntu with Juju: https://juju.ubuntu.com/ As an alternative approach would be that a Juju charm (script) would handle the initial deployment of a stock Ubuntu AMI and the customization in one step (or with puppet/chef) and then allow you to add new instances based on scale (though currently not automatic). When you have changes to your service you update the…

I would really love to recommend Juju. I used it for a good couple months attempting to get even just a working Openstack deployment. The trouble is that for the bare-metal functionality you guys mean it to be paired with MaaS. Unfortunately the community I found to exist around this combination was basically zero. Even a simple question went unanswered the couple times I posted it. Eventually I gave up and just went…

This was exactly my experience as well. Then I was introduced to Mirantis Fuel which uses Cobbler/Puppet to do bare metal provisioning and remote configuration.

Re: Why I left Heroku, and notes on my new AWS setup

#224
post #223
post #141

Earlier quoted context omitted.

I would really love to recommend Juju. I used it for a good couple months attempting to get even just a working Openstack deployment. The trouble is that for the bare-metal functionality you guys mean it to be paired with MaaS. Unfortunately the community I found to exist around this combination was basically zero. Even a simple question went unanswered the couple times I posted it. Eventually I gave up and just went…

This was exactly my experience as well. Then I was introduced to Mirantis Fuel which uses Cobbler/Puppet to do bare metal provisioning and remote configuration.

Very cool. I looked at the Fuel stuff as well, but at the time it wasn't quite able to do everything I needed so I ended up rolling my own. The 2.2 update they have coming up soon sounds like it fixes all of the things that were 'wrong' for me though!

Re: Why I left Heroku, and notes on my new AWS setup

#225
post #211

Earlier quoted context omitted.

i'm starting a process to deploy on aws, and i just finished creating my salt stack conf for a vagrant VM ( as a warm up). After reading the post i was in the process of ditching that for a simpler AMI-based deployment. Could you elaborate on why salt stack is better than custom AMIs ? also if you have any link explaining how to deploy to ec2 using saltstack, that would be awesome.

AMIs are really useful for production servers when you want to quickly launch a bunch of similar servers or set up auto-scaling groups to launch new servers based on load. The issue is that to take full advantage of using AMIs, you need to re-build (bake) the AMI every time you make a change to your production machines. Disadvantages of AMIs are that they are large files (which can be unwieldy) and are not in a forma…

Thanks, Sounds like the last option seems the best indeed. My salt configuration is way too slow to build to be used in an autoscaling scenario, that's one reason why AMI seemed suitable to me, but that last combination you mentioned (which i didn't know was possible) looks great.

Thanks again

Re: Why I left Heroku, and notes on my new AWS setup

#226

Earlier quoted context omitted.

Sounds interesting. Any possibility that you could anonymize the script and paste a link to a gist of it? would be interesting to see some real-world Ansible examples.

Sure: http://pastebin.com/KPrm3Zky It could use variables a bit more, I think, but there were a few bugs with expanding them, so I didn't use them. I'll fix them later on, though.

amazing. that example explains how it works better than 200 pages of documentation :-)

thx!

Re: Why I left Heroku, and notes on my new AWS setup

#227

Earlier quoted context omitted.

Sounds great. where do I sign up? :-)

Mail me? We should just arrange the next HN meetup ourselves. We can probably pick a better venue than the last one I went to here. :)

Email sent (earlier today).

Re: Why I left Heroku, and notes on my new AWS setup

#228

Earlier quoted context omitted.

Sure: http://pastebin.com/KPrm3Zky It could use variables a bit more, I think, but there were a few bugs with expanding them, so I didn't use them. I'll fix them later on, though.

amazing. that example explains how it works better than 200 pages of documentation :-) thx!

You're welcome, examples are pretty useful for this sort of thing. Plus, after you have a base to work off, it's trivial to extend.

I'll put this up in a post on my blog, maybe it'll help others as well.

Re: Why I left Heroku, and notes on my new AWS setup

#229

On my end I get a complete crash once a week when running with one dyno. The official response for support I got was to upgrade to two dynos. Apart from the PostgreSQL hosting, I'm not really happy with Heroku. Add to the random deploy breakage I've experienced mid-launch (not to mention it's slow as hell), I'm going to move back to my own servers.

Heroku docs do say (and I'm afraid the link to it is escaping me) that if you run only 1 dyno, it will shut down after something like 6 hours of inactivity. So if no one hits your site for 6 hours, the next time someone does it has to boot the dyno up again, which can take enough time for the request to time out. Not saying this is a great policy, just explaining in case you weren't sure. When you go to 2 dynos they…

I think it is much less than 6 hours. Like 30 mins or so.

Re: Why I left Heroku, and notes on my new AWS setup

#230
post #144

I love Heroku: git deployment, the "dyno" abstraction, Procfiles, buildpacks, putting configuration in environment variables (all the 12 Factor App stuff: http://www.12factor.net/ ). Is there an open source implementation of Heroku (close to 100% compatible, not just similar ideas) that runs on your own cloud?

Clone of Heroku? None I'm aware of. A bring-your-own PaaS? Many. I work with Cloudify myself: http://www.cloudifysource.org/ Nice things: It integrates with Chef/Puppet, allows built-in auto-scaling so it's cloud independent... has recipes for many applications and services ready to go: https://github.com/CloudifySource/cloudify-recipes Drawbacks in my mind are that it's based off of Groovy which may or may not be he…

You can also launch many of the popular frameworks such as MongoDB, Play Frameowrks etc online: http://www.cloudifysource.org/cloudifyRecipeCatalog.html
Post reply on HN