posted on 2017-04-29 10:20
You know how to use
ssh-copy-id so you can achieve your desired destination server of choice with passwordless keyauth for user root.
This is just for getting singe action run on single host or a group of hosts.
Some available modules:
Run a shell command remotely:
## run uptime on host(s) # -i: 'inventory', hostname or location of hosts file or a folder containing inventory files # -m: 'module', ansible part that does something, defa ansible -i HOSTNAME -m command -a uptime ansible -i HOSTNAME_1,HOSTNAME_2 -a uptime
## lets create a hosts file for less typing cd ~ mkdir ansible cd !$ echo " [hosts-group] HOSTNAME_1 HOSTNAME_2 " > hosts # update hosts packages ansible -i hosts -m date
Let's read the hosts file automatically be read and set explicitly some defaults. There's more to the hosts file like setting host/group-specific vars, groups-of-groups, but for now this will do.
echo " [defaults] host_key_checking = False ansible_ssh_user = root ansible_ssh_port = 22 ansible_connection = smart ansible_shell_type = sh hostfile = hosts " > ansible.cfg ansible hosts-group -a 'ip a' ansible all -m ping ## run on all hosts in the inventory file
-s does sudo, in case you'd want to work with a nonroot user.
All this can be done with bash, too, of course, except that you get some fancy output with colors and host grouping for free. But until now nothing really has changed. So why the fuss?
To better explain that, some more notation stuff:
And: Idempotence? The official definition from the manual's glossary: An operation is idempotent if the result of performing it once is exactly the same as the result of performing it repeatedly without any intervening actions.
But what is not expressed through this term, but what you get along the way compared to shell scripting?
while read i'ing that files consisting lists of hosts.)
Especially the last two points make any maintenance work a breeze. Either recreate a configuration on a new host through provisioning. Or just quickly read the task lists (grouping them properly helps for sure here), to get the idea what the system's purpose was/is. Keep the last bullet point in mind when creating and structuring playbooks, it really pays off in the end. If I don't forget, I will include a virtual banana for scale or something, this post series is going to end up a long one anyway.
posted on 2017-04-29 10:20
In the beginning there were shellscripts for provisioning. ('Go away or I will replace you with...')
Eventually highlevel language code appeared for this purpose. I did that myself with python, too reinventing the wheel, wrote some rather sophisticated wrappers in bash (shudder) for another project and have seen a nontrivial configuration management codebase in... PHP. I'm not kidding, that codebase still gives me the chills.
Due to the more or less obvious shortcomings with these methods, theoretically some proper configuration management tool, relieving one of the duty to really implement everything by hand while being readable, just had to arrive, especially with all these computers being everywhere nowadays.
From all the news and testimonals, puppet seemed to be the all-around best contender and thus lesser of all evils while being enterprisey enough.
... so you likely may up with ansible at last.
The fact that friends of mine jump through hoops with it at work in comparably big setups (and doing things with it in the process which the external specialized puppet consultants could not make do), also does not really inspire confidence. Mind you, they take the configuration management theme far, far more serious than I or my colleagues do. (The goal is single button presses for everything, from single hosts to complete clusters. The Litmus test wether the goal is achieved: You don't ssh onto the servers to do anything, but fix it in the configuration management's database. No more clustershell or for-looping across the fleets, no more manual work in the field. Same results, always, bla bla bla.)
And on the tool front, finally there's salt which a lot of people seem to dig, but ansible wins with simplicity, albeit being slower due to using ssh (salt has an encrypted rabbitmq as communication engine). But that hasn't been an issue with some several hundred servers so far, thanks to the ssh multiplexing.
But Salt basically needs a master due to being pull-based, but the push-based approach of ansible is good enough by far for provisioning with our workflow. Not every change has to go through ansible at our place (yet), and we just like having fewer moving parts.
On a last note, I really really really tried to dig (hoping even love) puppet, having had my doubts (scratch that, read: 'I still have') about ansible being the best tool available for our outlet, but I have looked too often at its documentation, just to end up finally in the sources to get whats happening. It doesn't matter that it is ruby instead of python (I am not one of THESE people), but It simply does not deliver, even after spending some considerable time with it. Sure, after a while you can even read all of its output pretty easily, but ansible's is just easier to read. You get up to speed rather easily, and until the ssh speed becomes the bottleneck, it will just do for now. May be that with 10.000s of servers this will change, lets see wether we will find out.
We've had our share with different ansible problems, too, of course (it's all software, after all). But all an all that went rather smoothly comparing the amounts of time we spent with fixing these. This included i.e. completely random bugs with extracting zipfiles and version incompatibilies, too, but all of them were resolved in an order of magnitude less pain and head-desk-banging happenings with puppet.
Dear future self, if considering puppet again, read this three times, thank you - and quit the stockholm syndrome bullshit.
posted on 2014-03-30 17:31:53
puppet is one of several open source configuration management tools.
A little excourse:
Notable alternatives would be Chef, Ansible, CFEngine, Salt and Sprinkle. In the Red Hat universe there exists Spacewalk, which also is built on puppet somehow according to wikipedia. A friend of mine considers Spacewalk a damn fine solution. Puppet seems to have an edge over its competition and is one of the bigger contestants along with Chef and CFEngine. Ansible and Salt are newer and likely better, Sprinkle is the smallest and most light-weight of the bunch. I haven't lookup up the current codebase sizes or commit activities which would indicate how lively each project is, this is as far as I came from searching blogs and test experiences.
As of end 2013 Ansible seems to be the most frictionless solution. Why is this about puppet then?
Puppet's unique selling points are
View posts from 2017-08, 2017-07, 2017-05, 2017-04, 2017-03, 2017-02, 2017-01, 2016-12, 2016-11, 2016-10, 2016-09, 2016-08, 2016-07, 2016-06, 2016-05, 2016-04, 2016-03, 2016-02, 2016-01, 2015-12, 2015-11, 2015-10, 2015-09, 2015-08, 2015-07, 2015-06, 2015-05, 2015-04, 2015-03, 2015-02, 2015-01, 2014-12, 2014-11, 2014-10, 2014-09, 2014-08, 2014-07, 2014-06, 2014-05, 2014-04, 2014-03, 2014-01, 2013-12, 2013-11, 2013-10