@pcarranzav let’s say I have 3 microservices running:
I need to make a configuration change to the worker process and my thought was that I would update the config for that “worker” – stored outside the worker container, maybe in a db or config file – and I was thinking I needed a way to trigger that “worker” to use the new config. My thought was it would be easy to just restart that microservice. The api service will actually update the config, and then I was thinking it could restart the worker container using the supervisor device api.
It’s likely not a “good” design but it seemed better than exposing an api layer on the “worker” just for this purpose. I should probably just detect this change from the worker instead and have it react accordingly. Thanks for making me think through this.
Although, I still think this “restart a particular microservice container from another container” could be useful!