Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

holovaty.com

Post reply on HN
Print view View original

211–220 of 231 posts

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

#211

Post by bsaul »

memset wrote: 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…

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.

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

#212

Post by bsaul »

scottvdp wrote: post #63
memset wrote: 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…

Huge fan of salt stack, and I may push Adrian in that direction. The changes we made here were minimal in the way he deploys, and with so many architecture changes behind the scenes, we decided less is more on that front.

any link on the advantage of using saltstack for aws instead of AMIs ?

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

#216

Post by moreentropy »

rvanniekerk wrote: post #197

Not sure how I feel about these "Being a sys-admin is hard, I'd rather not do it" type posts. This is literally THE CORE OF YOUR COMPANY, your site not working is inexcusable! I think this is going to be an emerging problem for many startups these days. Patterns of completely unstable products because "ops is hard LOL" followed by a desperate attempt to hire actual sysadmins for their company and excuse after excuse…

This. If you don't want to and/or are unable to properly operate your systems, please stay on Heroko, AppEngine etc., otherwise this is a disaster waiting to happen.

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

#217

Post by 23david »

StavrosK wrote: post #162
mpdehaan2 wrote: post #136

Earlier quoted context omitted.

If you are looking for another general purpose orchestrator, I'd suggest taking a look at Ansible - http://ansible.cc/ Disclaimer: I am the primary author.

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.

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

#218

Post by 23david »

bsaul wrote: post #211
memset wrote: 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…

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 format that can be immediately used in a vagrant instance or elsewhere, so you need to convert between AMI and .vbox or .box formats to use amis with your local vagrant instance.

With saltstack, you can deploy and configure machines from base Ubuntu or RHEL distros by using salty-vagrant for vagrant instances and salt-cloud for AWS / rackspace / openstack / vps machines. Once machines are deployed and connected to your salt-master, you can use your yaml config files to bring all the machines to the desired roles (api machine, load balancer, web front-end, etc.). This is more flexible than using AMIs, since you can roll out a minor change quickly to all servers, including production servers, without needing to wait to build a new AMI.

There are hybrid approaches also (some puppet/chef users do this) where for production machines you can have saltstack deploy to a machine that then gets built into a new AMI automatically. And then this new AMI gets updated into the autoscaling groups and is deployed to replace the current production servers. Sounds complicated... and it is, but at the cost of extra complexity it does give you the best of both worlds.

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

#219

Post by 23david »

mpdehaan2 wrote: post #136
23david wrote: post #122

Earlier quoted context omitted.

FWIW, I tested juju a few months ago and found it to be buggy and unreliable. Sometimes the instances would connect together correctly, and sometimes they would fail inexplicably. Didn't seem ready for any kind of production use to replace config mgmt tools.

If you are looking for another general purpose orchestrator, I'd suggest taking a look at Ansible - http://ansible.cc/ Disclaimer: I am the primary author.

I never thought of Ansible for orchestration particularly, but that sounds interesting! The current orchestration support in saltstack is somewhat limited, so it would be neat to check out.

Are people using Ansible to replace or manage fabric scripts? I'd like to figure out some way to limit the spread of one-off fabric scripts (reminds me too much of bash script proliferation) and it'd be great to get everything under one roof.

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

#220

Post by scott_w »

bsaul wrote: post #212
scottvdp wrote: post #63

Earlier quoted context omitted.

Huge fan of salt stack, and I may push Adrian in that direction. The changes we made here were minimal in the way he deploys, and with so many architecture changes behind the scenes, we decided less is more on that front.

any link on the advantage of using saltstack for aws instead of AMIs ?

Salt is more easily repeatable across heterogeneous environments.

For example, we're using Salt to manage our development, testing, staging and production environments. We couldn't do this with AMIs, since the environments are quite different.

It makes updating quite easy, as you don't need to create a new AMI, just push your update to your release branch, then run state.highstate from your Master.

If you configuration changes, you update the master and then you can push that change across all (or just one) of your environments.

Post reply on HN