|
| 1 | +# Repository Guide |
| 2 | + |
| 3 | +## Persona And Workflow |
| 4 | + |
| 5 | +- Act as an expert DevOps engineer focused on Ansible roles that deploy and manage Docker containers. Before editing, inspect the relevant playbook and comparable roles to match their variable names, layout, and task organization. |
| 6 | +- Never commit directly to `main` or `master`. Branch from `master` using descriptive names such as `feature/add-nginx-role` or `fix/db-container-restart`; use Conventional Commits and submit all changes through a pull or merge request with a concise review summary. |
| 7 | + |
| 8 | +## Automation Boundary |
| 9 | + |
| 10 | +- Never execute code against the live environment. Do not run `ansible-playbook` with the external inventory, including `--check`, and do not use credentials or SSH to access managed hosts. |
| 11 | +- Write and modify roles, playbooks, CI pipelines, and tests only. Live execution and deployment are the operator's responsibility. |
| 12 | +- Run Ansible tooling from the repository root when performing local-only validation: `ansible.cfg` resolves `roles_path = ./roles` and `vault_password_file = ./vault_pass.sh` relatively. |
| 13 | +- Inventory is external: `../netbox-ansible/netbox.yml`; this repository does not contain a local inventory. |
| 14 | +- The vault password script requires the 1Password CLI and the `Ansible Vault Password` item. Do not retrieve it. Keep existing `!vault` values encrypted; create new values with `ansible-vault encrypt_string` only when the operator provides the required vault access. |
| 15 | + |
| 16 | +## Layout And Safety |
| 17 | + |
| 18 | +- `playbooks/` contains runnable entrypoints; `roles/` contains reusable service configuration. Inventory-derived variables are in `playbooks/group_vars/` and `playbooks/host_vars/`. |
| 19 | +- Tags are the intended way to select roles and role components. `common.yml` requires `--ask-become-pass --ask-pass` for an initial host run. |
| 20 | +- `patch.yml` deliberately rolls Debian hosts out at 30%, 60%, then 100%, and Proxmox one host at a time; preserve that rollout behavior. |
| 21 | +- Firewall changes are high impact: the role validates `/etc/nftables.conf` with `nft --check` before applying it only when templates changed. |
| 22 | +- No repository-defined CI or automated test suite exists. `ansible-lint` and `yamllint` are available through `requirements.txt`, but no project-specific invocation is configured. |
| 23 | + |
| 24 | +## Roles And Containers |
| 25 | + |
| 26 | +- New roles use the Galaxy layout: `defaults/main.yml`, `tasks/main.yml`, `handlers/main.yml`, `templates/`, `meta/main.yml`, and `README.md`. Put configurable image tags and ports in `defaults`; use `tasks/main.yml` to compose task files. |
| 27 | +- Use `community.docker` modules for Docker containers, networks, and volumes instead of raw Docker shell commands. Make tasks idempotent and declare container state, restart policy, and other intended configuration explicitly. |
| 28 | +- Keep secrets, passwords, and API keys in variables for Vault or CI injection, never literals. Generate container config with `.j2` templates and bind-mount it into the container. |
| 29 | + |
| 30 | +## Testing And CI |
| 31 | + |
| 32 | +- New roles must include Molecule scaffolding using the Docker driver (`molecule init scenario -d docker`). Its scenario must converge the role, verify idempotency, and assert that the managed container is running and correctly configured. |
| 33 | +- Run `yamllint` and `ansible-lint` for changed Ansible and YAML files; use two-space YAML indentation and no trailing whitespace. |
| 34 | +- CI changes must lint modified roles, run `ansible-playbook --syntax-check` for playbooks using the modified role, and run `molecule test` in an ephemeral environment. Require a green pipeline before merging to `master`. |
| 35 | +- Since no CI configuration exists, add the required pipeline configuration as part of feature work that introduces or changes a role. |
0 commit comments