On 09/01/2015 11:25, Stefan G. Weichinger wrote: > Am 08.01.2015 um 19:29 schrieb Alan McKinnon: > >> The directory layout in the best practice page is indeed way more than >> you need, it lists most of the directories in common use across a wide >> array of deployments. In reality you create just the directories you need. >> >> Global stuff goes in the top level (like inventory). >> Variables for groups and individual hosts go into suitably named files >> inside group_vars and host_vars. >> Roles have a definite structure, in practice you'll use tasks/ and >> templates/ a lot, everything else only when you need them. >> >> This is a good design I feel. If a file describes variables, you don't >> have to tag it as such or explicitly include it anywhere. Instead, files >> inside a *vars/ directory contain variables, the system knows when to >> use them based on the name of the file. It's really stunningly obvious >> once you train your brain to stop thinking in terms of complexity :-) > > Thanks a lot ... I spent some time with it already and learn to like it ;) > > I am nearly done with setting up an inventory file for all the customer > boxes I am responsible for. Just using the ad-hoc-commands is very > useful already! > > For example I could store the output of the "setup" module for local > reference ... this gives me loads of basic information. > > I know it is not a backup program but I think I could also use it to > rsync all the /etc directories to my ansible host? Or trigger a "git > push" on the remote machines to let them push their configs up to some > central git-repo I provide here (having /etc and the @world-file is > quite a good start here and then ... ).
I think that is a perfectly valid approach, I just think of it slightly differently: I don't use it as a backup program, rather I think of it as a way to safely run the same command on multiple hosts. Whether you need to use git, trigger backups or add an arbitrary user doesn't matter, they are valid commands and ansible gives you a framework to run them safely on multiple hosts in parallel[1] And when you find yourself running the same ad-hoc command quite often, you can always fold it into a playbook proper > > It is also great to be able to check for let's say > shellshock-vulnerability by adding a playbook and running it to all/some > of the servers out there ... I am really starting to come up with lots > of ideas! > > My current use case will be more of an inventory to track all the boxes > ... deploying stuff out to them seems not so easy in my slightly > heterogeneous "zoo". But this can lead to a more standardized setup, sure. Indeed. it encourages a "cattle not pets" (google it) way of thinking. So your hosts may all be different, and you may end up with 10% more packages than you really need, but you do get a model you can keep in your head and be much more productive. And bill more hours :-) > > One question: > > As far as I see the hostname in the inventory does not have to be > unique? I have some firewalls out there without a proper FQDN, so there > are several "pfsense" lines in various groups (I have now groups in > there with the name of the [customer] and some of them have child groups > like [customer-sambas] ...). An inventory is just an .ini file, so duplicate entries don't really matter. IIRC later dupes just overwrite earlier ones. Internally, the inventory is treated as a bunch of key-value pairs and it's the key that ansible uses to name hosts it works with. The values tell it how to contact the host. What I do is list all my hosts at the top level of the inventory in some sensible order, and just list the names in groups below that (see the example below). If you don't explicitly provide an FQDN for a host, then ansible uses the name you gave it and tries to ssh to that name. The name can be something that resolves in DNS, something in /etc/hosts, or an IP address, just like using ssh (as it really is ssh doing the hard work under the hood) > I would like to be able to also access all the ipfires or sambas in > another group ... so I would have to list them again in that group > [ipfires] ? Yes. If the playbook says to run the play against a group, then you list each host in the group. You can also make groups of groups so it's quite easy to come up with a scheme that suits your setup. Here's a piece of my inventory to illustrate: # List all workstations here, including the ansible_* variables # Assign each host to the relevant groups below aadil-wks ansible_ssh_host=192.168.1.84 brandon-wks ansible_ssh_host=192.168.1.100 carmen-wks ansible_ssh_host=192.168.1.146 # List all servers here, including the ansible_* variables # Assign each host to the relevant groups below ppm-db-0 ansible_ssh_host=192.168.0.16 ppm-mail-0 ansible_ssh_host=192.168.0.14 ppm-preprod-0 ansible_ssh_host=192.168.0.12 ppm-www-0 ansible_ssh_host=192.168.0.20 [accounts-workstations] aadil-wks carmen-wks [support-workstations] brandon-wks [web-servers] ppm-www-0 [mysql-servers] ppm-db-0 [workstations:children] accounts-workstations support-workstations [servers:children] web-servers mysql-servers Basically, you call each host by any name that makes sense and group them how you want. It's the ansible_ssh_host attribute that tell ssh how to connect > > Thanks for the great hint to ansible, looking great so far! > Stefan [1] I used to use clusterssh for this, but I'm gradually shifting my headspace over to ansible ad-hoc commands. cssh is always impressive (fire off 30 xterms across 3 HD monitors, all thee newbies are terrified and your reputation in intact...) but ansible does remove a lot of noise from your vision -- Alan McKinnon alan.mckin...@gmail.com
