1Glossary 2======== 3 4The following is a list (and re-explanation) of term definitions used elsewhere in the Ansible documentation. 5 6Consult the documentation home page for the full documentation and to see the terms in context, but this should be a good resource 7to check your knowledge of Ansible's components and understand how they fit together. It's something you might wish to read for review or 8when a term comes up on the mailing list. 9 10.. glossary:: 11 12 Action 13 An action is a part of a task that specifies which of the modules to 14 run and which arguments to pass to that module. Each task can have 15 only one action, but it may also have other parameters. 16 17 Ad Hoc 18 Refers to running Ansible to perform some quick command, using 19 :command:`/usr/bin/ansible`, rather than the :term:`orchestration` 20 language, which is :command:`/usr/bin/ansible-playbook`. An example 21 of an ad hoc command might be rebooting 50 machines in your 22 infrastructure. Anything you can do ad hoc can be accomplished by 23 writing a :term:`playbook <playbooks>` and playbooks can also glue 24 lots of other operations together. 25 26 Ansible (the package) 27 A software package (Python, deb, rpm, and so on) that contains ansible-core and a select group of collections. Playbooks that worked with Ansible 2.9 should still work with the Ansible 2.10 package. See the :file:`ansible-<version>.build` file in the release-specific directory at `ansible-build-data <https://github.com/ansible-community/ansible-build-data>`_ for a list of collections included in Ansible, as well as the included ``ansible-core`` version. 28 29 ansible-base 30 Used only for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository <https://github.com/ansible/ansible>`_. See ``ansible-core``. 31 32 ansible-core 33 Name used starting with 2.11. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository <https://github.com/ansible/ansible>`_. Contains the command-line tools and the code for basic features and functions, such as copying module code to managed nodes. The ``ansible-core`` package includes a few modules and plugins and allows you to add others by installing collections. 34 35 Ansible Galaxy 36 An `online resource <galaxy.ansible.com>`_ for finding and sharing Ansible community content. Also, the command-line utility that lets users install individual Ansible Collections, for example`` ansible-galaxy install community.crypto``. 37 38 Async 39 Refers to a task that is configured to run in the background rather 40 than waiting for completion. If you have a long process that would 41 run longer than the SSH timeout, it would make sense to launch that 42 task in async mode. Async modes can poll for completion every so many 43 seconds or can be configured to "fire and forget", in which case 44 Ansible will not even check on the task again; it will just kick it 45 off and proceed to future steps. Async modes work with both 46 :command:`/usr/bin/ansible` and :command:`/usr/bin/ansible-playbook`. 47 48 Callback Plugin 49 Refers to some user-written code that can intercept results from 50 Ansible and do something with them. Some supplied examples in the 51 GitHub project perform custom logging, send email, or even play sound 52 effects. 53 54 Check Mode 55 Refers to running Ansible with the ``--check`` option, which does not 56 make any changes on the remote systems, but only outputs the changes 57 that might occur if the command ran without this flag. This is 58 analogous to so-called "dry run" modes in other systems, though the 59 user should be warned that this does not take into account unexpected 60 command failures or cascade effects (which is true of similar modes in 61 other systems). Use this to get an idea of what might happen, but do 62 not substitute it for a good staging environment. 63 64 Collection 65 A packaging format for bundling and distributing Ansible content, including plugins, roles, modules, and more. Collections release independent of other collections or ``ansible-core`` so features can be available sooner to users. Some collections are packaged with Ansible (version 2.10 or later). You can install other collections (or other versions of collections) with ``ansible-galaxy collection install <namespace.collection>``. 66 67 Collection name 68 The second part of a Fully Qualified Collection Name. The collection name divides the collection namespace and usually reflects the function of the collection content. For example, the ``cisco`` namespace might contain ``cisco.ios``, ``cisco.aci``, and ``cisco.nxos``, with content for managing the different network devices maintained by Cisco. 69 70 community.general (collection) 71 A special collection managed by the Ansible Community Team containing all the modules and plugins which shipped in Ansible 2.9 that do ont have their own dedicated Collection. See `community.general <https://galaxy.ansible.com/community/general>`_` on Galaxy. 72 73 community.network (collection) 74 Similar to ``community.general``, focusing on network content. `community.network <https://galaxy.ansible.com/community/network>`_` on Galaxy. 75 76 Connection Plugin 77 By default, Ansible talks to remote machines through pluggable 78 libraries. Ansible uses native OpenSSH (:term:`SSH (Native)`) or 79 a Python implementation called :term:`paramiko`. OpenSSH is preferred 80 if you are using a recent version, and also enables some features like 81 Kerberos and jump hosts. This is covered in the :ref:`getting 82 started section <remote_connection_information>`. There are also 83 other connection types like ``accelerate`` mode, which must be 84 bootstrapped over one of the SSH-based connection types but is very 85 fast, and local mode, which acts on the local system. Users can also 86 write their own connection plugins. 87 88 Conditionals 89 A conditional is an expression that evaluates to true or false that 90 decides whether a given task is executed on a given machine or not. 91 Ansible's conditionals are powered by the 'when' statement, which are 92 discussed in the :ref:`working_with_playbooks`. 93 94 Declarative 95 An approach to achieving a task that uses a description of the 96 final state rather than a description of the sequence of steps 97 necessary to achieve that state. For a real world example, a 98 declarative specification of a task would be: "put me in California". 99 Depending on your current location, the sequence of steps to get you to 100 California may vary, and if you are already in California, nothing 101 at all needs to be done. Ansible's Resources are declarative; it 102 figures out the steps needed to achieve the final state. It also lets 103 you know whether or not any steps needed to be taken to get to the 104 final state. 105 106 Diff Mode 107 A ``--diff`` flag can be passed to Ansible to show what changed on 108 modules that support it. You can combine it with ``--check`` to get a 109 good 'dry run'. File diffs are normally in unified diff format. 110 111 Executor 112 A core software component of Ansible that is the power behind 113 :command:`/usr/bin/ansible` directly -- and corresponds to the 114 invocation of each task in a :term:`playbook <playbooks>`. The 115 Executor is something Ansible developers may talk about, but it's not 116 really user land vocabulary. 117 118 Facts 119 Facts are simply things that are discovered about remote nodes. While 120 they can be used in :term:`playbooks` and templates just like 121 variables, facts are things that are inferred, rather than set. Facts 122 are automatically discovered by Ansible when running plays by 123 executing the internal :ref:`setup module <setup_module>` on the remote nodes. You 124 never have to call the setup module explicitly, it just runs, but it 125 can be disabled to save time if it is not needed or you can tell 126 ansible to collect only a subset of the full facts via the 127 ``gather_subset:`` option. For the convenience of users who are 128 switching from other configuration management systems, the fact module 129 will also pull in facts from the :program:`ohai` and :program:`facter` 130 tools if they are installed. These are fact libraries from Chef and 131 Puppet, respectively. (These may also be disabled via 132 ``gather_subset:``) 133 134 Filter Plugin 135 A filter plugin is something that most users will never need to 136 understand. These allow for the creation of new :term:`Jinja2` 137 filters, which are more or less only of use to people who know what 138 Jinja2 filters are. If you need them, you can learn how to write them 139 in the :ref:`API docs section <developing_filter_plugins>`. 140 141 Forks 142 Ansible talks to remote nodes in parallel and the level of parallelism 143 can be set either by passing ``--forks`` or editing the default in 144 a configuration file. The default is a very conservative five (5) 145 forks, though if you have a lot of RAM, you can easily set this to 146 a value like 50 for increased parallelism. 147 148 Fully Qualified Collection Name (FQCN) 149 The full definition of a module, plugin, or role hosted within a collection, in the form <namespace.collection.content_name>. Allows a Playbook to refer to a specific module or plugin from a specific source in an unambiguous manner, for example, ``community.grafana.grafana_dashboard``. The FQCN is required when you want to specify the exact source of a plugin. For example, if multiple collections contain a module plugin called ``user``, the FQCN specifies which one to use for a given task. When you have multiple collections installed, the FQCN is always the explicit and authoritative indicator of which collection to search for the correct plugin for each task. 150 151 Gather Facts (Boolean) 152 :term:`Facts` are mentioned above. Sometimes when running a multi-play 153 :term:`playbook <playbooks>`, it is desirable to have some plays that 154 don't bother with fact computation if they aren't going to need to 155 utilize any of these values. Setting ``gather_facts: False`` on 156 a playbook allows this implicit fact gathering to be skipped. 157 158 Globbing 159 Globbing is a way to select lots of hosts based on wildcards, rather 160 than the name of the host specifically, or the name of the group they 161 are in. For instance, it is possible to select ``ww*`` to match all 162 hosts starting with ``www``. This concept is pulled directly from 163 :program:`Func`, one of Michael DeHaan's (an Ansible Founder) earlier 164 projects. In addition to basic globbing, various set operations are 165 also possible, such as 'hosts in this group and not in another group', 166 and so on. 167 168 Group 169 A group consists of several hosts assigned to a pool that can be 170 conveniently targeted together, as well as given variables that they 171 share in common. 172 173 Group Vars 174 The :file:`group_vars/` files are files that live in a directory 175 alongside an inventory file, with an optional filename named after 176 each group. This is a convenient place to put variables that are 177 provided to a given group, especially complex data structures, so that 178 these variables do not have to be embedded in the :term:`inventory` 179 file or :term:`playbook <playbooks>`. 180 181 Handlers 182 Handlers are just like regular tasks in an Ansible 183 :term:`playbook <playbooks>` (see :term:`Tasks`) but are only run if 184 the Task contains a ``notify`` directive and also indicates that it 185 changed something. For example, if a config file is changed, then the 186 task referencing the config file templating operation may notify 187 a service restart handler. This means services can be bounced only if 188 they need to be restarted. Handlers can be used for things other than 189 service restarts, but service restarts are the most common usage. 190 191 Host 192 A host is simply a remote machine that Ansible manages. They can have 193 individual variables assigned to them, and can also be organized in 194 groups. All hosts have a name they can be reached at (which is either 195 an IP address or a domain name) and, optionally, a port number, if they 196 are not to be accessed on the default SSH port. 197 198 Host Specifier 199 Each :term:`Play <plays>` in Ansible maps a series of :term:`tasks` (which define the role, 200 purpose, or orders of a system) to a set of systems. 201 202 This ``hosts:`` directive in each play is often called the hosts specifier. 203 204 It may select one system, many systems, one or more groups, or even 205 some hosts that are in one group and explicitly not in another. 206 207 Host Vars 208 Just like :term:`Group Vars`, a directory alongside the inventory file named 209 :file:`host_vars/` can contain a file named after each hostname in the 210 inventory file, in :term:`YAML` format. This provides a convenient place to 211 assign variables to the host without having to embed them in the 212 :term:`inventory` file. The Host Vars file can also be used to define complex 213 data structures that can't be represented in the inventory file. 214 215 Idempotency 216 An operation is idempotent if the result of performing it once is 217 exactly the same as the result of performing it repeatedly without 218 any intervening actions. 219 220 Includes 221 The idea that :term:`playbook <playbooks>` files (which are nothing 222 more than lists of :term:`plays`) can include other lists of plays, 223 and task lists can externalize lists of :term:`tasks` in other files, 224 and similarly with :term:`handlers`. Includes can be parameterized, 225 which means that the loaded file can pass variables. For instance, an 226 included play for setting up a WordPress blog may take a parameter 227 called ``user`` and that play could be included more than once to 228 create a blog for both ``alice`` and ``bob``. 229 230 Inventory 231 A file (by default, Ansible uses a simple INI format) that describes 232 :term:`Hosts <Host>` and :term:`Groups <Group>` in Ansible. Inventory 233 can also be provided via an :term:`Inventory Script` (sometimes called 234 an "External Inventory Script"). 235 236 Inventory Script 237 A very simple program (or a complicated one) that looks up 238 :term:`hosts <Host>`, :term:`group` membership for hosts, and variable 239 information from an external resource -- whether that be a SQL 240 database, a CMDB solution, or something like LDAP. This concept was 241 adapted from Puppet (where it is called an "External Nodes 242 Classifier") and works more or less exactly the same way. 243 244 Jinja2 245 Jinja2 is the preferred templating language of Ansible's template 246 module. It is a very simple Python template language that is 247 generally readable and easy to write. 248 249 JSON 250 Ansible uses JSON for return data from remote modules. This allows 251 modules to be written in any language, not just Python. 252 253 Lazy Evaluation 254 In general, Ansible evaluates any variables in 255 :term:`playbook <playbooks>` content at the last possible second, 256 which means that if you define a data structure that data structure 257 itself can define variable values within it, and everything "just 258 works" as you would expect. This also means variable strings can 259 include other variables inside of those strings. 260 261 Library 262 A collection of modules made available to :command:`/usr/bin/ansible` 263 or an Ansible :term:`playbook <playbooks>`. 264 265 Limit Groups 266 By passing ``--limit somegroup`` to :command:`ansible` or 267 :command:`ansible-playbook`, the commands can be limited to a subset 268 of :term:`hosts <Host>`. For instance, this can be used to run 269 a :term:`playbook <playbooks>` that normally targets an entire set of 270 servers to one particular server. 271 272 Local Action 273 A local_action directive in a :term:`playbook <playbooks>` targeting 274 remote machines means that the given step will actually occur on the 275 local machine, but that the variable ``{{ ansible_hostname }}`` can be 276 passed in to reference the remote hostname being referred to in that 277 step. This can be used to trigger, for example, an rsync operation. 278 279 Local Connection 280 By using ``connection: local`` in a :term:`playbook <playbooks>`, or 281 passing ``-c local`` to :command:`/usr/bin/ansible`, this indicates 282 that we are managing the local host and not a remote machine. 283 284 Lookup Plugin 285 A lookup plugin is a way to get data into Ansible from the outside world. 286 Lookup plugins are an extension of Jinja2 and can be accessed in templates, for example, 287 ``{{ lookup('file','/path/to/file') }}``. 288 These are how such things as ``with_items``, are implemented. 289 There are also lookup plugins like ``file`` which loads data from 290 a file and ones for querying environment variables, DNS text records, 291 or key value stores. 292 293 Loops 294 Generally, Ansible is not a programming language. It prefers to be 295 more declarative, though various constructs like ``loop`` allow 296 a particular task to be repeated for multiple items in a list. 297 Certain modules, like :ref:`yum <yum_module>` and :ref:`apt <apt_module>`, actually take 298 lists directly, and can install all packages given in those lists 299 within a single transaction, dramatically speeding up total time to 300 configuration, so they can be used without loops. 301 302 Modules 303 Modules are the units of work that Ansible ships out to remote 304 machines. Modules are kicked off by either 305 :command:`/usr/bin/ansible` or :command:`/usr/bin/ansible-playbook` 306 (where multiple tasks use lots of different modules in conjunction). 307 Modules can be implemented in any language, including Perl, Bash, or 308 Ruby -- but can leverage some useful communal library code if written 309 in Python. Modules just have to return :term:`JSON`. Once modules are 310 executed on remote machines, they are removed, so no long running 311 daemons are used. Ansible refers to the collection of available 312 modules as a :term:`library`. 313 314 Multi-Tier 315 The concept that IT systems are not managed one system at a time, but 316 by interactions between multiple systems and groups of systems in 317 well defined orders. For instance, a web server may need to be 318 updated before a database server and pieces on the web server may 319 need to be updated after *THAT* database server and various load 320 balancers and monitoring servers may need to be contacted. Ansible 321 models entire IT topologies and workflows rather than looking at 322 configuration from a "one system at a time" perspective. 323 324 Namespace 325 The first part of a fully qualified collection name, the namespace usually reflects a functional content category. Example: in ``cisco.ios.ios_config``, ``cisco`` is the namespace. Namespaces are reserved and distributed by Red Hat at Red Hat's discretion. Many, but not all, namespaces will correspond with vendor names. See `Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_ on the Galaxy docsite for namespace requirements. 326 327 Notify 328 The act of a :term:`task <tasks>` registering a change event and 329 informing a :term:`handler <handlers>` task that another 330 :term:`action` needs to be run at the end of the :term:`play <plays>`. If 331 a handler is notified by multiple tasks, it will still be run only 332 once. Handlers are run in the order they are listed, not in the order 333 that they are notified. 334 335 Orchestration 336 Many software automation systems use this word to mean different 337 things. Ansible uses it as a conductor would conduct an orchestra. 338 A datacenter or cloud architecture is full of many systems, playing 339 many parts -- web servers, database servers, maybe load balancers, 340 monitoring systems, continuous integration systems, and so on. In 341 performing any process, it is necessary to touch systems in particular 342 orders, often to simulate rolling updates or to deploy software 343 correctly. Some system may perform some steps, then others, then 344 previous systems already processed may need to perform more steps. 345 Along the way, emails may need to be sent or web services contacted. 346 Ansible orchestration is all about modeling that kind of process. 347 348 paramiko 349 By default, Ansible manages machines over SSH. The library that 350 Ansible uses by default to do this is a Python-powered library called 351 paramiko. The paramiko library is generally fast and easy to manage, 352 though users who want to use Kerberos or Jump Hosts may wish to switch 353 to a native SSH binary such as OpenSSH by specifying the connection 354 type in their :term:`playbooks`, or using the ``-c ssh`` flag. 355 356 Playbooks 357 Playbooks are the language by which Ansible orchestrates, configures, 358 administers, or deploys systems. They are called playbooks partially 359 because it's a sports analogy, and it's supposed to be fun using them. 360 They aren't workbooks :) 361 362 Plays 363 A :term:`playbook <playbooks>` is a list of plays. A play is 364 minimally a mapping between a set of :term:`hosts <Host>` selected by a host 365 specifier (usually chosen by :term:`groups <Group>` but sometimes by 366 hostname :term:`globs <Globbing>`) and the :term:`tasks` which run on those 367 hosts to define the role that those systems will perform. There can be 368 one or many plays in a playbook. 369 370 Pull Mode 371 By default, Ansible runs in :term:`push mode`, which allows it very 372 fine-grained control over when it talks to each system. Pull mode is 373 provided for when you would rather have nodes check in every N minutes 374 on a particular schedule. It uses a program called 375 :command:`ansible-pull` and can also be set up (or reconfigured) using 376 a push-mode :term:`playbook <playbooks>`. Most Ansible users use push 377 mode, but pull mode is included for variety and the sake of having 378 choices. 379 380 :command:`ansible-pull` works by checking configuration orders out of 381 git on a crontab and then managing the machine locally, using the 382 :term:`local connection` plugin. 383 384 Push Mode 385 Push mode is the default mode of Ansible. In fact, it's not really 386 a mode at all -- it's just how Ansible works when you aren't thinking 387 about it. Push mode allows Ansible to be fine-grained and conduct 388 nodes through complex orchestration processes without waiting for them 389 to check in. 390 391 Register Variable 392 The result of running any :term:`task <tasks>` in Ansible can be 393 stored in a variable for use in a template or a conditional statement. 394 The keyword used to define the variable is called ``register``, taking 395 its name from the idea of registers in assembly programming (though 396 Ansible will never feel like assembly programming). There are an 397 infinite number of variable names you can use for registration. 398 399 Resource Model 400 Ansible modules work in terms of resources. For instance, the 401 :ref:`file module <file_module>` will select a particular file and ensure 402 that the attributes of that resource match a particular model. As an 403 example, we might wish to change the owner of :file:`/etc/motd` to 404 ``root`` if it is not already set to ``root``, or set its mode to 405 ``0644`` if it is not already set to ``0644``. The resource models 406 are :term:`idempotent <idempotency>` meaning change commands are not 407 run unless needed, and Ansible will bring the system back to a desired 408 state regardless of the actual state -- rather than you having to tell 409 it how to get to the state. 410 411 Roles 412 Roles are units of organization in Ansible. Assigning a role to 413 a group of :term:`hosts <Host>` (or a set of :term:`groups <group>`, 414 or :term:`host patterns <Globbing>`, and so on) implies that they should 415 implement a specific behavior. A role may include applying certain 416 variable values, certain :term:`tasks`, and certain :term:`handlers` 417 -- or just one or more of these things. Because of the file structure 418 associated with a role, roles become redistributable units that allow 419 you to share behavior among :term:`playbooks` -- or even with other users. 420 421 Rolling Update 422 The act of addressing a number of nodes in a group N at a time to 423 avoid updating them all at once and bringing the system offline. For 424 instance, in a web topology of 500 nodes handling very large volume, 425 it may be reasonable to update 10 or 20 machines at a time, moving on 426 to the next 10 or 20 when done. The ``serial:`` keyword in an Ansible 427 :term:`playbooks` control the size of the rolling update pool. The 428 default is to address the batch size all at once, so this is something 429 that you must opt-in to. OS configuration (such as making sure config 430 files are correct) does not typically have to use the rolling update 431 model, but can do so if desired. 432 433 Serial 434 .. seealso:: 435 436 :term:`Rolling Update` 437 438 Sudo 439 Ansible does not require root logins, and since it's daemonless, 440 definitely does not require root level daemons (which can be 441 a security concern in sensitive environments). Ansible can log in and 442 perform many operations wrapped in a sudo command, and can work with 443 both password-less and password-based sudo. Some operations that 444 don't normally work with sudo (like scp file transfer) can be achieved 445 with Ansible's :ref:`copy <copy_module>`, :ref:`template <template_module>`, and 446 :ref:`fetch <fetch_module>` modules while running in sudo mode. 447 448 SSH (Native) 449 Native OpenSSH as an Ansible transport is specified with ``-c ssh`` 450 (or a config file, or a directive in the :term:`playbook <playbooks>`) 451 and can be useful if wanting to login via Kerberized SSH or using SSH 452 jump hosts, and so on. In 1.2.1, ``ssh`` will be used by default if the 453 OpenSSH binary on the control machine is sufficiently new. 454 Previously, Ansible selected ``paramiko`` as a default. Using 455 a client that supports ``ControlMaster`` and ``ControlPersist`` is 456 recommended for maximum performance -- if you don't have that and 457 don't need Kerberos, jump hosts, or other features, ``paramiko`` is 458 a good choice. Ansible will warn you if it doesn't detect 459 ControlMaster/ControlPersist capability. 460 461 Tags 462 Ansible allows tagging resources in a :term:`playbook <playbooks>` 463 with arbitrary keywords, and then running only the parts of the 464 playbook that correspond to those keywords. For instance, it is 465 possible to have an entire OS configuration, and have certain steps 466 labeled ``ntp``, and then run just the ``ntp`` steps to reconfigure 467 the time server information on a remote host. 468 469 Task 470 :term:`Playbooks` exist to run tasks. Tasks combine an :term:`action` 471 (a module and its arguments) with a name and optionally some other 472 keywords (like :term:`looping directives <loops>`). :term:`Handlers` 473 are also tasks, but they are a special kind of task that do not run 474 unless they are notified by name when a task reports an underlying 475 change on a remote system. 476 477 Tasks 478 A list of :term:`Task`. 479 480 Templates 481 Ansible can easily transfer files to remote systems but often it is 482 desirable to substitute variables in other files. Variables may come 483 from the :term:`inventory` file, :term:`Host Vars`, :term:`Group 484 Vars`, or :term:`Facts`. Templates use the :term:`Jinja2` template 485 engine and can also include logical constructs like loops and if 486 statements. 487 488 Transport 489 Ansible uses :term:``Connection Plugins`` to define types of available 490 transports. These are simply how Ansible will reach out to managed 491 systems. Transports included are :term:`paramiko`, 492 :term:`ssh <SSH (Native)>` (using OpenSSH), and 493 :term:`local <Local Connection>`. 494 495 When 496 An optional conditional statement attached to a :term:`task <tasks>` that is used to 497 determine if the task should run or not. If the expression following 498 the ``when:`` keyword evaluates to false, the task will be ignored. 499 500 Vars (Variables) 501 As opposed to :term:`Facts`, variables are names of values (they can 502 be simple scalar values -- integers, booleans, strings) or complex 503 ones (dictionaries/hashes, lists) that can be used in templates and 504 :term:`playbooks`. They are declared things, not things that are 505 inferred from the remote system's current state or nature (which is 506 what Facts are). 507 508 YAML 509 Ansible does not want to force people to write programming language 510 code to automate infrastructure, so Ansible uses YAML to define 511 :term:`playbook <playbooks>` configuration languages and also variable 512 files. YAML is nice because it has a minimum of syntax and is very 513 clean and easy for people to skim. It is a good data format for 514 configuration files and humans, but also machine readable. Ansible's 515 usage of YAML stemmed from Michael DeHaan's first use of it inside of 516 Cobbler around 2006. YAML is fairly popular in the dynamic language 517 community and the format has libraries available for serialization in 518 many languages (Python, Perl, Ruby, and so on). 519 520.. seealso:: 521 522 :ref:`ansible_faq` 523 Frequently asked questions 524 :ref:`working_with_playbooks` 525 An introduction to playbooks 526 :ref:`playbooks_best_practices` 527 Tips and tricks for playbooks 528 `User Mailing List <https://groups.google.com/group/ansible-devel>`_ 529 Have a question? Stop by the google group! 530 `irc.libera.chat <https://libera.chat/>`_ 531 #ansible IRC chat channel 532