I am currently automating the deployment of a Ziti network using ArgoCD. During this process, I am trying to determine the necessary steps for upgrading or reconfiguring the Ziti network.
From what I understand, upgrading the controller and routers involves using the new version of Helm charts provided by the OpenZiti project. Is it advisable to only update the image used by the chart, or is there a strong correlation between the chart version and the Ziti version?
Additionally, are there any special steps to consider when reconfiguring the Ziti network? For instance, if I change the endpoints (advertisedHosts) of a controller, I assume the PKI is updated by the cert-manager, which would then require me to re-enroll my routers. Is that correct?
Are there any other settings on the controller(s) or routers(s) that require additional steps (like re-enrollments) when changed ?
There's a weak correlation between the chart and app version. We routinely bump the chart version along with the latest stable release of each app after a minimal amount of automated testing. Here's the workflow that ensures the chart is still upgradeable from the current latest chart version: helm-charts/.github/workflows/miniziti.yml at main · openziti/helm-charts · GitHub
Historically, we've managed to avoid major revisions of the chart version in most cases, and it's always a good idea IMO to pin the major version, at least, so you can opt-in to any potentially breaking changes. Case in point, the router identity migration script you noticed in your GitHub PR about making that Helm hook optional, which was designed to gracefully transition to a new way of persisting the identity without breaking existing Helm releases.
One important thing to remember is that the ziti controller upgrades the database schema, so it's essential to possess a controller database snapshot if you must downgrade the ziti controller app version for any reason, such as a failed Helm release upgrade (link to Linux backup hint). Database snapshots are not yet automated in any of the open source deployments. Here's a Kubernetes-specific hint.
The snapshot is persisted in the same PVC as the active database, which is a single file.
Correct, Cert Manager will reissue the certificates with the new DNS SAN. You may be able to transition gradually and gracefully by adding an extra DNS SAN in advance of retiring the old domain name.
Changing the permanent FQDN of the Ziti controller can be catastrophic because all existing identity and router enrollments will no longer be able to reach the controller, so they'll need to be re-enrolled. There's a re-enrollment operation for both identities and routers that allows you to avoid re-writing any policies that may @mention the enrolled entities directly, rather than by #roles.