Hands-on Lab·Ansible
Ansible Playbooks in Git
add, commit, push is three commands. The part specific to Ansible is what must never go in: a .vault_pass file committed once is in the history for good, and git check-ignore -v is how you prove a rule actually covers it before you find out the hard way.
Templates, Files and Vault Guide 23 of 45 Beginner
- OSUbuntu 26.04 LTS
- ansible-core2.20.1
- Python3.14.4
- TimeAbout 13 min
git check-ignore -v prints the file, line number and pattern that matched. It is the only way to be certain which rule is doing the work when a .gitignore has several that could.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| ANS-CTL01 | 192.168.0.36 | Ubuntu 26.04 LTS | Ansible Control Node | 2 Core | 3 GB | 50 GB |
| ANS-B01 | 192.168.0.38 | Ubuntu 26.04 LTS | Managed Node (group: db) | 2 Core | 3 GB | 50 GB |
This guide includes
Use this when playbooks have to live in Git. This matters because add, commit and push are only three commands - and the files that must never be committed are the part worth being deliberate about.
- staging and committing, and reading the two columns of
git status --short - identifying the four patterns that must never be committed, and why each is there
- getting the first push through, past the branch-name failure
- reviewing with
git diff --statbefore committing
Before you start
- A control node configured as shown in the first step.
- The repository from the cloning guide, or any clone you can push to.
-
The configuration this guide assumes
-
Stage and commit
-
The files that must never be committed
-
Push it
-
Change, review, commit