@@ -587,7 +589,7 @@ logs from ansible-pull runs would be an excellent way to gather and analyze remo
it later. Use of the command module in this way can in many ways eliminate the need to write site specific facts, for
instance, you could test for the existance of a particular program.</p>
<p>The ‘register’ keyword decides what variable to save a result in. The resulting variables can be used in templates, action lines, or only_if statements. It looks like this (in an obviously trivial example):</p>
<divclass="highlight-python"><pre>- name: test playbook
<divclass="highlight-python"><pre>- name: test play
hosts: all
tasks:
...
...
@@ -599,6 +601,45 @@ instance, you could test for the existance of a particular program.</p>
@@ -7,7 +7,7 @@ and command execution framework. Other tools in this space have been too compli
require too much bootstrapping, and have too much learning curve. By comparison, Ansible is dead simple
and painless to extend. Puppet and Chef have about 60k lines of code. Ansible's core is a little over 2000 lines.
Ansible isn't just for configuration management -- it's also great for ad-hoc tasks, quickly firing off commands against nodes, and it excels at complex multi-tier deployment tasks, being designed for that purpose from day one.
Ansible isn't just for configuration management -- it's also great for ad-hoc tasks, quickly firing off commands against nodes, and it excels at complex multi-tier deployment tasks, being designed for that purpose from day one.
Systems management doesn't have to be complicated. We've learned well from the "Infrastructure is Code" movement.
Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project -- bugs, complexity, and overhead. Infrastructure configurations should be simple, easy to develop, and easy to audit. This is Ansible's philosophy and the main reason it's different. Read on, though, and we'll tell you more.
...
...
@@ -33,6 +33,8 @@ Infrastructure should be easy and powerful to command, but it should not look li
@@ -448,7 +448,7 @@ instance, you could test for the existance of a particular program.
The 'register' keyword decides what variable to save a result in. The resulting variables can be used in templates, action lines, or only_if statements. It looks like this (in an obviously trivial example)::
- name: test playbook
- name: test play
hosts: all
tasks:
...
...
@@ -460,6 +460,49 @@ The 'register' keyword decides what variable to save a result in. The resulting