Ansible学习笔记

Ansible (opens new window)是一个基于Python开发的自动化运维工具，可以用来配置系统、部署软件和编排其他系统任务。Ansible没有客户端，底层通信依赖于系统软件，Linux系统下基于OpenSSH通信，Windows系统下基于PowerShell，管理端必须是Linux。Ansible通过SSH连接客户端执行任务。

Ansible的三大组件

Ansible automates the management of remote systems and controls their desired state.

As shown in the preceding figure, most Ansible environments have three main components:

• Control node

  A system on which Ansible is installed. You run Ansible commands such as ansible or ansible-inventory on a control node.

• Inventory

  A list of managed nodes that are logically organized. You create an inventory on the control node to describe host deployments to Ansible.

• Managed node

  A remote system, or host, that Ansible controls.

Ansible的安装部署

Control node requirements

For your control node (the machine that runs Ansible), you can use nearly any UNIX-like machine with Python installed. This includes Red Hat, Debian, Ubuntu, macOS, BSDs, and Windows under a Windows Subsystem for Linux (WSL) distribution (opens new window). Windows without WSL is not natively supported as a control node; see Matt Davis’ blog post (opens new window) for more information.

Managed node requirements

The managed node (the machine that Ansible is managing) does not require Ansible to be installed, but requires Python to run Ansible-generated Python code. The managed node also needs a user account that can connect through SSH to the node with an interactive POSIX shell.

以下是在基于Red Hat的系统（如CentOS和Fedora）中使用yum安装Ansible的步骤：

# epel-release的主要用途是提供一个额外的软件源，用于安装那些在官方软件源中不可用或难以找到的软件包。EPEL（Extra Packages for Enterprise Linux）是一个由Fedora社区创建的项目，旨在为RHEL（Red Hat Enterprise Linux）及其衍生版本（如CentOS、Scientific Linux等）提供高质量的软件包。通过安装epel-release软件包，用户实际上是在他们的系统中添加了一个第三方的yum源，这个源提供了比官方rpm仓库更丰富的软件包资源。这在官方源中软件包不足或缺少某些特定软件时非常有用，避免了用户自行编译软件的繁琐过程。
# 安装epel-release源后可找到并安装ansible
yum -y install epel-release
yum -y install ansible

验证安装结果：

ansible --version

# https://docs.ansible.com/ansible/2.9/index.html
[root@localhost0141 ~]# ansible --version
ansible 2.9.27
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.5 (default, Nov 14 2023, 16:14:06) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)]

其他安装方式：https://docs.ansible.com/ansible/latest/installation_guide/index.html (opens new window)

Ansible的目录结构

可以通过以下命令获取ansible所有文件存放目录：

rpm -ql ansible

该命令输出内容较多，大致分为如下几类：

1. 配置文件目录 ：/etc/ansible/，主要功能为：Inventory主机信息配置、Ansible工具功能配置等。所有Ansible的配置均存放在该目录下，运维日常的所有配置类操作也均基于此目录进行。
2. 执行文件目录 ：/usr/bin/，主要功能为：Ansible系列命令默认存放目录。Ansible所有可执行文件均存放在该目录下。
3. Lib库依赖目录：/usr/lib/pythonX.X/site-packages/ansible/，Ansible所有lib库文件和模块文件也均存放于该目录下。
4. Help文档目录 ：/usr/share/doc/ansible-X.X.X/
5. Man文档目录 ：/usr/share/man/man1/

Ansible的配置文件

https://docs.ansible.com/ansible/latest/reference_appendices/config.html#ansible-configuration-settings-locations (opens new window)

Ansible的配置文件是：/etc/ansible/ansible.cfg。

ansible.cfg可以存放于多个地方，Ansible读取配置文件的顺序依次是：

• ANSIBLE_CONFIG (environment variable if set)
• ansible.cfg (in the current directory)
• ~/.ansible.cfg (in the home directory)
• /etc/ansible/ansible.cfg

先找到哪个就使用哪个的配置。其ansible.cfg配置的所有内容均可在命令行通过参数的形式传递或定义在Playbooks中。

# config file for ansible -- https://ansible.com/
# ===============================================

# nearly all parameters can be overridden in ansible-playbook
# or with command line flags. ansible will read ANSIBLE_CONFIG,
# ansible.cfg in the current working directory, .ansible.cfg in
# the home directory or /etc/ansible/ansible.cfg, whichever it
# finds first

