{"dataset":{"id":"00000000-0000-0000-0000-000000000043","slug":"ansible-best-practices","name":"Ansible best practices","description":"Source-linked guidance on Ansible fundamentals: playbooks, inventory, variable precedence, handlers, and roles. Scoped to Ansible community documentation; not a general IT automation corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Roles: directory structure and content organization","sourceUrl":"https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html","text":"An Ansible role has a defined directory structure with seven main standard directories; you must include at least one in each role and can omit any the role does not use. By default, Ansible looks in most role directories for a main.yml file — also main.yaml and main — for relevant content. tasks/main.yml lists the tasks the role provides to the play for execution; handlers/main.yml holds handlers imported into the parent play; defaults/main.yml provides very low-precedence variable values that any other variable source overrides, while vars/main.yml provides high-precedence variables. files/ holds one or more files available to the role and its children, and templates/ holds templates, which end in .j2. meta/main.yml carries metadata including role dependencies and optional Galaxy metadata such as supported platforms — required for uploading into Galaxy as a standalone role, but not for using the role in a play. None of the files are required: a role can provide only files/ or vars/ content and still be valid, and roles can also include custom modules in library/ or plugins such as lookup_plugins/. Scope: Ansible. Reviewed October 4, 2026.","id":"ansible-best-practices:Roles: directory structure and content organization","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Handlers: running operations on change","sourceUrl":"https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html","text":"When a task should run only when a change is made on a machine — for example, restarting a service only if a task updated that service's configuration — Ansible uses handlers, which are tasks that run only when notified. Tasks instruct one or more handlers to execute using the notify keyword, which accepts a list of handler names or a single string; handlers run on task change, after all tasks are completed in the play. Handlers execute in the order they are defined in the handlers section, not in the order listed in the notify statement. Notifying the same handler multiple times results in the handler executing only once, regardless of how many tasks notify it — if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible bounces Apache once to avoid unnecessary restarts. Tasks can also use loops to notify handlers, which is useful with variables for dynamic notifications; with a loop, the changed state is set if any of the loop items changed, so any change triggers all of the handlers. Scope: Ansible. Reviewed October 4, 2026.","id":"ansible-best-practices:Handlers: running operations on change","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Understanding variable precedence","sourceUrl":"https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html","text":"Ansible applies variable precedence from least to greatest: role defaults sit lowest, followed by inventory file or script group vars, inventory and playbook group_vars, inventory file or script host vars, inventory and playbook host_vars, host facts and cached set_facts, play vars, vars_prompt, vars_files, role vars, block vars, task vars, include_vars, registered vars and set_facts, role and include_role params, and include params; extra vars, passed with -e, always win. Command-line values such as -u my_user are not variables. In general, Ansible gives precedence to variables defined more recently, more actively, and with more explicit scope. Variables in a role's defaults folder are easily overridden, while anything in the role's vars directory overrides previous versions of that variable in the namespace; explicit includes such as include_vars tasks override inventory variables. Ansible merges variables set in inventory so more specific settings override more generic ones — for example, ansible_ssh_user set as a group_var is overridden by ansible_user set as a host_var. Within any section, redefining a var overrides the previous instance. Scope: Ansible. Reviewed October 4, 2026.","id":"ansible-best-practices:Understanding variable precedence","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"How to build your inventory","sourceUrl":"https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html","text":"Ansible automates tasks on managed nodes, or hosts, using a list or group of lists known as inventory, composed from one or more inventory sources. Inventory defines the managed nodes, their associated variables, and groups, which let you target multiple associated hosts or define variables in bulk; once defined, patterns select the hosts or groups to run against. The default inventory file location is /etc/ansible/hosts, and you can specify a different source at the command line with the -i option or through the configuration system. The most common formats are INI and YAML because Ansible includes built-in support for them; INI uses headings in brackets as group names, and group names should follow the same guidelines as creating valid variable names. As inventory expands, you can generate it dynamically with inventory plugins, pass multiple sources, or organize sources in a directory. Any host that is a member of a child group is automatically a member of the parent group, groups cannot have circular relationships, and hosts and groups are always global — redefining one adds or overwrites information on the same entity. Scope: Ansible. Reviewed October 4, 2026.","id":"ansible-best-practices:How to build your inventory","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Playbooks: plays, tasks, and idempotency","sourceUrl":"https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html","text":"Ansible playbooks provide a repeatable, reusable configuration management and multimachine deployment system, expressed in YAML with a minimum of syntax. A playbook is an ordered list of plays, and each play runs one or more tasks that call Ansible modules; both plays and tasks execute from top to bottom. At a minimum, each play defines the managed nodes to target, using a pattern, and at least one task to execute. For Ansible 2.10 and later, use the fully-qualified collection name (FQCN) so the correct module is selected when multiple collections ship modules with the same name. Most modules check whether the desired final state has already been achieved and exit without performing any actions if it has — modules that behave this way are idempotent, so running a playbook once or multiple times should produce the same outcome. Not all modules behave this way, so test playbooks in a sandbox environment before repeating them in production. Pass -C or --check to ansible-playbook for check mode, which reports the changes it would have made without altering systems. Scope: Ansible. Reviewed October 4, 2026.","id":"ansible-best-practices:Playbooks: plays, tasks, and idempotency","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}