Hacker News Reader

Comment by rsanders | Hacker News Reader

This is excellent news. I have a rather complicated app which I fought tooth and nail to get working on Elastic Beanstalk. The provisioning scripts were just too buggy, undocumented, and full of bad assumptions.

I have a couple of apps running perfectly under EB. This neatly solves my main issue with it.

View on HN

I would be interested in the details with regards to problems you had. I deploy a java/tomcat application to Elastic Beanstalk, and haven't had any issues, going so far as to heavily modify the environment using .ebextensions scripts to replace apache configurations, install additional packages, etc.

My Clojure app originally written to run on EB worked with no issues. The problem was with an old, sprawling "monorail" Rails app that needed a very specific system configuration, including running a daemon or two in addition to the web app itself. I can't remember all the individual issues, but the .ebextensions directory was getting pretty big and complicated.

I finally gave up when I ran into bugs in the Rails provisioning scripts that only appeared on initial deploy (or re-deploy; I forget). I had to patch and overwrite them, which was very brittle, and it was just easier to use Chef to spin custom AMIs exactly as I wanted them.

Having Docker be the common "configure a system to your app's needs" mechanism shields me from all these details about how EB works, and that's exactly what was needed.

That's fair. Thanks for the details.

I'm still looking for a way to deploy with Elastic Beanstalk without causing a brief interruption in service. It seems like a major oversight in the system it provides.

I know you can do the CNAME swap trick, but that cause monitoring issues due to essentially switching between groups of servers, plus you have to run twice as many servers.

Since you've had some experience with advanced configuration of EB apps, have you run into any convenient trick for doing this?

I agree this is the EB's biggest missing feature. I do it by having a second environment running the same web app. Before deploying I add nodes from this 'reserve' env to the ELB of the main env, and remove all the nodes-to-be-deployed from the main load balancer. Then I deploy the app. When deploy is complete and prod nodes are ready I add them back to the ELB and remove the reserve nodes. The deployment is seamless but this is not a convenient trick - it required a fair bit of custom scripting... Luckily AWS provides great APIs to make all this stuff possible.

Elastic Beanstalk does have rolling updates, but unfortunately its for environment changes, not application version changes.

Our developers are fond of the Elastic Beanstalk interface; to switch between app versions without end-user disruption, I have logic that directly manipulates instance state and uses connection draining (both ELB functions) to cycle new clients to the fresh cluster while not disrupting existing clients.

We don't run twice as many servers; before we switch between groups of servers, we scale up the destination cluster, and after the switch scale down the stale cluster with the old app version (2 is the minimum for load balanced applications unfortunately).

My email is in my profile; feel free to get in touch, I'd be happy to answer any questions you may have.

my .ebextensions script just calls chef-client, which is pretty straightforward to maintain.. Downside is that it takes many minutes for a new node to come up. Sounds like docker might help speed this up.

Reply on news.ycombinator.com