OpenZiti declarative deployments

Hello, when deploying environments we generally wish to use a declarative model as much as possible, such as a repo with committed infrastructure as code using Terraform for cloud resource provisioning and NixOS for declarative OS configuration and services.

Are there examples of declarative deployments for OpenZiti available so I can start thinking about how best to do this within our framework?


For the most part, I would say we really don’t have anything exactly like you’re looking for just yet. It’s absolutely on our backlog of ‘things to do’ but for better and worse we don’t have any lack of ‘things to do’ so it’s just not been gotten to yet. I know there is another user on discourse doing this sort of thing though. I don’t know if they have shared anything yet. Maybe they’ll see this or someone working with them will comment.

I can think of two places that seem to cover what you’re looking for. One is the helm chart that we have to deploy the openziti ziti-edge-tunnel into a kubernetes cluster. You can find that NetFoundry Helm Charts | charts or GitHub - netfoundry/charts: Helm charts depending on what you want to look at.

The other would be docker and docker compose which you can find one for the ziti-edge-tunnel over at ziti-tunnel-sdk-c/docker at main · openziti/ziti-tunnel-sdk-c · GitHub and you can look at how the quickstarts operate with the ones over at ziti/quickstart/docker at release-next · openziti/ziti · GitHub These are not “meant for production” but they are there to help learners start up an environment easily. They are very opinionated about how it works, what gets deployed etc.

We don’t yet have official containers (yet), nor anything other than that. You could also take a look at the GitHub - openziti/fablab: The Fabulous Laboratory . It’s definitely more in line with what you’re looking for but it’s not a Terraform plugin, it’s a thing of it’s own. You might find it interesting though :slight_smile:

1 Like

Thank you! I’ll take a look at those resources.

Since we would normally prefer to load up all config possible per service into a single config file that is then provided to the service daemon, whether it’s json, yaml, toml, etc, I’ll be paying attention to what imperative commands I’ve seen in the example quickstarts that can instead just be provided directly in a single config file to the service daemon startup command.

Any remaining configuration commands that must remain imperative, maybe such as one time client registrations, I’ll look into adding separate bootstrap services or preStart scripts which utilize bootstrap-complete type markers once successfully executed.

I’ll probably be aiming to configure systemd daemon services for OpenZiti on the base OS, but will fall back to docker use as an alternative if I hit some blockers there.