This is a bit of a tricky topic with no right answer. You can run network-manager inside a container if you bindmount /var/run/dbus into that container. This will let you use the nmcli utility for basic operations. However, I’m unaware of the limits of this, or whether you can just freely use all of network-managers capabilities inside a container.
Another idea would be to have a script on the host that when triggered will change the host IP address. Then depending on how you approach this, you could trigger this script from the container. That way you don’t have to worry about crossing host/container environments too much.
These are a couple of the thoughts off the top of my head. Though I’ve yet to test either method very thoroughly, so no guarantees to either. It’ll probably need some playing around with.
Your first solution worked well, I just had to install nmcli inside the container (by adding “RUN apt-get -q -y update && apt-get install network-manager” in the buildcommands of the vscode extention for Torizon).
The hardest part was to call nmcli from a .NET application but this point is now solved.
I’m not sure what you mean by “approved” and “production worthy” since this heavily depends on your own use-cases and requirements.
But in general trying to change something like the network configuration on the host OS from inside a container, is already a bit of a odd use-case. Since containers by design are meant to be isolated from the host. Yet here obviously if we want to dynamically change the network configuration we have to break that host-container isolation just a bit. Really it’s just a matter of perspective in terms of “proper” way to do things.
Mind you the ways I highlighted in this post aren’t the only possible ways to do this. They are just the ways that we know of and are known to work.