[defaults]

# some basic default values...

#inventory      = /etc/ansible/hosts		# 定义Inventory
#library        = /usr/share/my_modules/	# 自定义lib库存放目录
#module_utils   = /usr/share/my_module_utils/
#remote_tmp     = ~/.ansible/tmp	# 临时文件远程主机存放目录
#local_tmp      = ~/.ansible/tmp	# 临时文件本地存放目录
#plugin_filters_cfg = /etc/ansible/plugin_filters.yml
#forks          = 5		# 默认开启的并发数
#poll_interval  = 15	# 默认轮询时间间隔
#sudo_user      = root	# 默认sudo用户
#ask_sudo_pass = True	# 是否需要sudo密码
#ask_pass      = True	# 是否需要密码
#transport      = smart
#remote_port    = 22
#module_lang    = C
#module_set_locale = False

# plays will gather facts by default, which contain information about
# the remote system.
#
# smart - gather by default, but don't regather if already gathered
# implicit - gather by default, turn off with gather_facts: False
# explicit - do not gather by default, must say gather_facts: True
#gathering = implicit

# This only affects the gathering done by a play's gather_facts directive,
# by default gathering retrieves all facts subsets
# all - gather all subsets
# network - gather min and network facts
# hardware - gather hardware facts (longest facts to retrieve)
# virtual - gather min and virtual facts
# facter - import facts from facter
# ohai - import facts from ohai
# You can combine them using comma (ex: network,virtual)
# You can negate them using ! (ex: !hardware,!facter,!ohai)
# A minimal set of facts is always gathered.
#gather_subset = all

# some hardware related facts are collected
# with a maximum timeout of 10 seconds. This
# option lets you increase or decrease that
# timeout to something more suitable for the
# environment.
# gather_timeout = 10

# Ansible facts are available inside the ansible_facts.* dictionary
# namespace. This setting maintains the behaviour which was the default prior
# to 2.5, duplicating these variables into the main namespace, each with a
# prefix of 'ansible_'.
# This variable is set to True by default for backwards compatibility. It
# will be changed to a default of 'False' in a future release.
# ansible_facts.
# inject_facts_as_vars = True

# additional paths to search for roles in, colon separated
#roles_path    = /etc/ansible/roles	# 默认下载的Roles存放的目录

# uncomment this to disable SSH key host checking
#host_key_checking = False	# 首次连接是否需要检查key认证

# change the default callback, you can only have one 'stdout' type  enabled at a time.
#stdout_callback = skippy


## Ansible ships with some plugins that require whitelisting,
## this is done to avoid running all of a type by default.
## These setting lists those that you want enabled for your system.
## Custom plugins should not need this unless plugin author specifies it.

# enable callback plugins, they can output to stdout but cannot be 'stdout' type.
#callback_whitelist = timer, mail

# Determine whether includes in tasks and handlers are "static" by
# default. As of 2.0, includes are dynamic by default. Setting these
# values to True will make includes behave more like they did in the
# 1.x versions.
#task_includes_static = False
#handler_includes_static = False

# Controls if a missing handler for a notification event is an error or a warning
#error_on_missing_handler = True

# change this for alternative sudo implementations
#sudo_exe = sudo

# What flags to pass to sudo
# WARNING: leaving out the defaults might create unexpected behaviours
#sudo_flags = -H -S -n

# SSH timeout
#timeout = 10	# 默认超时时间

# default user to use for playbooks if user is not specified
# (/usr/bin/ansible will use current user as default)
#remote_user = root

# logging is off by default unless this path is defined
# if so defined, consider logrotate
#log_path = /var/log/ansible.log	# 执行日志存放目录

# default module name for /usr/bin/ansible
#module_name = command	# 默认执行的模块

# use this shell for commands executed under sudo
# you may need to change this to bin/bash in rare instances
# if sudo is constrained
#executable = /bin/sh

# if inventory variables overlap, does the higher precedence one win
# or are hash values merged together?  The default is 'replace' but
# this can also be set to 'merge'.
#hash_behaviour = replace

# by default, variables from roles will be visible in the global variable
# scope. To prevent this, the following option can be enabled, and only
# tasks and handlers within the role will see the variables there
#private_role_vars = yes

# list any Jinja2 extensions to enable here:
#jinja2_extensions = jinja2.ext.do,jinja2.ext.i18n

