[falcolas]

My tip number 0: Use a CMS. It's a beautiful thing to start an ec2 instance, run Ansible, get a drink of water, and return to a fully provisioned and configured machine.

Tip 0.1: Use Vagrant with an EC2 box, and just 'vagrant up' yourself a fully operational machine.

[Sssnake]

Why are people so thrilled about a slower more error prone way to do what amazon provides already? Just make an ami for each kind of server you want. Now you skip the waiting part, and the "oops, my pile of messy ruby scripts fucked up configuring the server" parts.

[ceejayoz]

You can use Ansible to create an AMI to get the best of both worlds - fast provisioning, plus the ability to make new AMIs in a repeatable, self-documenting manner. You're arguing configuration management is "error prone", but I've found it a lot less error prone than other methods. If something doesn't install right I can blow away the whole thing rather than trying to un-break a destroyed install.

If your Ansible scripts are in Ruby you've done something very odd, and if they're messy it's your own fault. Mine are pretty clean, and once built they work the same way for subsequent runs.

[Sssnake]

>If your Ansible scripts are in Ruby

The popular options are in ruby. Just because you use a less popular one that is written in python doesn't change the main point.

[ceejayoz]

Ansible itself is Python, and the docs all use Python examples. I've yet to come across a Ruby one...

[Sssnake]

Why are you replying if you can't be bothered to read?

[ceejayoz]

The post you replied to was about Ansible (which is pretty popular).

If you're intending to bash Puppet/Chef, why are you doing it in response to someone mentioning how handy Ansible is?

[falcolas]

How do you create that initial AMI? CMs make answering that question simple.

AMIs are nice - but they're merely snapshots of an end product. Being able to get to that end product in a repeatable, idempotant and self-documenting fashion is just as nice.

So is being able to create a virtual image on your own machine with the same end product.

FWIW, Vagrant lets you specify an AMI in its box description, so you get the best of both of your worlds there.

[Sssnake]

>How do you create that initial AMI? CMs make answering that question simple.

No, they make it slower and more complex. The idea being that after you have built a config, future clones will be easier. But you already get a better solution just setting up a server and then making an AMI from it. Cfengine and friends offer quite literally zero benefits for this sort of scenario.

[falcolas]

You missed two points. How did you create that first image? Exactly what versions of packages, packages, configurations, etc were installed? Being unable to answer that question will hurt you more in the long run than you might expect.

Second, if you should move from AWS to (as an example of a second popular PAAS provider) Rackspace, how do you recreate that image? If you want to create a local VM to perform development on, how do you do that?

Now, if I were limited to just using one CMS, I might agree with you. There are some really obtuse ones out there that require a lot of learning. I don't think Ansible falls into this category. You're not writing python, you're not writing in some tool specific DSL, you're writing lists of packages, to be installed in-order. Simple and straightforward.

    - yum: name=nginx

Versus

    sudo yum -y install nginx

[Sssnake]

I didn't miss any points. Every package manager can accept a list of packages. You missed learning the most basic fundamentals of your OS. And once again, the specific tool does not matter. They all do the same thing, and they all do it in an error prone and ill-conceived way. Hell, nix is a better "CM" tool than the real ones, and it is just a package manager.