unit 1 · Orientation
Collections & FQCN
Why old tutorials lie to you
you may want to read 3 · ansible-core vs the community package first — but nothing is locked
tl;dr
- Since Ansible 2.10, modules live in collections — versioned packages under a namespace.
- FQCN is the full path: ansible.builtin.copy, not copy. Write it always.
- Old tutorials use bare names because they predate the split. That is how you date them.
why it matters Half the Ansible answers on the internet predate collections; if you can’t spot pre-2.10 content, you’ll copy patterns your linter rejects and your colleagues left behind years ago.
Up to Ansible 2.9, every module shipped in one monolithic package — three thousand–plus modules, versioned and released together. Ansible 2.10 broke that monolith into collections: independently versioned packages, each owning its modules, roles and plugins under a namespace. The community package from last lesson is really ansible-core plus 85+ curated collections.
That split created the FQCN — the full path to a module:
- name: Push the MOTD file
ansible.builtin.copy:
src: files/motd
dest: /etc/motdRead it right-to-left: the copy module, in the builtin collection,
published under the ansible namespace . Three FQCNs you’ll
meet constantly: ansible.builtin.service, community.general.ufw,
ansible.windows.win_copy. That last pair matters: Linux and Windows modules
live in different collections.
Why old tutorials lie to you
Most tutorials, blog posts and Stack Overflow answers predate the split. They use bare module names — before 2.10 that’s all there was:
- name: Push the MOTD file
copy:
src: files/motd
dest: /etc/motdThe trap: that still runs. Modules from the 2.9 era keep resolving through a redirect mapping, so old playbooks didn’t break. Bare names don’t fail loudly — they quietly date your YAML and set you up for two real problems.
Getting collections you don’t have
pip install ansible already gave you the big bundle. When a playbook needs
a collection outside it (or you’re on bare ansible-core), install it by
namespace and name:
ansible-galaxy collection install community.generalLesson 26 covers pinning these in requirements.yml so every machine — and
the CI runner — gets identical versions. For now, one habit: when you see a
module in the wild, read its namespace first. It tells you who maintains it
and what you need installed before anything runs.
at work, this sounds like
- “Use the FQCN or lint will fail the PR.”
- Write ansible.builtin.copy, not copy — the CI linter enforces full module paths.
- “Is that module in ansible.windows or community.windows?”
- Which collection ships it — you may need to install a different one to use it.
self-check — recall, not a test
1 What are the three parts of an FQCN, in order?
2 A tutorial writes “- copy:” with no dots. Roughly when was it written, and why does it still run?
3 Why does ansible-lint care?
lab (optional — never required)
Run one ad-hoc ping twice — once as “ping”, once as “ansible.builtin.ping” — and confirm they resolve to the same module with ansible-doc.
needs: Any control node from lesson 5 (a Linux VM or container with ansible installed).