# if set, always use this private key file for authentication, same as
# if passing --private-key to ansible or ansible-playbook
#private_key_file = /path/to/file

# If set, configures the path to the Vault password file as an alternative to
# specifying --vault-password-file on the command line.
#vault_password_file = /path/to/vault_password_file

# format of string {{ ansible_managed }} available within Jinja2
# templates indicates to users editing templates files will be replaced.
# replacing {file}, {host} and {uid} and strftime codes with proper values.
#ansible_managed = Ansible managed: {file} modified on %Y-%m-%d %H:%M:%S by {uid} on {host}
# {file}, {host}, {uid}, and the timestamp can all interfere with idempotence
# in some situations so the default is a static string:
#ansible_managed = Ansible managed

# by default, ansible-playbook will display "Skipping [host]" if it determines a task
# should not be run on a host.  Set this to "False" if you don't want to see these "Skipping"
# messages. NOTE: the task header will still be shown regardless of whether or not the
# task is skipped.
#display_skipped_hosts = True

# by default, if a task in a playbook does not include a name: field then
# ansible-playbook will construct a header that includes the task's action but
# not the task's args.  This is a security feature because ansible cannot know
# if the *module* considers an argument to be no_log at the time that the
# header is printed.  If your environment doesn't have a problem securing
# stdout from ansible-playbook (or you have manually specified no_log in your
# playbook on all of the tasks where you have secret information) then you can
# safely set this to True to get more informative messages.
#display_args_to_stdout = False

# by default (as of 1.3), Ansible will raise errors when attempting to dereference
# Jinja2 variables that are not set in templates or action lines. Uncomment this line
# to revert the behavior to pre-1.3.
#error_on_undefined_vars = False

# by default (as of 1.6), Ansible may display warnings based on the configuration of the
# system running ansible itself. This may include warnings about 3rd party packages or
# other conditions that should be resolved if possible.
# to disable these warnings, set the following value to False:
#system_warnings = True

# by default (as of 1.4), Ansible may display deprecation warnings for language
# features that should no longer be used and will be removed in future versions.
# to disable these warnings, set the following value to False:
#deprecation_warnings = True

# (as of 1.8), Ansible can optionally warn when usage of the shell and
# command module appear to be simplified by using a default Ansible module
# instead.  These warnings can be silenced by adjusting the following
# setting or adding warn=yes or warn=no to the end of the command line
# parameter string.  This will for example suggest using the git module
# instead of shelling out to the git command.
# command_warnings = False


# set plugin path directories here, separate with colons
#action_plugins     = /usr/share/ansible/plugins/action
#become_plugins     = /usr/share/ansible/plugins/become
#cache_plugins      = /usr/share/ansible/plugins/cache
#callback_plugins   = /usr/share/ansible/plugins/callback
#connection_plugins = /usr/share/ansible/plugins/connection
#lookup_plugins     = /usr/share/ansible/plugins/lookup
#inventory_plugins  = /usr/share/ansible/plugins/inventory
#vars_plugins       = /usr/share/ansible/plugins/vars
#filter_plugins     = /usr/share/ansible/plugins/filter
#test_plugins       = /usr/share/ansible/plugins/test
#terminal_plugins   = /usr/share/ansible/plugins/terminal
#strategy_plugins   = /usr/share/ansible/plugins/strategy


# by default, ansible will use the 'linear' strategy but you may want to try
# another one
#strategy = free

# by default callbacks are not loaded for /bin/ansible, enable this if you
# want, for example, a notification or logging callback to also apply to
# /bin/ansible runs
#bin_ansible_callbacks = False


# don't like cows?  that's unfortunate.
# set to 1 if you don't want cowsay support or export ANSIBLE_NOCOWS=1
#nocows = 1

# set which cowsay stencil you'd like to use by default. When set to 'random',
# a random stencil will be selected for each task. The selection will be filtered
# against the `cow_whitelist` option below.
#cow_selection = default
#cow_selection = random

# when using the 'random' option for cowsay, stencils will be restricted to this list.
# it should be formatted as a comma-separated list with no spaces between names.
# NOTE: line continuations here are for formatting purposes only, as the INI parser
#       in python does not support them.
#cow_whitelist=bud-frogs,bunny,cheese,daemon,default,dragon,elephant-in-snake,elephant,eyes,\
#              hellokitty,kitty,luke-koala,meow,milk,moofasa,moose,ren,sheep,small,stegosaurus,\
#              stimpy,supermilker,three-eyes,turkey,turtle,tux,udder,vader-koala,vader,www

