Application Code Deployments with Aminator

130 views
Skip to first unread message

Ross McFarlane

unread,
Jul 11, 2013, 5:32:30 AM7/11/13
to amin...@googlegroups.com
Hi,

I'm interested to know if/how Netflix uses Aminator for application code deployments. Are you baking new AMIs for every code change to the application, or just for changes to the OS/language/libraries/tools?

If you're deploying application code changes as new AMIs, how do you handle the rollout across a cluster (I'm assuming one box on, one box off)?

If you're deploying application code separately, how do you bootstrap an autoscaled instance with application code?

Thanks,
Ross

Justin Ryan

unread,
Jul 11, 2013, 10:57:07 PM7/11/13
to amin...@googlegroups.com
Yes, Netflix bakes new AMIs for each code change. It first starts by building up a base, called the BaseAMI, and then each app is layered onto that base. As far as deployment goes, we typically use Asgard (https://github.com/Netflix/asgard) for deployments. Joe Sondow has talked extensively about how Asgard is used at Netflix, you should be able to find one of his talks on YouTube. But to your point, we're deploying to AWS, so we can spin up a new "cluster" (actually an ASG) for each new AMI we need, and then we spin down the old one when we're done testing the new one. We call this a Red-Black push. What happens to the "boxes" isn't our concern, #cloudftw.

Ross McFarlane

unread,
Jul 15, 2013, 4:12:15 AM7/15/13
to amin...@googlegroups.com
Thanks Justin,

That's really interesting. We'd toyed with the idea of baking code into the AMI, but expected it to be too slow. Is the process you describe fast enough for you to use in dev/test environments, too?

Thanks,
Ross

Justin Ryan

unread,
Jul 15, 2013, 5:35:05 PM7/15/13
to Ross McFarlane, amin...@googlegroups.com
To each his own, it truly depends on what your testing strategy is.  For us, most everything is already in the base, so overlaying a .war file isn't a lot more work and doesn't take more than 5 minutes.  Once you start thinking about the AMI as a build artifact, it feels irresponsible to not package it up. It'd be like saying that compiling and zipping up .class files (making a .jar) isn't worth the trouble, "we'll just let the target environment figure it all out". Someone has to copy the .war around and set up the image, might as well do it up front in a reproducible way.


--
You received this message because you are subscribed to a topic in the Google Groups "Aminator" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aminator/UfpQMrAOeAg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to aminator+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Ross McFarlane

unread,
Jul 16, 2013, 4:04:14 AM7/16/13
to amin...@googlegroups.com, Ross McFarlane
Thanks Justin,

That's pretty quick! We're a PHP shop, mostly, so I suppose we're a bit lazy about 'builds' at the moment, but this sounds like a really tidy way to go.

Once we've figured out how to get dynamic config to those boxes (I'm looking at archaius now) then we'll be sorted.

Thanks again,
Ross
Reply all
Reply to author
Forward
0 new messages