Hey everyone, we’re looking for a way to export rendered Icinga2 config without using director. Our current config files have become a bit cluttered, and we’d like to clean them up by organizing them by type, similar to how director structures files. Ideally, we’d like to create separate files for each object type, such as:
hosts.conf
host-templates.conf
services.conf
… and so on, for each zone
If anyone knows of a method to achieve this, it would be greatly appreciated!
Any tips or suggestions are welcome.
Since Icinga Director is the only config tool, I think your are out of luck finding any other solution than writing some custom parsing scripts.
But here are some thoughts:
Use Icinga Director to build a configuration from your original one and deploy that to a dummy Icinga environment. Fetch the config files and sync it to your prod environment.
After some time you might want to migrate to Icinga Director anyway and your can do that easily since your config is already there.
Thanks for your question. While I am not quite certain that it does exactly what you want, you can query all Objects from Icinga 2 via icinga2 object list, as further described under Troubleshooting, List Configuration Objects.
The output is more similar to an object tree, but it may be good enough for you to be used as the input for a script to generate something you desire.
By the way, the reason why Icinga 2 cannot just dump its config as its DSL is because the configuration is being interpreted. Thus, all files from /etc/icinga2/ are being parsed and interpreted, put into its internal state. Part of this interpretation is, e.g., including templates. This state might be further altered via changes through the API, e.g, by the Director.
Thus, you might want to start by having a look at icinga2 object list --type Host. However, I don’t think you can recreate something you want to put in a host-templates.conf, due to the config interpretation described above.
I have just reread the OP and especially this sentence stuck with me. Before, I somehow assumed the setup to be a mix of a config-based setup and some “on-the-fly” changes.
However, may it be that everything in your setup is based on Icinga 2 “DSL” configuration files, but those files got a bit messy over the time?
If this is the case, I would suggest first catting all configs (within their respective zone) together, than splitting them based on their type, which is usually at the line start, maybe after an apply. As each Object or apply rule comes with its block being in curly brackets ({ … }), this may be easy to automate, e.g., via a vim macro.
I’ve started to lose hope that we can clean up the current configuration files, especially with the large number of contributors involved. As a result, we’re planning to migrate to Director in the future. The idea of having a clean, centralized configuration was tempting, also as preparetion for the migration, and seeing how Director provides rendered objects made me think there might be another way to achieve this. Note: we have a two icinga environments, consolidation and production with corresponding git branches.
I also discovered that the icinga2 object list command could be useful, but its output is rather challenging to sanitize.
We might consider a compromise: extracting the configuration by object types using cat as suggested, and then trying to reorganize it into a more structured format. Alternatively, we could spin up another Icinga instance, also as you suggested, to import the configuration from the core of the actual system. We could then use the rendered config output to replace the current messy setup.
However, would this approach work without replicating the entire setup? We have multiple, and even nested, configuration zones.
If the Director is going to work better in your scenario is something you have to evaluate. There are people preferring it and people preferring configuration files, potentially generated from some config management tool. I guess, it’s a question of how you work and your “culture”. Personally, especially when working with multiple persons, I prefer a repository where one can link changes line-wise to their author.
You can get similar data via the Icinga 2 API, returning easier to handle JSON data. Icinga2 Api - Icinga 2
I would suggest trying this in a test setup. For example, you can copy your whole configuration to a locally installed Icinga 2 (maybe within a container or a VM) and start refactoring there, always validating your changes. This setup does not necessarily needs to reach the agents or endpoints, as long as you only focus on the configuration refactoring while validating that the changes still can get parsed by Icinga 2. Then, you could migrate the changes bit-by-bit to your production setup.
Otherwise, to be sure, a testing or staging environment may help.