# don't like colors either?
# set to 1 if you don't want colors, or export ANSIBLE_NOCOLOR=1
#nocolor = 1

# if set to a persistent type (not 'memory', for example 'redis') fact values
# from previous runs in Ansible will be stored.  This may be useful when
# wanting to use, for example, IP information from one group of servers
# without having to talk to them in the same playbook run to get their
# current IP information.
#fact_caching = memory

#This option tells Ansible where to cache facts. The value is plugin dependent.
#For the jsonfile plugin, it should be a path to a local directory.
#For the redis plugin, the value is a host:port:database triplet: fact_caching_connection = localhost:6379:0

#fact_caching_connection=/tmp



# retry files
# When a playbook fails a .retry file can be created that will be placed in ~/
# You can enable this feature by setting retry_files_enabled to True
# and you can change the location of the files by setting retry_files_save_path

#retry_files_enabled = False
#retry_files_save_path = ~/.ansible-retry

# squash actions
# Ansible can optimise actions that call modules with list parameters
# when looping. Instead of calling the module once per with_ item, the
# module is called once with all items at once. Currently this only works
# under limited circumstances, and only with parameters named 'name'.
#squash_actions = apk,apt,dnf,homebrew,pacman,pkgng,yum,zypper

# prevents logging of task data, off by default
#no_log = False

# prevents logging of tasks, but only on the targets, data is still logged on the master/controller
#no_target_syslog = False

# controls whether Ansible will raise an error or warning if a task has no
# choice but to create world readable temporary files to execute a module on
# the remote machine.  This option is False by default for security.  Users may
# turn this on to have behaviour more like Ansible prior to 2.1.x.  See
# https://docs.ansible.com/ansible/become.html#becoming-an-unprivileged-user
# for more secure ways to fix this than enabling this option.
#allow_world_readable_tmpfiles = False

# controls the compression level of variables sent to
# worker processes. At the default of 0, no compression
# is used. This value must be an integer from 0 to 9.
#var_compression_level = 9

# controls what compression method is used for new-style ansible modules when
# they are sent to the remote system.  The compression types depend on having
# support compiled into both the controller's python and the client's python.
# The names should match with the python Zipfile compression types:
# * ZIP_STORED (no compression. available everywhere)
# * ZIP_DEFLATED (uses zlib, the default)
# These values may be set per host via the ansible_module_compression inventory
# variable
#module_compression = 'ZIP_DEFLATED'

# This controls the cutoff point (in bytes) on --diff for files
# set to 0 for unlimited (RAM may suffer!).
#max_diff_size = 1048576

# This controls how ansible handles multiple --tags and --skip-tags arguments
# on the CLI.  If this is True then multiple arguments are merged together.  If
# it is False, then the last specified argument is used and the others are ignored.
# This option will be removed in 2.8.
#merge_multiple_cli_flags = True

# Controls showing custom stats at the end, off by default
#show_custom_stats = True

# Controls which files to ignore when using a directory as inventory with
# possibly multiple sources (both static and dynamic)
#inventory_ignore_extensions = ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo

# This family of modules use an alternative execution path optimized for network appliances
# only update this setting if you know how this works, otherwise it can break module execution
#network_group_modules=eos, nxos, ios, iosxr, junos, vyos

# When enabled, this option allows lookups (via variables like {{lookup('foo')}} or when used as
# a loop with `with_foo`) to return data that is not marked "unsafe". This means the data may contain
# jinja2 templating language which will be run through the templating engine.
# ENABLING THIS COULD BE A SECURITY RISK
#allow_unsafe_lookups = False

# set default errors for all plays
#any_errors_fatal = False

[inventory]
# enable inventory plugins, default: 'host_list', 'script', 'auto', 'yaml', 'ini', 'toml'
#enable_plugins = host_list, virtualbox, yaml, constructed

# ignore these extensions when parsing a directory as inventory source
#ignore_extensions = .pyc, .pyo, .swp, .bak, ~, .rpm, .md, .txt, ~, .orig, .ini, .cfg, .retry

# ignore files matching these patterns when parsing a directory as inventory source
#ignore_patterns=

