Best practice for managing a large configuration file in a role

Get Help
1

I’m a bit of a hobbyist, working on a collection to deploy Gitea and related tools.

One thing I struggle with, is the astoundingly large set of configuration options for Gitea. It’s 600+ options long in a 2500+ line config file. For another collection I built (for atuin), it was relatively easy to template the whole configuration file, and put all options with their default values in defaults/main.yml.

However, I’m not looking forward to doing this with a 2,500 line ini file. Alternatively, I could work with the lineinfile or general_ini modules (which would save me from templating the config file, I think), but that might become unwieldly with 2,500 lines of config file.

Or I could do what I’ve seen in some other places, which is basically say: put the contents of your desired config file in a variable, and let the role use that to populate a config file. So basically a one variable template. But that feels like a shortcut that isn’t very helpful to new users.

What is considered best practice in this context? Ideally, I would not want people to have to write their configuration file in a variable, and ideally I don’t want to maintain a 2,500 line configuration file template.

I guess I could script much of templating the config file, but before I set about doing that, I would appreciate some input…

2

I’d use the from_ini to read the file (or community.general.jc with the JC ini parsers if that isn’t suitable, for example due to the lack of support for ini files without section headers or duplicates).

And community.general.ini_file to write the file.

However perhaps community.general.ini_file with only a path argument would also work for reading the file as well as writing it?

Suggesting that people use JC on the command line to read the INI file as YAML for the config is also something to consider, eg:

cat gitea.ini | jc --ini -yp

In order to get all their existing config into Ansible.

This way you could only have the variables in Ansible that you want to change in the role defaults, eg:

gitea_conf:
  foo: bar

And it would also work with all the 600+ options if people want to add them.

Templating the file sounds like too much of a PITA especially if config options available change with versions etc…

Also note that recent versions of the ini_file module have a modify_inactive_option which really helps with keeping large files (I’m thinking PHP and MariaDB config files) that are updated using Ansible also human readable (I have been using line_infile to remove the commented version of the option before updating the files using ini_file and need to update my roles to use modify_inactive_option ).

3 Likes