Best Method for supporting RESTful Appliance with Foreman

Problem:
I have 100+ remote locations. In each of those locations I have 4 devices: ESXi, CentOS7, FreeBSD, and a purpose-built appliance that only accepts API calls. The devices that operate from API calls are managed from the CentOS7 device and has the information needed to connect and manage. I want to conform and manage the API based device based on centralized configs so that if they get altered by an end user they are reverted, or if we need to deploy new configs to all 100 sites we don’t have to script it manually or run it on the side. I’m very comfortable scripting in python. Ruby is completely foreign to me. I have a couple templates setup I managed to make work but they are sketchy at best.

Expected outcome:
Manage the API hosts by setting common things like time zone, default user list, reports, etc… Coding the process in python is something I’m comfortable with, creating factor items, or ruby scripts is out of skill set. I’m willing to learn enough to get by if I absolutely have to.

Foreman and Proxy versions:
1.22 for all versions. Running on CentOS7

I’ve been toying with the idea of having a cron job that runs ever 30 mins that pulls the current API config data and compares it to a config file on the local server. If they are different, then the cron job updates the API target data to match. If they are the same, it reports no change. My struggle with this approach is that I’m creating a layer of troubleshooting between foreman/puppet and the API target. The advantage is I can use the tools I know well and the puppet checks are simpler (maintain the configuration file)… also the VPN I’m coming across won’t have a latency impact on the calls.

Hello and welcome to the community!
Thank you for taking the time to share with us an overview of what you’re hoping to achieve.

Dare I ask: why don’t you upgrade?

You certainly may dare, though I can’t claim to have “good” reasons, justs “reasons” ranging from: I need to migrate the database as I’m using Postgres instead of MySQL, my puppet code ranges from “wth is this?” to “I think I got it” to “nope, that was wrong, lemme fake it…”, so I have concerns about my modules surviving an upgrade…

You know, general IT tomfoolery. A complete rebuild from scratch is on the s*** list, I just haven’t gotten there yet because… you know, life.

Is there a compelling reason related to my question why an upgrade would be beneficial to solving my appliance problem?

What you may be able to do is use Remote Execution with custom Ansible playbooks. Remote Execution would receive the host parameters and you can convert that to API calls. Perhaps even write some custom Ansible module (in Python) to make it idempotent.

You may have to abuse the local connection that Ansible has to not SSH into the machine.

1 Like

Thanks for the suggestion. I think you’re thinking along the lines of my python cron-job that self-checks itself against a local config file. I can control the python script, cron job, and contents of the config files via puppet using the existing configuration, that’s why I was leaning that direction.

I think the only thing I’d really like that it is missing is a feedback loop to know that the configuration was applied sucessfully or if it gets changed. I suppose if I maintain two files. One with the running config and one with the desired config and then leverage puppet to “enforce” the desired config.

Thinking out loud, I’d want to make sure that I have some sort of failsafe if one of the files is corrupted so that a bad config doesn’t get applied… Thanks for the feedback, will need to keep noodling it but I think I have the bones of it.

If you use the Remote Execution plugin, it should be able to decide if the command was successful. If all you need is green/red, that should give you that because there is a host status as well that indicates it. REX jobs can be scheduled inside Foreman itself giving you the continuous run status.

1 Like