Thank you for the long answer. The problem is that a persistent volume is not possible in the setup I would like to build. I would like to ask if you can make a feature request so automatic configuration pushing is possible without making a persistent volume in docker.
pvansluisveld Okay! First, I would like to learn more about the setup you are trying to build in order to understand better the problem space. Can you give me any extra information you have?
Do I understand correctly that each time you re-create the container, you manually (or via a script) re-inject the DVLS provisioner public key, and any other required component such as the certificate?
Are you also using the Devolutions Server REST API to automate some tasks already?
I’ve given some more thoughts to this, and it occurred to me that even if we implemented "Automatic configuration publishing" as-is, you would probably not be very satisfied with the end result.
The main issue becomes handling the transient period of time where the container has been recreated without its configuration, but still recognizes the public key. Heartbeat calls, preflight calls, etc - will not complete successfully. There is an interval for those calls, it's not instant, because the Devolutions Gateway is not pulling its configuration as soon as it's up. Even if it could pull, there's no way for DVLS to know what Devolutions Gateway it is in that direction, because the Devolutions Gateway doesn't remember its own id (its been fully reset).
At this point, maybe you would want to use the Devolutions Server API to immediately trigger the configuration pushing, right after you are done re-creating the containers with, e.g., your script, so that you can achieve minimal downtime.
For instance, maybe you want to first correlate the initial ID and container ID together using the Devolutions Server API, then re-create the containers with updated images, and then use another REST API endpoint to specify the initial IDs of the instances you just updated so Devolutions Server just do the right amount of work at the right time.
In such setup, you really have to be aware that you’ll still lose any persistent data such as logs, recordings and some transient data such as detailed traffic events which are pumped by Devolutions Server on interval. There is nothing we could do for the logs and recordings if you don’t use persistent storage, but it would be possible to expose an additional endpoint so you can trigger the traffic event collection earlier for specific Devolution Gateway instances.
Maybe there is yet another better approach to all of this. I would like to think about it a little bit more based on the exact constraints of the setup you want to achieve.
