[TriLUG] Curious

Igor Partola igor at igorpartola.com
Mon Oct 27 09:52:35 EDT 2014


I should also mention that Puppet works really well for me when using AWS.
For example, I have a project where I might need to quickly add web
servers, but don't want them running all the time (classic cloud computing
use case). I have set up the existing web servers to use cloud-init to
download the Puppet manifests from the private GitHub repository, then run
them locally. Because Puppet is slow, it takes a while for the server to
come up, but once it does, I know that it's the correct configuration.
After it's done, cloud-init uses the AWS API + bash script to register it
with the load balancer. I am not using puppet-master for this since I don't
want to much around with registering keys, etc.

One debate I keep having with people is whether it makes sense to use
Puppet or bake an EC2 instance image and just keep spinning up machines
based on that. I detest the pre-built image solution for a few reasons.
First, you have to reinvent a part of what Puppet already does for you. For
example, if you want a service that listens on a specific IP address, you
now have to create a script that will update the configuration file.

Second, software updates are a pain. Say, you built an image pre-Hearbleed,
or pre-shellshock. Now you have to rebuild it in a hurry. And what if the
vulnerability is not as widely publicized? Simply running normal updates on
your servers is a nice scriptable task. Re-building and re-testing all
images is a huge pain, comparatively.

Finally, pre-built images lock you into EC2. I am not saying that it's EC2
vs Rackspace vs whoever, but for me it's EC2 vs Vagrant (for local
development). It's a huge deal to run a server in a VM on my laptop, then
push the code to and identically configured server on EC2. Puppet ensures
that the two are in fact identical.

Igor


More information about the TriLUG mailing list