<root@linux0 /etc/ansible>$ cat /root/name
ping
raw
yum
apt
pip
synchronize
template
copy
user
group
service
get_url
fetch
file
unarchive
command
shell
<root@linux0 /etc/ansible>$ cat /root/find.sh
#!/bin/bashfor i in`cat /root/name`do
l=`ansible-doc $i |awk'/^$/ {print NR}'|sed -n '2'p`#查找第二个空行的行数；#echo $((l-1))
ansible-doc $i|sed -n "1,$((l-1))"p |tee -a /root/result.txt #截取到空行以前的内容，重定向和显示；done<root@linux0 /etc/ansible>$ bash /root/find.sh
> PING (/usr/lib/python2.7/site-packages/ansible/modules/system/ping.py)
A trivial test module, this module always returns `pong' on successful
contact. It does not make sense in playbooks, but it is useful from
`/usr/bin/ansible' to verify the ability to login and that a usable python
is configured. This is NOT ICMP ping, this is just a trivial test module.
For Windows targets, use the [win_ping] module instead.
> RAW (/usr/lib/python2.7/site-packages/ansible/modules/commands/raw.py)
Executes a low-down and dirty SSH command, not going through the module
subsystem. This is useful and should only be done in two cases. The first
case is installing `python-simplejson' on older (Python 2.4 and before)
hosts that need it as a dependency to run modules, since nearly all core
modules require it. Another is speaking to any devices such as routers that
do not have any Python installed. In any other case, using the [shell] or
[command] module is much more appropriate. Arguments given to `raw' are run
directly through the configured remote shell. Standard output, error output
and return code are returned when available. There is no change handler
support for this module. This module does not require python on the remote
system, much like the [script] module. This module is also supported for
Windows targets.
> YUM (/usr/lib/python2.7/site-packages/ansible/modules/packaging/os/yum.py)
Installs, upgrade, downgrades, removes, and lists packages and groups with
the `yum' package manager.
> APT (/usr/lib/python2.7/site-packages/ansible/modules/packaging/os/apt.py)
Manages `apt' packages (such as for Debian/Ubuntu).
> PIP (/usr/lib/python2.7/site-packages/ansible/modules/packaging/language/pip.py)
Manage Python library dependencies. To use this module, one of the following
keys is required: `name' or `requirements'.> SYNCHRONIZE (/usr/lib/python2.7/site-packages/ansible/modules/files/synchronize.py)`synchronize' is a wrapper around rsync to make common tasks in your
playbooks quick and easy. It is run and originates on the local host where
Ansible is being run. Of course, you could just use the `command' action to
call rsync yourself, but you also have to add a fair number of boilerplate
options and host facts. `synchronize' is not intended to provide access to
the full power of rsync, but does make the most common invocations easier to
implement. You `still` may need to call rsync directly via `command' or
`shell' depending on your use case.
> TEMPLATE (/usr/lib/python2.7/site-packages/ansible/modules/files/template.py)
Templates are processed by the Jinja2 templating language
(http://jinja.pocoo.org/docs/) - documentation on the template formatting
can be found in the Template Designer Documentation
(http://jinja.pocoo.org/docs/templates/). Six additional variables can be
used in templates: `ansible_managed' (configurable via the `defaults'
section of `ansible.cfg') contains a string which can be used to describe
the template name, host, modification time of the template file and the
owner uid. `template_host' contains the node name of the template's machine.
`template_uid' the numeric user id of the owner. `template_path' the path of
the template. `template_fullpath' is the absolute path of the template.
`template_run_date' is the date that the template was rendered.
> COPY (/usr/lib/python2.7/site-packages/ansible/modules/files/copy.py)
The `copy' module copies a file from the local or remote machine to a
location on the remote machine. Use the [fetch] module to copy files from
remote locations to the local box. If you need variable interpolation in
copied files, use the [template] module. For Windows targets, use the
[win_copy] module instead.
> USER (/usr/lib/python2.7/site-packages/ansible/modules/system/user.py)
Manage user accounts and user attributes. For Windows targets, use the
[win_user] module instead.
> GROUP (/usr/lib/python2.7/site-packages/ansible/modules/system/group.py)
Manage presence of groups on a host. For Windows targets, use the
[win_group] module instead.
> SERVICE (/usr/lib/python2.7/site-packages/ansible/modules/system/service.py)
Controls services on remote hosts. Supported init systems include BSD init,
OpenRC, SysV, Solaris SMF, systemd, upstart. For Windows targets, use the
[win_service] module instead.
> GET_URL (/usr/lib/python2.7/site-packages/ansible/modules/net_tools/basics/get_url.py)
Downloads files from HTTP, HTTPS, or FTP to the remote server. The remote
server `must' have direct access to the remote resource. By default, if an
environment variable `<protocol>_proxy' is set on the target host, requests
will be sent through that proxy. This behaviour can be overridden by setting
a variable for this task (see `setting the environment
<http://docs.ansible.com/playbooks_environment.html>`_), or by using the
use_proxy option. HTTP redirects can redirect from HTTP to HTTPS so you
should be sure that your proxy environment for both protocols is correct.
From Ansible 2.4 when run with `--check', it will do a HEAD request to
validate the URL but will not download the entire file or verify it against
hashes. For Windows targets, use the [win_get_url] module instead.
> FETCH (/usr/lib/python2.7/site-packages/ansible/modules/files/fetch.py)
This module works like [copy], but in reverse. It is used for fetching files
from remote machines and storing them locally in a file tree, organized by
hostname. This module is also supported for Windows targets.
> FILE (/usr/lib/python2.7/site-packages/ansible/modules/files/file.py)
Sets attributes of files, symlinks, and directories, or removes
files/symlinks/directories. Many other modules support the same options as
the `file' module - including [copy], [template], and [assemble]. For
Windows targets, use the [win_file] module instead.
> UNARCHIVE (/usr/lib/python2.7/site-packages/ansible/modules/files/unarchive.py)
The `unarchive' module unpacks an archive. By default, it will copy the
sourcefile from the local system to the target before unpacking. Set
`remote_src=yes' to unpack an archive which already exists on the target.
For Windows targets, use the [win_unzip] module instead.
> COMMAND (/usr/lib/python2.7/site-packages/ansible/modules/commands/command.py)
The `command' module takes the command name followed by a list of space-
delimited arguments. The given command will be executed on all selected
nodes. It will not be processed through the shell, so variables like `$HOME'
and operations like `"<"', `">"', `"|"', `";"' and `"&"' will not work (use
the [shell] module if you need these features). For Windows targets, use the
[win_command] module instead.
> SHELL (/usr/lib/python2.7/site-packages/ansible/modules/commands/shell.py)
The `shell' module takes the command name followed by a list of space-
delimited arguments. It is almost exactly like the [command] module but runs
the command through a shell (`/bin/sh') on the remote node. For Windows
targets, use the [win_shell] module instead.
