ansible-playbook — run an ansible playbook
Ansible playbooks are a configuration and multinode deployment system. Ansible-playbook is the tool +
ansible-playbook — run an ansible playbook
Ansible playbooks are a configuration and multinode deployment system. Ansible-playbook is the tool used to run them. See the project home page (link below) for more information.
ansible — run a command somewhere else
Ansible is an extra-simple tool/framework/API for doing 'remote things' over +
ansible — run a command somewhere else
Ansible ships with a number of modules that can be executed directly -on remote hosts or through ansible playbooks.
-Nearly all modules take key=value parameters, space delimited. Some modules take -no parameters, and the command/shell modules simply take the string +
Ansible ships with a number of modules (called the ‘module library’) +that can be executed directly on remote hosts or through Playbooks. +Users can also write their own modules. These modules can control system +resources, like services, packages, or files (anything really), or +handle executing system commands.
+Let’s review how we execute three different modules from the command line:
+ansible webservers -m service -a "name=httpd state=running"
+ansible webservers -m ping
+ansible webservers -m command -a "/sbin/reboot -t now"
+Each module supports taking arguments. Nearly all modules take key=value +arguments, space delimited. Some modules take +no arguments, and the command/shell modules simply take the string of the command you want to run.
-All modules return JSON format data, though if you are using the +
From playbooks, Ansible modules are executed in a very similar way:
+- name: reboot the servers
+ action: command /sbin/reboot -t now
+All modules technically return JSON format data, though if you are using the command line or playbooks, you don’t really need to know much about -that.
-Most modules other than command are idempotent, meaning they will seek -to avoid changes unless a change needs to be made. When using ansible -playbooks, these modules can trigger change events. Unless otherwise -noted, all modules support change hooks.
-Stock modules:
+that. If you’re writing your own module, you care, and this means you do +not have to write modules in any particular language – you get tho choose. +Most modules other than command are idempotent, meaning they will seek +to avoid changes to the system unless a change needs to be made. When using ansible +playbooks, these modules can trigger ‘change events’. Unless otherwise +noted, any given module does support change hooks.
+Let’s see what’s available in the Ansible module library, out of the box:
The command module takes the command name followed by a list of diff --git a/patterns.html b/patterns.html index aa9282deef..e76a748f5a 100644 --- a/patterns.html +++ b/patterns.html @@ -157,13 +157,12 @@ s.parentNode.insertBefore(ga, s);
How to define and select hosts you wish to manage
-Ansible works against multiple systems in your infrastructure at the same time. It does this by selecting portions of systems listed in -Ansible’s inventory file, which defaults to /etc/ansible/hosts, and -looks like this:
+Ansible’s inventory file, which defaults to /etc/ansible/hosts. +The format for /etc/ansible/hosts looks like this:
mail.example.com
[webservers]
@@ -181,7 +180,16 @@ but they are useful.
These patterns target all hosts in the inventory file:
+We’ll go over how to use the command line in Command Line Examples section, however, basically it looks like this:
+ansible <pattern_goes_here> -m <module_name> -a <arguments>
+Such as:
+++ansible <pattern_goes_here> -m service -a “name=httpd state=running”
Within Playbooks, these patterns can also be used, for even greater purposes.
+Anyway, to use Ansible, you’ll first need to know how to tell Ansible which hosts in your inventory file to talk to. +This is done by designating particular host names or groups of hosts.
+The following patterns target all hosts in the inventory file:
all
*