# If 'true' unparsed inventory sources become fatal errors, they are warnings otherwise.
#unparsed_is_failed=False

[privilege_escalation]
#become=True
#become_method=sudo
#become_user=root
#become_ask_pass=False

[paramiko_connection]

# uncomment this line to cause the paramiko connection plugin to not record new host
# keys encountered.  Increases performance on new host additions.  Setting works independently of the
# host key checking setting above.
#record_host_keys=False

# by default, Ansible requests a pseudo-terminal for commands executed under sudo. Uncomment this
# line to disable this behaviour.
#pty=False

# paramiko will default to looking for SSH keys initially when trying to
# authenticate to remote devices.  This is a problem for some network devices
# that close the connection after a key failure.  Uncomment this line to
# disable the Paramiko look for keys function
#look_for_keys = False

# When using persistent connections with Paramiko, the connection runs in a
# background process.  If the host doesn't already have a valid SSH key, by
# default Ansible will prompt to add the host key.  This will cause connections
# running in background processes to fail.  Uncomment this line to have
# Paramiko automatically add host keys.
#host_key_auto_add = True

[ssh_connection]

# ssh arguments to use
# Leaving off ControlPersist will result in poor performance, so use
# paramiko on older platforms rather than removing it, -C controls compression use
#ssh_args = -C -o ControlMaster=auto -o ControlPersist=60s

# The base directory for the ControlPath sockets.
# This is the "%(directory)s" in the control_path option
#
# Example:
# control_path_dir = /tmp/.ansible/cp
#control_path_dir = ~/.ansible/cp

# The path to use for the ControlPath sockets. This defaults to a hashed string of the hostname,
# port and username (empty string in the config). The hash mitigates a common problem users
# found with long hostnames and the conventional %(directory)s/ansible-ssh-%%h-%%p-%%r format.
# In those cases, a "too long for Unix domain socket" ssh error would occur.
#
# Example:
# control_path = %(directory)s/%%h-%%r
#control_path =

# Enabling pipelining reduces the number of SSH operations required to
# execute a module on the remote server. This can result in a significant
# performance improvement when enabled, however when using "sudo:" you must
# first disable 'requiretty' in /etc/sudoers
#
# By default, this option is disabled to preserve compatibility with
# sudoers configurations that have requiretty (the default on many distros).
#
#pipelining = False

# Control the mechanism for transferring files (old)
#   * smart = try sftp and then try scp [default]
#   * True = use scp only
#   * False = use sftp only
#scp_if_ssh = smart

# Control the mechanism for transferring files (new)
# If set, this will override the scp_if_ssh option
#   * sftp  = use sftp to transfer files
#   * scp   = use scp to transfer files
#   * piped = use 'dd' over SSH to transfer files
#   * smart = try sftp, scp, and piped, in that order [default]
#transfer_method = smart

# if False, sftp will not use batch mode to transfer files. This may cause some
# types of file transfer failures impossible to catch however, and should
# only be disabled if your sftp version has problems with batch mode
#sftp_batch_mode = False

# The -tt argument is passed to ssh when pipelining is not enabled because sudo 
# requires a tty by default. 
#usetty = True

# Number of times to retry an SSH connection to a host, in case of UNREACHABLE.
# For each retry attempt, there is an exponential backoff,
# so after the first attempt there is 1s wait, then 2s, 4s etc. up to 30s (max).
#retries = 3

[persistent_connection]

# Configures the persistent connection timeout value in seconds.  This value is
# how long the persistent connection will remain idle before it is destroyed.
# If the connection doesn't receive a request before the timeout value
# expires, the connection is shutdown. The default value is 30 seconds.
#connect_timeout = 30

# The command timeout value defines the amount of time to wait for a command
# or RPC call before timing out. The value for the command timeout must
# be less than the value of the persistent connection idle timeout (connect_timeout)
# The default value is 30 second.
#command_timeout = 30

[accelerate]
#accelerate_port = 5099
#accelerate_timeout = 30
#accelerate_connect_timeout = 5.0

# The daemon timeout is measured in minutes. This time is measured
# from the last activity to the accelerate daemon.
#accelerate_daemon_timeout = 30

# If set to yes, accelerate_multi_key will allow multiple
# private keys to be uploaded to it, though each user must
# have access to the system via SSH to add a new key. The default
# is "no".
#accelerate_multi_key = yes

