mirror of
https://github.com/ansible-collections/community.general.git
synced 2025-10-21 19:43:59 -07:00
Spellcheck. Formatting. References.
This commit is contained in:
parent
8bd523fe36
commit
a1010e5405
7 changed files with 187 additions and 123 deletions
|
@ -25,25 +25,37 @@ Let's use ansible's command line tool to reboot all web servers in Atlanta, 10 a
|
|||
|
||||
The -f 10 specifies the usage of 10 simultaneous processes.
|
||||
|
||||
Note that other than the command module, ansible modules do not work like simple scripts. They make the remote system look like you state, and run the commands neccessary to get it there. This is commonly refered to
|
||||
as 'idempotency'.
|
||||
.. note::
|
||||
|
||||
Note that other than the :ref:`command` module, ansible modules do
|
||||
not work like simple scripts. They make the remote system look like
|
||||
you state, and run the commands necessary to get it there. This
|
||||
is commonly referred to as 'idempotent'.
|
||||
|
||||
File Transfer & Templating
|
||||
``````````````````````````
|
||||
|
||||
Ansible can SCP lots of files to multiple machines in parallel, and optionally use them as template sources.
|
||||
Ansible can SCP lots of files to multiple machines in parallel, and
|
||||
optionally use them as template sources.
|
||||
|
||||
To just transfer a file directly to many different servers::
|
||||
|
||||
ansible atlanta copy -a "/etc/hosts /tmp/hosts"
|
||||
|
||||
To use templating, first run the setup module to put the template variables you would like to use on the remote host. Then use the template module to write the files using the templates. Templates are written in Jinja2 format. Playbooks (covered elsewhere in the documentation) will run the setup module for you, making this even simpler.::
|
||||
To use templating, first run the setup module to put the template
|
||||
variables you would like to use on the remote host. Then use the
|
||||
template module to write the files using the templates. Templates are
|
||||
written in Jinja2 format. Playbooks (covered elsewhere in the
|
||||
documentation) will run the setup module for you, making this even
|
||||
simpler.::
|
||||
|
||||
ansible webservers -m setup -a "favcolor=red ntp_server=192.168.1.1"
|
||||
ansible webservers -m template -a "src=/srv/motd.j2 dest=/etc/motd"
|
||||
ansible webservers -m template -a "src=/srv/ntp.j2 dest=/etc/ntp.conf"
|
||||
|
||||
Need something like the fqdn in a template? If facter or ohai are installed, data from these projects will also be made available to the template engine, using 'facter' and 'ohai' prefixes for each.
|
||||
Need something like the fqdn in a template? If facter or ohai are
|
||||
installed, data from these projects will also be made available to the
|
||||
template engine, using 'facter' and 'ohai' prefixes for each.
|
||||
|
||||
Deploying From Source Control
|
||||
`````````````````````````````
|
||||
|
@ -52,7 +64,10 @@ Deploy your webapp straight from git::
|
|||
|
||||
ansible webservers -m git -a "repo=git://foo dest=/srv/myapp version=HEAD"
|
||||
|
||||
Since ansible modules can notify change handlers (see 'Playbooks') it is possible to tell ansible to run specific tasks when the code is updated, such as deploying Perl/Python/PHP/Ruby directly from git and then restarting apache.
|
||||
Since ansible modules can notify change handlers (see
|
||||
:doc:`playbooks`) it is possible to tell ansible to run specific tasks
|
||||
when the code is updated, such as deploying Perl/Python/PHP/Ruby
|
||||
directly from git and then restarting apache.
|
||||
|
||||
Managing Services
|
||||
`````````````````
|
||||
|
@ -68,14 +83,19 @@ Alternatively, restart a service on all webservers::
|
|||
Time Limited Background Operations
|
||||
``````````````````````````````````
|
||||
|
||||
Long running operations can be backgrounded, and their status can be checked on later. The same job ID is given to the same task on all hosts, so you won't lose track. Polling support is pending in the command line.::
|
||||
Long running operations can be backgrounded, and their status can be
|
||||
checked on later. The same job ID is given to the same task on all
|
||||
hosts, so you won't lose track. Polling support is pending in the
|
||||
command line.::
|
||||
|
||||
ansible all -B 3600 -a "/usr/bin/long_running_operation --do-stuff"
|
||||
ansible all -n job_status -a jid=123456789
|
||||
|
||||
Any module other than 'copy' or 'template' can be backgrounded. Typically you'll be backgrounding shell
|
||||
commands or software upgrades only.
|
||||
Any module other than :ref:`copy` or :ref:`template` can be
|
||||
backgrounded. Typically you'll be backgrounding shell commands or
|
||||
software upgrades only.
|
||||
|
||||
After the time limit (in seconds) runs out (-B), the process on the remote nodes will be killed.
|
||||
After the time limit (in seconds) runs out (``-B``), the process on
|
||||
the remote nodes will be killed.
|
||||
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue