Automatically Publish Gateway Configuration for DVLS Gateway in DVLS Server within Docker architecture

Hello @pvansluisveld

There is currently no such option to automatically run "Publish Gateway Configuration" when the configuration is changed.

But the better answer is: you usually don’t need to automate “Publish Gateway configuration” at all.

What’s happening in your setup is almost certainly this:

• When you recreate the Gateway container, it comes up “fresh” and has lost its local Gateway state (its gateway.json, provisioner key material, cert references, etc.).
• DVLS then detects the gateway is out-of-sync and you use “Publish Gateway configuration” to push the required config back to the gateway so it can operate again (and in some cases you then also publish the revocation list).

The Docker-friendly fix I would recommend is to persist the Gateway config folder.
Instead of automating the UI configuration pushing, make sure the container does not lose its config/state when recreated.
On Linux, the Gateway config is stored in the Gateway configuration file (gateway.json) on disk.
So in Docker, mount a persistent volume/bind mount for the directory where gateway.json (and related files) live.

Example using Docker Compose:

services:
  gateway:
    image: devolutions/devolutions-gateway:<tag>
    ports:
      - "7171:7171"
      - "8181:8181"
    volumes:
      # Persist gateway.json + keys/certs/etc
      - gateway_config:/etc/devolutions-gateway
volumes:
  gateway_config:

With that in place, updates become the standard safe pattern:

docker compose pull
docker compose up -d

Because the config is persisted, the recreated container comes back up already configured, and DVLS shouldn’t require you to “Publish Gateway configuration” again (unless you actually changed something DVLS needs to push).

If you still want "automatic configuration pushing", I can still evaluate this as a feature request.

Best regards,

Hello @pvansluisveld

There is currently no such option to automatically run "Publish Gateway Configuration" when the configuration is changed.

But the better answer is: you usually don’t need to automate “Publish Gateway configuration” at all.

What’s happening in your setup is almost certainly this:

• When you recreate the Gateway container, it comes up “fresh” and has lost its local Gateway state (its gateway.json, provisioner key material, cert references, etc.).
• DVLS then detects the gateway is out-of-sync and you use “Publish Gateway configuration” to push the required config back to the gateway so it can operate again (and in some cases you then also publish the revocation list).

The Docker-friendly fix I would recommend is to persist the Gateway config folder.
Instead of automating the UI configuration pushing, make sure the container does not lose its config/state when recreated.
On Linux, the Gateway config is stored in the Gateway configuration file (gateway.json) on disk.
So in Docker, mount a persistent volume/bind mount for the directory where gateway.json (and related files) live.

Example using Docker Compose:
services:
gateway:
image: devolutions/devolutions-gateway:<tag>
ports:
- "7171:7171"
- "8181:8181"
volumes:
# Persist gateway.json + keys/certs/etc
- gateway_config:/etc/devolutions-gateway
volumes:
gateway_config:
With that in place, updates become the standard safe pattern:
docker compose pull
docker compose up -d
Because the config is persisted, the recreated container comes back up already configured, and DVLS shouldn’t require you to “Publish Gateway configuration” again (unless you actually changed something DVLS needs to push).

If you still want "automatic configuration pushing", I can still evaluate this as a feature request.

Best regards,

@Benoit Cortier
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.

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.