[selinux]
# file systems that require special treatment when dealing with security context
# the default behaviour that copies the existing context or uses the user default
# needs to be changed to use the file system dependent context.
#special_context_filesystems=nfs,vboxsf,fuse,ramfs,9p,vfat

# Set this to yes to allow libvirt_lxc connections to work without SELinux.
#libvirt_lxc_noseclabel = yes

[colors]
#highlight = white
#verbose = blue
#warn = bright purple
#error = red
#debug = dark gray
#deprecate = purple
#skip = cyan
#unreachable = red
#ok = green
#changed = yellow
#diff_add = green
#diff_remove = red
#diff_lines = cyan


[diff]
# Always print diff when running ( same as always running with -D/--diff )
# always = no

# Set how many context lines to show in diff
# context = 3

Ansible的命令

ansible

https://docs.ansible.com/ansible/latest/command_guide/intro_adhoc.html#intro-adhoc (opens new window)

https://docs.ansible.com/ansible/latest/cli/ansible.html#ansible (opens new window)

ad-hoc（临时命令模式）主要用于临时命令的执行。使用格式如下：

ansible <host-pattern> -m [module] -a "[module options]"

<host-pattern> 是Inventory中定义的主机或主机组，可以为ip、hostname、Inventory中的group组名、具有“.”或“*”或“:”等特殊字符的匹配型字符串。

[module options]是ansible的参数选项。

• -i 'PATH', --inventory 'PATH'：指定hosts文件路径，默认/etc/ansible/hosts

• -m 'MODULE_NAME', --module-name 'MODULE_NAME'：指定执行使用的模块 ，默认是command。

• -a 'MODULE_ARGS', --args 'MODULE_ARGS'：指定模块参数。

• -u 'REMOTE_USER', --user 'REMOTE_USER'：指定远程主机以USERNAME运行命令。

• -k, --ask-pass：询问连接密码。

• -v, --verbose：详细模式（-vvv更多，-vvv启用连接调试）。使用 -vvv 参数可以清楚地了解Ansible命令执行流程。

  

使用man ansible可以查看详细选项。

ansible-playbook

https://docs.ansible.com/ansible/latest/cli/ansible-playbook.html#ansible-playbook (opens new window)

使用格式如下：

ansible-playbook playbook.yml

playbook

https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html (opens new window)

playbook（剧本模式）可以理解为ad-hoc的集合，通过一定的规则编排在一起。

一个playbook就是play的列表。

	是否必需	描述
hosts	是	需要配置的一组主机。
tasks	是	需要在这组主机上执行的任务。 每个task必须包含一个键值对。 键是模块的名字，值是要传递到模块的参数。 task中可以声明一个notify，键是notify，值是handler的名字。
vars	否	定义变量。在vars区段中定义变量的名字与值。使用引用变量。
vars_files	否	定义变量。把变量放到一个或多个文件中。
handlers	否	与tasks很相似。 handler只会在所有task执行完后执行。 哪怕被通知了多次，它也只执行一次。 当play中定义了多个handler时，handler安装play中定义的顺序执行，而不是通知的顺序。

role

role是将playbook分割为多个文件的主要机制。

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html (opens new window)

ansible-doc

ansible-doc是Ansible模块文档说明。

使用方式：

ansible-doc [options] [module...]

常用选项：

• -l, --list：列出可用模块
• -s, --snippet：显示指定模块的playbook片段

具体示例：

# 列出可用模块
ansible-doc -l
# 功能模块说明
ansible-doc command
ansible-doc shell
# 显示指定模块的playbook片段
ansible-doc -s command
ansible-doc -s shell

Ansible的模块

https://docs.ansible.com/ansible/latest/module_plugin_guide/modules_intro.html (opens new window)

debug模块

debug模块：打印任意信息。例如：输出变量的值- debug: var=myvarname。

---
name: usage of register and debug module
hosts: managednodes
tasks:
  - name: capture output of id command
    command: id -un
    register: login  # 捕获id -un命令的输出到名为login的变量中
  - debug: var=login # 使用debug模块输出login变量

debug模块的输出类似如下：

command模块‌

‌command模块‌：用于在远程主机上执行命令。此模块为默认模块。

常用参数	功能
chdir	执行命令前先进入到指定目录
cmd	运行命令指定
creates	如果文件存在将不运行命令
removes	如果文件存在将运行命令

