TechnitiumSoftware
Feature Request: Cluster Configuration via IaC/Env
Hey @ShreyasZare, really love the Technitium product, been using it extensively for a few years now. Super excited to see the Clustering support land!
I am wondering - is there a way we could configure clustering support via IaC/Environment variables so we could programatically configure clusters in environments such as Kubernetes or other Infrastucture-as-code setups? Would love a one-click cluster configuration for Kubernetes, or via the few Ansible roles that exist for Technitium.
Appreciate your work and consideration!
Thanks for the suggestion. Will see how this can be added in later updates.
I would love to see this as well, would allow us to set up replication and get proper rolling updates without impacting DNS resolutions.
If one day the HTTP API becomes a RESTFUL API, which means the API results are decoupled from the view, then I may work on writing a Python SDK for them. Currently HTTP API is designed more like a BFF (Backend for Frontend). It contains visualization data, for instance, not only metrics.
When frontend and API fully gets decoupled, I can write the OpenAPI Spec, then Python SDK, then an unofficial Ansible package.
Having a Python SDK can also help writing an octodns provider as well.
These require huge effort but the biggest one is the architectural changes blocking them. It's hard to keep a project stable and make highly complex architectural changes.
One more note: Someone already created an Ansible solution: https://github.com/effectivelywild/ansible-collection-technitium-dns
One more note: Someone already created an Ansible solution: https://github.com/effectivelywild/ansible-collection-technitium-dns
I use this today for my VMs running technitium, but I'd love to integrate Technitium into my Kubernetes clusters, etc.
A true IaC (zero touch) would be excellent.
Has this role added cluster support? I haven't glanced in a while if I'm honest. Considering an initContainer as a short-term answer and might use this if so. Otherwise I'll stick to REST APIs.