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?
Thanks!
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
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.