ansible all -m command -a 'chdir=/mnt pwd'
ansible all -m command -a 'chdir=/mnt cmd=pwd'
ansible all -m command -a 'chdir=/mnt creates=/mnt/file pwd'
ansible all -m command -a 'chdir=/mnt removes=/mnt/file pwd'
ansible all -m command -a 'chdir=/mnt touch file'
ansible all -m command -a 'chdir=/mnt creates=/mnt/file pwd'
ansible all -m command -a 'chdir=/mnt removes=/mnt/file pwd'

shell模块

shell模块‌：用于在远程主机上执行命令。Shell模块支持变量引用、管道符和重定向，可以执行更复杂的命令‌。

常用参数	功能
chdir	执行命令前先进入到指定目录
cmd	运行命令指定
creates	如果文件存在将不运行命令
removes	如果文件存在将运行命令
executable	指定执行环境，默认为sh

ansible all -m shell -a 'chdir=/mnt/ touch file{1..3}'
ansible all -m shell -a 'chdir=/mnt/ ls -ld /mnt'
ansible all -m shell -a 'chdir=/mnt/ ls -lR /mnt'

script模块

在ansible主机中写好的脚本在受控主机中执行。

file模块

file模块‌：用于管理文件和目录，包括创建、删除、修改文件属性等操作。例如，设置文件的属主、属组、权限，以及创建空文件或目录‌。

参数	功能
path	指定文件名称
state	指定操作状态 touch：建立 absent：删除 directory：递归目录 link：建立软链接 hard：建立硬链接
mode	设定权限
owner	设定属主
group	设定属组
src	源文件
dest	目标文件
recurse=yes	递归更改

template模块

template模块：从模板生成一个文件并复制到远程主机上。

copy模块‌ 和 ‌fetch模块‌

copy模块‌：用于从本地复制文件到远程主机。

copy模块参数：

参数	功能
src	源文件
dest	目的地文件
owner	指定目的地文件所有人
group	指定目的地文件所有组
mode	指定目的地文件权限
backup=yes	当受控主机中存在文件时备份原文件
content	指定文本内容直接在受控主机中生成文件

fetch模块‌：用于从远程主机复制文件到本地。fetch模块‌不支持目录。

fetch模块参数：

参数	功能
src	受控主机的源文件
dest	本机目录
flat	基本名称功能，单纯只要文件，不要路径的层层目录

archive模块‌ 和 ‌unarchive模块‌

‌archive模块‌ 和 ‌unarchive模块‌：用于压缩和解压缩文件。

archive模块‌参数：

参数	功能
path	打包目录名称
dest	声称打包文件名称
format	打包格式
owner	指定文件所属人
mode	指定文件权限

unarchive模块‌参数：

其他模块

• hostname模块‌：用于管理远程主机上的主机名。
• ‌cron模块‌：用于管理cron任务。
• ‌yum_repository模块‌ 和 ‌yum(dnf)模块‌：用于管理YUM仓库。
• ‌service模块‌ 和 ‌firewalld模块‌：分别用于管理服务（启动、停止或者重启一个服务）和防火墙规则。
• ‌user模块‌ 和 ‌group模块‌：用于管理用户和组。
• ‌lineinfile模块‌ 和 ‌replace模块‌：用于修改配置文件中的特定行或文本。
• ‌setup模块‌ 和 ‌debug模块‌：分别用于收集远程主机的信息和进行调试。

Ansible的示例

在 /etc/ansible/hosts 配置

192.168.1.42
192.168.1.43

[managednodes]
192.168.1.42
192.168.1.43

使用 ad-hoc 方式执行命令

ansible 192.168.1.42 -m command -a 'hostname'
ansible managednodes -m shell -a 'df -lh'

使用 playbook 方式执行命令

1. 创建文件 test.yml

   ---
   - name: test
     hosts: managednodes
     tasks:
       - name: hostname
         command: hostname  
       - name: view disk space
         shell: df -lh
   

2. 检查语法

   ansible-playbook --syntax-check test.yml
   

3. 执行命令

   ansible-playbook test.yml
   

Python API

https://docs.ansible.com/ansible/2.9/dev_guide/developing_api.html (opens new window)

https://docs.ansible.com/ansible/latest/dev_guide/developing_api.html (opens new window)

参考资料

https://docs.ansible.com/ansible/latest/index.html (opens new window)