5 ms·
That's actually, honestly, a bad way to do it. It's fine to pre-load an instance with source and application/package dependencies. At this point though, you rea
by druiid 13y ago
That's actually, honestly, a bad way to do it. It's fine to pre-load an instance with source and application/package dependencies. At this point though, you really should be backing those up with it being deployed by Puppet/Chef.
Essentially you pre-run a puppet manifest and have it do all the first-run processing and then store THAT as the AMI/instance. This way you have an instance that only needs a few seconds to get itself ready while also integrating configuration management (which really you should be doing these days). Just some suggestions from a sysadmin.
- rschmitty 13y agoDepends on how fast you want new instances to be online. Sometimes you want to respond to demand very fast, it can take a few minutes for an instance to register with ELB, if you have to download/build/configure packages prior you are just adding minutes on time. The faster you can spin up instances the higher you can run your servers as you need to tell amazon at what threshold should I spawn more instances There are 3 general levels you can take with AMIs: 1) Vanilla instance AMI, have puppet/chef install everything for you, then fetch your app code and configure that 2) Use another tool to have your instance built with puppet/chef and then capture that into an AMI. Once it spins up it just needs to get your app code. Idea here is your services arent likely to need updated as fast as your app code. 3) Same as two, but when your production code is in release/maintenance mode, bake everything into an AMI. When you need to deploy new code, you need to create a new AMI, but you are creating an AMI with scripts so its no big deal :) All you have to do now is update your cloudformation
- druiid 13y agoWell this is why I suggested pre-running with Puppet and 'install' your code and dependencies into the AMI before saving it. That way you get the best of both worlds. Obviously if you have a setup with rapidly deployed code changes you'll want to have your puppet manifest grab the latest version before deploying live when spinning up a new instance.
- brown9-2 13y agoI believe #3 is what Netflix does.
- raylu 13y agoPuppet/Chef is overkill for a site running a config this simple.
- tlrobinson 13y agoWhat do you recommend for simple configurations where you still want the repeatability/documentation/versioning tools like Chef/Puppet provide? Shell scripts?
- mbaukes 13y agoscriptrock.com - FD: I'm one of the founders, we think of it as a executable documentation tool.
- shimms 13y agobabushka - http://babushka.me/ http://babushka.me/
- shykes 13y agoYou could build containers using Docker (http://docker.io http://docker.io) and Dockerfiles. Here's an example: https://github.com/steeve/docker-opencv https://github.com/steeve/docker-opencv
- druiid 13y agoI don't really agree with this. If you're defining a whole crazy master/agent relationship with Puppet then it's overkill for them, no doubt. There's a reason many Vagrant boxes I see use Puppet to instantiate though: It's friggin simple to get started with. More advanced configurations might even end up requiring you to build your own modules and extended manifests, but I expect this configuration detailed in the article would probably amount to a couple hundred lines for the entire manifest. I think this also underscores one of the things I like the most about Puppet (instead of Chef, which is a fine CM system as well); It's easy to get started with but powerful enough to get things done down the road. Honestly, there's never a better time to start working with Puppet than from the very beginning of a project!
- chaz 13y ago