Hi all, I'm running a self-hosted OpenZiti deployment on a single Azure VM, where the controller and the edge router live together, it was setup using the install script, i'm planning to switch that do docker.
The VM currently uses the azure provided domain, so this will change. I want to move the controller + router onto a new VM with a new hostname/domain. The new VM will be hosted on a different infra provider. The domain change is the part that concerns me the most.
The network isn't huge, but i would like to avoid reenlisting everything. Here's a summary of what's currently enrolled/running:
Controller: 1
Identities: 13
Edge routers: 2 (one in the vm, one inside a k8s cluster)
Services: 12
What's the cleanest migration path?
I've setup the entire thing using terraform, so recreating everything will not be such a big issue, reenrolling everything is gonna be a bit cumbersome as i don't have direct access to all the devices, i would like to avoid this if i can without doing a lot of work.
The closest thing that i could find for my problem is
But here it's only a port change, and also the post is quite old 1.5 years ago, i saw that there is a clustering mode for controllers now and i was hopping that it might help.
Any pointers to docs, existing migration guides, or community experience with controller relocation would be very much appreciated. Thanks!
but i will completely change the domain, the current domain is ....cloudapp.azure.com, this will definitely change.
Or do you mean after i setup the new vm + domain, have the new domain point to the azure vm?
but i will completely change the domain, the current domain is ....cloudapp.azure.com, this will definitely change
That's the exact case newListener (ctrl channel) and newAddress (REST/edge API) were built for -- a domain change without re-enrolling. They were added in v0.24.5. Routers learn the new ctrl address over the control channel, and SDK clients pick up a Ziti-Ctrl-Address HTTP response
header from the old controller and auto-rewrite their identity ztAPI on the next request -- no re-enrollment, no per-client edits.
The rough flow I'd try:
Regenerate the controller's ctrl and edge server certs to include BOTH the old and new hostnames as SANs (the controller refuses these settings if the new hostname isn't in the cert).
Add newListener: tls:NEW_DOMAIN:8440 under ctrl.options and newAddress: NEW_DOMAIN:8441 under each web.bindPoints[] on the old controller, then restart it -- routers reconnect
and record the new ctrl address; clients receive the header and rewrite their config.
Stop the old controller, copy the quickstart dir (configs + pki + db) to the new VM at the same absolute path, flip advertiseAddress and each bindPoint address to NEW_DOMAIN, drop
the newListener / newAddress lines, and start there.
Bring the old controller back up briefly while clients drain -- mind that the two controllers' bbolt DBs diverge from the moment the new one starts, so keep the window short and only
make admin changes against the new one. Once everyone has drained, stop the old one for good.
On the Docker side: I have tested the above on plain VMs running the controller under systemd, not in a container, so you'll have to work out the Docker-specific bits yourself -- mounting the
migrated quickstart dir into the container (same absolute paths inside the container as the yaml expects), publishing 8440/8441, pointing the container's command at the same yaml, and
getting your TLS cert paths visible inside the container. The migration logic itself doesn't change, only the packaging.