Reloading configuration in running apps

[Perry The Cynic]

I'm up to about ten "apps" running on my TrueNAS mini now, and they're mostly well-behaved and happy. When I change a configuration file for an app (mapped to a host path) - not the app's "internal" configuration through its UI - I usually need to then tell the app to reload its stuff. The actual commands differ - kill -HUP 1, rndc reload, apachectl graceful, etc. But they all require that I run some simple command inside the app's container.

There's perfectly fine UI for this: click the "get a shell" button in the app's panel and type in the relevant command. But what's the API for this? I searched far and wide and couldn't find it in the REST API; is it some midclt madness that only True TrueNAS Experts know how to find? (In which case, please help me out here...) To be clear, I want to automate this (from a GitOps harness that actually manages the configuration files), so "type this into a terminal window" isn't a good answer.

(There's also the option to find the pod's name and kubectl exec the command, but I assume that's a violation of the sacred API boundary...)

So... what are my options?

Thanks
-- perry

 

[sfatula]

I generally stop and restart the app, I don't generally care to manage each app differently. I think that's your only alternative as I don't think truenas can know for each app how to reload it's config.

Stopping and starting the app is contrallable via api.

 

[Perry The Cynic]

I know how to reload each app. I just don't have an API way to execute the command for it. I don't expect TrueNAS to have a "magically know how to reload this app" function. I do expect them to have a "run this shell command in that app" function that doesn't involve me typing on the screen each time.

Granted, stopping and starting would work, but it would also kick out all its clients each time. The whole point of a "reload" function is to reconfigure the service without stopping it.

Cheers
-- perry

 

[sfatula]

Ok, more information then. So, you have apps that have clients you don't want to kick out, none of my 15 apps are that way, I just restart them when wife or I not using them. So, the solution is kubectl exec commands, there is no violation there that I am aware of. Yes, I am fully aware of reload vs restart just was not aware of your concern.

To stop an app via api as an example:

/usr/bin/midclt call chart.release.scale $app '{"replica_count": 0}'

Where $app is the name of you app you assigned to it. Use replica count 1 to bring it back up. I actually stop all of my apps on any shutdown or reboot. And I start them in a specific order on startup, all automatic.

 

[Perry The Cynic]

I have some services that (a) take a long time to start and (b) have ongoing clients that I don't want to get kicked every time I reconfigure things.

Take Apache as practical example: "apachectl reload" tells Apache (the web server) to re-read its configuration and apply it to new connections while keeping existing connections chugging along. From the clients' perspective, this means there is never a time when Apache won't accept new connections or service existing ones. The same applies to gitlab (which takes roughly a minute to fully spool up from a standing start).

I do know how to bounce (stop/start) a service, both from midclt and REST API. That's reasonably well supported.

It is the "run this simple shell invocation inside the app's container" function that eludes me. Other than going the k3s-inside-TrueNAS route, I don't know of a way to do it. If that's okay with the platform guardians (well, in practice it would be "run kubectl with credentials exported into a container", which amounts to the same thing), I can do that fairly easily. I was under the impression that direct use of kubectl & friends was a violation of the API boundary. Am I wrong?

Cheers
-- perry

 

[sfatula]

I am not IX, but I've seen them recommend in these forums kubectl commands for executing things within containers, so, my opinion is it's fine. It's certainly harmless for things like restarting Aoache or anything like it, running cron jobs without having cron in the container (so scheduled at the Scale level), etc.

 

[Perry The Cynic]

Thank you for setting my mind at (somewhat) ease. I'll go that way.

Cheers
-- perry