Ansible Strategy?

Archives Ansible Project
1

I’m trying to figure out exactly how to put ansible into my overall job of maintaining servers. I’m getting pretty comfortable with ansible by itself, but I want to run this by the list so folks can point out where I’m being stupid.

My goal is to be able to create servers that match existing servers on demand. Say, our web team wants a temporary dev environment that matches our production web server environment. Here’s how I envision the cycle:

  • Use ansible to gather information about the production server (this is done in advance) sufficient to create a clone. This includes making kickstart snippets for cobbler or equivalent.
  • Use cobbler to create base install of OS on a virtual machine.
  • Use ansible to add packages, configs, users etc…
  • Use a backup/rsync/database-replication etc… to copy bulk user-data
  • Test (nagios? jenkins? ???)

I’m making headway on gathering information about a server I might want to copy. I’m basically just running “shell: something > /tmp/something” and then using fetch followed by a local play to convert the fetched something into yaml I can later use as a vars file. I’ve got rpm list, pvs, vgs and pvs so far. I can also use ansible to organize that information and

Using cobbler seems pretty straight-forward so far. I have VMs popping up and down happily.

Using ansible to add packages & configs looks again, pretty straight forward if I already know what I want them to look like. I imagine low-low level stuff, like the disk layout and networking will be gathered from the existing server. The configurations of actively configured servers, like apache and sshd, will be managed in ansible with templates, so I don’t so much need to scrape a config out of an existing server, as it should already be there.

User /home dirs & other user data will be copied over in bulk. I currently use rsync & db replication for that.

Testing is an interesting question. A clone can’t be an exact copy or it will collide with the thing it’s a clone of. So, testing that server B actually acts like server A is mostly going to involve writing tests for things I know have failed. (The Host header in an HTTP request is my friend!). Anyway, that’s not really an ansible thing, though ansible could be used as a tool within those tests.

Once a server is running, ansible can keep the managed configs and various other things correct. The hard part is defining what is correct.

Again, I’m not really asking a specific question so much as laying out my understanding of how things should work so someone can bonk me on the head if I’m being stupid. If you read this and think “So, whats your question?” then great, thank you for your time. If you read this and think “No! You idiot, ansible already does XXXX” then you’re the one I want to hear from.

Thanks
-Dylan

2

I'm trying to figure out exactly how to put ansible into my overall job of
maintaining servers. I'm getting pretty comfortable with ansible by itself,
but I want to run this by the list so folks can point out where I'm being
stupid.

My goal is to be able to create servers that match existing servers on
demand. Say, our web team wants a temporary dev environment that matches
our production web server environment. Here's how I envision the cycle:

- Use ansible to gather information about the production server (this is
done in advance) sufficient to create a clone. This includes making
kickstart snippets for cobbler or equivalent.

Hmm, ansible doesn't really do this. You could write a module or a
script to use it to more or less do this though.

(I think someone earlier suggested it would be cool if someone wrote a
blueprint module for ansible like it has for puppet/chef -- and I
agree! Someone do that!)

It would generate somewhat suboptimal configurations, but it would be
a fair starting point.

Me, I'd be inclined to just think about what aspects you really want
to manage and start your playbook from scratch, since it's going to be
pretty small anyway (hopefully) and that gives you a chance to think
about what /should/ be on the server and what just happens to be
there.

- Use cobbler to create base install of OS on a virtual machine.
- Use ansible to add packages, configs, users etc..

Minimal OS deployed with Cobbler/other + ansible over the top is
definitely the way to go here.

- Use a backup/rsync/database-replication etc... to copy bulk user-data
- Test (nagios? jenkins? ???)

I'm making headway on gathering information about a server I might want to
copy. I'm basically just running "shell: something > /tmp/something" and
then using fetch followed by a local play to convert the fetched something
into yaml I can later use as a vars file. I've got rpm list, pvs, vgs and
pvs so far. I can also use ansible to organize that information

Using cobbler seems pretty straight-forward so far. I have VMs popping up
and down happily.

Using ansible to add packages & configs looks again, pretty straight forward
if I already know what I want them to look like. I imagine low-low level
stuff, like the disk layout and networking will be gathered from the
existing server. The configurations of actively configured servers, like
apache and sshd, will be managed in ansible with templates, so I don't so
much need to scrape a config out of an existing server, as it should already
be there.

User /home dirs & other user data will be copied over in bulk. I currently
use rsync & db replication for that.

Ansible could kick this off with a "local_action: rsync ..." if you want...

Testing is an interesting question. A clone can't be an exact copy or it
will collide with the thing it's a clone of. So, testing that server B
actually acts like server A is mostly going to involve writing tests for
things I know have failed. (The Host header in an HTTP request is my
friend!). Anyway, that's not really an ansible thing, though ansible could
be used as a tool within those tests.

Up to you, I guess. I'd just set up a machine in a stage environment
and test it with your usual collection of tests/monitoring thingies?

There are some here that have some CI setups that may want to chime in.

3

To 'clone' installed packages, it would be easy to have rpm/apt/yum/etc
list them, put them into a registered variable and then deploy them.

Configs get trickier, not only do you need to detect if they changed from
the default installation (most package managers let you verify it) but you
also need to know if that change is host/ip dependent.