In the new multicontainer architecture - totally awesome by the way! - is it possible to start, stop, or restart a service container from another container?
Say I have container1 and I want to restart container2 for some reason? Can I use the supervisor api to perform this action from within container1?
Hi @donfmorrison!
There are actually a few supervisor endpoints for that, but they aren’t documented yet, and they reference services by an imageId that is not available to the containers anyways, so you currently wouldn’t be able to use them.
We’re still working on completing the “v2” supervisor API so we’ll keep this use case in mind. Would you mind telling us a bit more about your use case to understand how/why you want to do this?
@pcarranzav let’s say I have 3 microservices running:
ui
api
some_continuous_worker
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!
We have a similar set-up and would need the same functionality (maybe even a little bit extended) to restart containers.
Set-Up:
config_saver
service1
service2
We also safe configs (basically the same as loading them from a db, in our case they are saved to a shared volume) and we want to restart service1 and send a message to service2 to reload the configs (it should not be restartet)
We would love to see the documentation soon on what you @pcarranzav implemented already and want to support @donfmorrison 's need for
restart a particular microservice container from another container
Regarding signaling to the service to reload a config - you could you expose a small API on that container, that upon a correct request would handle it as you’d like it (e.g. reloading a config). That would probably the most versatile one, since while restart a service is pretty universal, other behaviours like reload depends on the software running in that service, and needs to be handled appropriately - and your application is in the best place to handle it, IMHO.