Roles, secrets, and check mode

Package behavior that has a clear purpose

A role groups tasks, templates, defaults, files, and handlers using a conventional directory structure. The play still selects hosts; the role provides reusable behavior. For the marker exercise, a role might promise: “Write one non-secret configuration file in the current user's home, with an integer port and mode 0600.” That is a more useful interface than “run these miscellaneous tasks.”

Sketch this layout in your notes before moving files:

roles/study_marker/
  defaults/main.yml
  tasks/main.yml
  handlers/main.yml
  templates/study.conf.j2

The play variables become overridable role defaults. The entries under tasks move into tasks/main.yml without the enclosing play. The handler list moves into handlers/main.yml. The template keeps its contents. A play can then select hosts: study, gather facts, and include roles: [study_marker]. The optional lab extension performs that refactor; first learn how to preview the current complete playbook.

Read a preview as a prediction

From ansible-practice, with the inventory and site.yml from the previous lesson:

ansible-playbook -i inventory.ini site.yml --syntax-check
ansible-playbook -i inventory.ini site.yml --limit study-vm --check --diff

Syntax checking catches structural problems but does not prove target access or application correctness. Check mode asks supporting modules to predict changes. Diff mode shows content differences for supported operations. The marker contains no secrets, so its small before/after text is useful to inspect.

Change the play's study_port to 8081, preview, and read the remote file without applying. Expected: a proposed port change, while the actual file retains its earlier port. Restore 8080 afterward. If the destination never existed, a preview may show its proposed contents without creating it.

Check mode is not a universal sandbox. Modules vary in support; some tasks are skipped, values registered by skipped tasks may be missing, and tasks with check_mode: false can still run. Review the tasks, target, and module behavior before assuming a play cannot change anything.

Protect secrets before and after decryption

Ansible Vault encrypts files or individual values at rest. A person or automation process with the decryption key can read them during execution. Encryption in Git therefore does not prevent disclosure through task output, diff output, destination files, process arguments, or backups.

For a real secret-bearing task, use an appropriate secret source, limit access to decryption, restrict destination permissions, and control task logging and diffs. no_log: true suppresses task output in normal Ansible reporting, while diff: false prevents that task's diff display. Neither automatically controls every downstream process or debugging path. Do not put real credentials into this practice marker just to try encryption.

A compromised committed credential needs revocation or rotation; wrapping the same exposed value in Vault afterward does not undo exposure. Keep vault passwords outside the repository and use a deliberate delivery mechanism for automation.

Practice the review

Read the marker play and answer: which target is selected, which file changes, who owns execution, which task can notify a handler, and which output could reveal contents? The answers are study narrowed to study-vm, the user's marker file, the regular connection user, the template task, and diff output.

Would zero changes prove a service is healthy? No; it proves only that the tested modules reported no change for these inputs and state. Next, run the full scoped lab, inspect the generated file, test a changed input, and remove the fixture. Molecule, reusable collections, rolling batches, delegation, and custom plugins are later depth rather than prerequisites for this first configuration cycle.

References: roles↗, check and diff mode↗, and Ansible Vault↗.