Initializing new hosts

Hello all,

I’m curious what is now “state of the art” for Ansible with regard to bootstrapping or initializing new hosts?

…Something along the lines of these threads: first, second. Specifically, without necessarily considering distinctions of platform (ec2 vs. openvz vs. physical), I’m referring to a set of plays or roles that one would create to simply normalize new hosts before running deployment or configuration plays on them. These would handle items that you only want to do once, and which IMHO would get in the way pretty badly if you instead tried to add them as the opening of all your deployment and config plays (what I’ll call “normal” plays).

One of many examples of this would be that so many default Linux installers and VM images tend to include both apache and samba, but (all hypotheical here…) do you really want to add a task to the start of your webserver role to remove samba? or vice-versa? and should the dbserver role remove both packages? What if you have a single fileserver also running some sort of web-based file browser? or you need lamp for phpmyadmin on one dbserver? Are you then going to add an exception to the package removals for those certain hosts?

To me it seems much easier to have a play that removes both packages (and does any other pre-deploy tasks) that you only run once, and then just have the normal plays install what they need and go from there. I’ve seen a lot of one-off posts on this topic in searching the list, but is there any consensus or framework or fleshed out examples on how to get it done? I’m on the fifth iteration of my own attempt, which is slowly approaching “not entirely useless” and I’m wondering what else is out there. (I’ll have my own attempt posted soon and would certainly love any comments, but I see that whole exchange as a -mostly- separate issue from my question here.)

Thanks for reading,
Mark

Hi Mark,

Generally speaking plays rarely remove packages.

It’s much more common to use them for initial provisioning and then full lifecycle management, but then only remove a package when you know it got added in the past and explicitly needed to be gone.

The idea of a playbook to remove content is sketchy --and it is with any system – because you don’t know all the things that could be on there that you want to remove. Thus most people tend to not model things with regard to removal.