My Ansible roles for Rocky Linux

Rocky Linux Help & Support
1

Hi,

I’ve started to publish a handful of Ansible roles for Rocky Linux on GitLab. Here for example:

I’m relatively new to this. Before going any further and writing more roles in the days and weeks (and months) to come, I thought I’d ask. Does this seem to fit the current standards? Do you have any suggestions in regard to best practices? Did I miss something?

So far this works OK. I can import the roles in my playbooks using a requirements.yml file, so stuff is much more modular and reusable.

Any suggestions ?

Niki

1 Like
2

Nice.

You do remove some *.repo files that are from packages? Package update would re-install them.
Then again, edit of those files (to wipe them empty, for example) will make the potential update add equivalent *.rpmnew files.

The lists of “nearby mirrors” could be in vars. Easier for other sites to override.

1 Like
3

OK noted.

Besides that, stuff in README.md and in meta/main.yml seems OK ?

4

I think the main.yml are fine. The only thing I would question are the dependencies. I’m pretty sure rpmfusion can be used without epel as a dependency. But assuming that your playbook for rpmfusion is dependent on something from both of these repositories, then that would probably explain it. However, I don’t see anything in the tasks.yml that would hint at it requiring epel as a dependency. Again with KDE, rpmfusion is mentioned as a dependency, but is it really a dependency in that the KDE tasks installs something from rpmfusion? I’m pretty sure KDE is just pulling mostly from EPEL with some distro packages from baseos or appstream. And GDM is in the distro anyway, so prob doesn’t need to be dependent on KDE.

5

One other note, is that with your tasks, you don’t need to put them in a file called main.yml, but what you can do is separate them out and make things more logical and easier to read. Here’s an example of something I did once for an app:

.
├── ansible.cfg
├── app.yml
├── files
│   └── apt
│       ├── app.list
│       ├── mssql-server.list
│       ├── mssql-tools.list
│       └── sources.list
├── inventory
├── README.md
├── tasks
│   ├── add_repos.yml
│   ├── clone_scripts.yml
│   ├── configure_cron.yml
│   ├── configure_timezone.yml
│   ├── enable_firewalld.yml
│   ├── install_deps.yml
│   ├── restart_services.yml
│   └── set_php_parms.yml
├── templates
│   └── cron_onsite.j2
└── vars
    ├── debian.yml
    ├── rhel.yml
    └── ubuntu.yml

so you can see my structure slightly different. Various task files for doing things like configuring and enabling firewall for example. The variables I separated out from the main play app.yml and depending on what distro I’m deploying the app, be it Debian, Red Hat or Ubuntu it gets configured with the specific set of variables.

Obviously for quick and simple plays, there’s no need to go crazy :slight_smile:

1 Like
6

There’s a reason for all these tweaks. This is my personal blend of KDE with quite a few customizations. KDE relies on ffmpeg, and I’m pulling in the more functional package from RPMFusion so things like thumbnails work for all video formats. SDDM doesn’t play well with NVidia drivers so I’m replacing it with my tweaked version of GDM (hence the dependency).

7

I know the method you use. Unfortunately you can’t really manage handlers with it. I have quite a few in my 200+ tasks playbook. As far as I’m concerned, roles are the way to go. (Waiting for jlehtone to chime in here.)

8

OK understood, just thought I’d mention it :slight_smile:

1 Like
9

I do have handlers in mine, they work fine with the way I’ve done it. The one I have mentioned showing the directory structure is a role, but with a load of features that it’s dealing with. Roles can be simple one-off things, but they can also be complex.

Mine does lack some of those default and main directories, but that’s just the way I’ve done it because I’m not publishing it anywhere.

10

Roles can indeed be complex and when a play does include_role it can name task-file. The System Roles (in rhel-system-roles) are clearly not simple.

This reveals another aspect. You have written the role for three different distros and its tasks probably include role-vars based on where the role is used.

The ansible-galaxy role init creates a skeleton for role – empty ‘main.yml’ in every directory.

11

Correct, a combination of when: fields with ansible_distribution, as well as going further with ansible_distribution_major_version depending on EL7 or EL8 for example.

Yup, true, I just got rid of those parts that I didn’t need, as mentioned, I’m not publishing it anywhere, so it was superfluous to my needs. But I do have roles where I have left these because I distribute them.

1 Like