Docker : ziti-router container : How do I set the controller name?

Support
1

Greetings,

I have been trying to move some of my on-prem routers into containerized versions. I am currently using my routers in a "LAN Gateway" use case, which spans On-Prem, as well as the cloud. The routers intercept specific TCP ports from on-prem storage appliances, and send them to the counterpart storage in the cloud. The reverse direction is also true. In my first attempt, I believe I was using the wrong container for what I was trying to do. Now, I am looking specifically at the ziti-router container, but when I run it using the docker compose standalone example here: Deploy the Router with Docker | OpenZiti
it does not seem to respect the name of the controller. By that, I mean, if I set the ZITI_CTRL_ADVERTISED_ADDRESS variable, it does not appear to honor my setting. It understands that I have set the port to 5443, but it only wants to address the controller as "ziti-controller". I was able to get it to connect by tricking it with /etc/hosts on the machine on which I run docker, however, that solution breaks the X.509 certificate, because it is not valid for "ziti-controller". At one point, I saw reference in the logs to an "endpoints" file not existing, so it was adding the controller based on the config. If I can pass the controller name in through an endpoints file, that would be sufficient. However, I would need to know where that file should live, and an example of the syntax of the file. There is actually a lot of stuff that lives in my current <router_name>.yaml file on my on-prem routers that I would need to pass in, including using the link dialer/listener connection groups to limit the routers that my on-prem routers attempt to reach out to. Is there a way to pass the entire config file into the container?

Thanks!

2

It sounds like that ctrl address var wasn't set during the first run, or you need to change the controller address (ctrl.endpoint).

You can edit the config.yml file in the container filesystem or mask it with a mounted config file. Either of those approaches allows you to continue with the existing enrollment without starting over with a new enrollment.

The default working directory is /ziti-router (Docker file), so your run command is relative to that directory.

This means you can mount an alternative file in /ziti-router/config.yml and pass run config.yml.

It's expected that the directory where the config.yml is found is writeable by the router PID. If you mount from the host filesystem you must ensure the container's EUID has permission to read the mounted file.

I haven't personally explored the LAN gateway use case with this router container, but can't think of a reason it wouldn't work. You'll need to grant the elevated privileges mentioned in the trproxy sidecar example, though this is not a case for a sidecar per se. You may need to use host network mode. I'd love to have a working sample if you're able to share it.