The top 100 Ansible modules

Ansible is an automation system which is widely used for deployments and configuration. It contains a dizzying array of modules for interfacing with things like files, services, package managers, and various pieces of software and hardware.

Background

There are some modules which I would expect every Ansible user to be familiar with, while others are barely used at all. I could have a guess about which modules I use most, but what about the wider community?

I couldn’t find any existing data, so I set out to determine which Ansible modules were most widely-used. The best source for this is Ansible Galaxy, which is a directory of around 18,000 Ansible roles. Using some scripts, I sifted through the 18,259 publicly accessible roles from Ansible Galaxy, found 71,610 files to look through, and tallied up which modules were being used by each of the 317,757 tasks in those files.

The list

These are the top 100 modules as of January 2019. I used the same method to build such a list in January 2018, so you can also see the change in popularity of some modules over the last 12 months.

Rank	Module	Uses	Rank +/-
1	file	26,224	+1
2	include	25,267	-1
3	template	24,062	–
4	command	23,952	–
5	service	19,436	–
6	shell	19,401	–
7	set_fact	17,079	+1
8	apt	16,006	+1
9	lineinfile	12,432	-2
10	copy	8,794	+1
11	yum	8,733	-1
12	assert	7,504	+7
13	include_tasks	6,686	+15
14	stat	5,922	-2
15	package	5,422	-1
16	get_url	5,323	-3
17	debug	5,147	-2
18	import_tasks	5,016	+20
19	include_vars	4,251	-2
20	apt_repository	3,789	-4
21	user	3,233	-3
22	fail	2,812	+2
23	unarchive	2,734	-2
24	apt_key	2,665	-4
25	pip	2,474	–
26	systemd	2,389	+8
27	action	2,114	-4
28	git	2,043	-1
29	uri	1,680	+7
30	group	1,665	-1
31	sysctl	1,331	-5
32	raw	1,323	-2
33	mysql_user	1,266	–
34	meta	1,204	+3
35	replace	1,125	-3
36	ini_file	1,125	-5
37	find	1,030	-15
38	local_action	986	-3
39	mysql_db	959	–
40	cron	925	–
41	wait_for	898	–
42	rpm_key	771	–
43	include_role	742	+15
44	yum_repository	723	+2
45	mount	669	-2
46	blockinfile	619	+3
47	firewalld	579	+1
48	ufw	563	-1
49	authorized_key	557	-4
50	docker_container	488	+2
51	dnf	455	+5
52	seboolean	417	-8
53	homebrew	409	-2
54	fetch	378	+1
55	npm	367	-5
56	osx_defaults	363	+8
57	postgresql_user	350	-4
58	pkgng	345	-4
59	pause	340	+4
60	script	314	+5
61	setup	290	+7
62	postgresql_db	289	-2
63	mysql_replication	286	-1
64	win_regedit	281	+6
65	pacman	257	-4
66	debconf	256	+1
67	slurp	255	+10
68	gem	253	-11
69	iptables	240	+13
70	apache2_module	231	-4
71	synchronize	213	-2
72	docker	213	-13
73	alternatives	210	–
74	selinux	202	–
75	oc_obj	199	+98
76	make	194	-1
77	win_shell	191	+13
78	modprobe	187	+11
79	hostname	181	-7
80	zypper	174	-4
81	xml	160	–
82	supervisorctl	160	-11
83	win_file	149	+15
84	homebrew_cask	149	-6
85	add_host	144	-2
86	rabbitmq_user	129	-7
87	pamd	124	+81
88	win_command	116	+13
89	assemble	116	-9
90	htpasswd	115	-6
91	apk	112	-5
92	openbsd_pkg	111	-7
93	win_get_url	109	+14
94	win_chocolatey	109	–
95	docker_image	109	+4
96	tempfile	106	+25
97	locale_gen	105	-5
98	easy_install	97	-10
99	django_manage	97	-3
100	composer	96	-3

Out of over 2,500 modules mentioned in Ansible Galaxy, it turns out that only a few dozen are widely used. Following this, there is a long tail of infrequently-used and custom modules.

How many modules do I need to know?

You can write 80% of the roles in Ansible Galaxy using only the 74 most popular Ansible modules.

For writing an individual Ansible role, you don’t need anywhere near this many. The median number of modules used by an role in Ansible Galaxy is just 6.

There are a few reasons that you won’t need to use many popular modules all at the same time:

• Different technologies: eg. mysql_db and postgresql_db set up different databases, and would be invoked by different roles if you need both.
• Obsolete modules: eg. docker has been split up, and new code will use docker_container instead.
• Different levels of abstraction: eg. cross-platform developers will use the package module, while develpers who know their platform may directly use the apt, dnf and yum modules. You are unlikely to see these mixed.
• Different styles: include_tasks vs. import_tasks.

Some notes

Here are some things to keep in mind when reading the table.

• I skipped any role that was not hosted in a public GitHub repository, or could not be parsed. A php-yaml bug also kept a few files out of the 2019 tally.
• Each task was counted only once, so local_action and action are obscuring which modules were eventually executed.
• The OpenShift oc_obj module on this list is not bundled with Ansible (the module itself is distributed through Galaxy).
• I did not attempt to exclude abandoned or incomplete packages. Eg. The docker module on this list has been removed from the latest version, but remains popular in existing Ansible Galaxy roles.