Bootstrapping Icinga Director - Workflow for initial deployment through automation.

  • Hi Guys,


    Can I start by saying how much I love the Icinga Director!!


    I have a query regarding director deployment that I am hoping will initiate a useful conversation for the community.


    My company has recently begun our journey in migrating our monitoring to Icinga2, we deploy everything through automated tools (Puppet, Ansible etc).


    In our initial deployment efforts, I have been resorting to a MySQL dump/restore (of a skeletal deployment with no hosts defined) in order to deploy a working hierarchy of Fields, Apply-Services, Templates, etc.


    This was fine for initial deployment but really ties our hands when it comes to revision control (we need to slowly enhance the service-monitoring options through releases).


    I have been developing some python scripts in order to deploy everything from static YAML files.


    Some example YAML (one example of each type):



    I am hitting some limitations of the API and so have resorted to building some relationships in MySQL (like the field relationships in the icinga_host_field table.).


    My main queries are:


    1. What are others using for initial deployments of director? Hand-crafting director implementations for each implementation would be very time-consuming. I imagine I am not the first person to come across this task.
    2. Where would my efforts best be directed? Should we be focusing our efforts on the "icingacli director" functionality? The icingacli CLI seems to be lagging behind the REST API in functionality (like you can't delete services from the CLI).
    3. Is there a better way of exporting a working template->apply->field hierarchy from a template environment?

    I am ready to assist with some programming effort (although I'm only really effective in Python) but I don't want to duplicate effort if there is already work underway to implement this.


    TIA,

    TechnoTaff

  • You want to deploy static config to director?

    Why would you need to do this more than once?
    What is the goal you want to achieve?

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • I currently have 8 air-gapped director implementations and that's just the beginning, this number will increase many times. We have strict environment boundaries which I can't cross.


    I really don't want to do it more than once - hence my query :)


    Our workflow is currently:


    1. Deploy Master and Satellite servers from Puppet (using the awesome puppet modules).
    2. Deploy our skeletal Director layout from a SQL restore.
    3. Add client nodes via PuppetDB, LDAP and static YAML.
  • ah ok, now I know what you want to do.


    I would suggest using the director templates instead of static yaml files.

    You can build them once and get them via the API as json files. Those can be inserted via the API.


    So you would no longer deploy a skeleton DB, just using the default DB and then inserting your stuff via the API

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • We do currently use host and service templates, sorry for my ignorance but is there another type of template that I am unaware of?


    I've been using a combination of REST and CLI calls but the API functionality doesn't currently extend to attaching fields to templates, or apply-rule option values.


    I'm trying to avoid poking things directly into MySQL, otherwise when the director team update the Schema i'll break something! :$

  • now I do understand you, when you said YAML files, I did not think, you would use them as templates in the director.


    I would have to take a closer look at the API, to determine how you could do such a thing.

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • I don't mind contributing to the development effort. I understand how things like DB schema migrate over long periods, which makes refactoring difficult.


    I would rather contribute to an organised roadmap than develop my own secret sauce.


    With everybody going DevOps it's really nice to be able to configure things from scripts/puppet, etc.

  • bodsch and me are currently trying to implement API libs in ruby and python for Icinga2 and the Director. Sadly we do not have much time besides our day jobs.

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Hi Kevin,


    I might be able to assist with this.


    Do you know if the Director DB schema/topology is documented somewhere?


    Is there a repo started for it?


    Techno

  • you are most certainly welcome to help us :) just take a look at my github Page or here https://github.com/KevinHonka/Icinga2_Python_API


    I do not think the DB schema is documented anywhere, you would have to take a look in the mysql.sql file on github

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them