Who is using Timoni?

[stefanprodan]

If you are using Timoni in any capacity, on your home cluster or at work, it would be really great if you could let us now in a comment.

For those of you who can't publicly disclose the name of the organisation where Timoni is used, please reach out to me on CNCF Slack or on email contact (at) stefanprodan.com.

Thank you 🤗

[b4nst]

We started to roll Timoni in our K8s deployment at Loft. We were already using CUE for most our deployment but were relying on some custom made tools + script to achieve deployment.
Timoni makes it really more reliable for us, especially with module oci publish and bundle deployment.

[kol-ratner]

I am exclusively using timoni in conjunction with flux v2 and flagger to implement our kubernetes applications here at Clarity AI. So far very happy with the user experience and with the power of this toolset.

[kol-ratner]

I will add that we are of course very interested in learning about the timoni-controller for flux, any updates you are willing to share @stefanprodan would be much appreciated!

[disi]

I only heard about it last week. For now I use timoni in my home lab, working on some deployment instructions to build a cluster running AWX from scratch (works great :) ).
Once I am confident enough, I'll probably use it at work. IIRC, this can also deploy to Azure and GCP.

[ngeorger]

Hi! I'm starting to use Timoni right now, currently reading docs, also I'm writing a post about it in https://sredevops.org
If you have the time, let me know if we can have an interview for the site or anything else you think it could be interesting to our readers, mostly spanish speakers and latin american SREs and DevOps.
Regards from Chile and thank you very much.

[seifrajhi]

Hey @stefanprodan, really great tool, thank you for the efforts 💯
Any plans for virtual workshops or YouTube videos ? the would be nice

[stefanprodan]

Hey @ngeorger please reach out to me on CNCF Slack and we can setup a meeting.

@seifrajhi here is the recording of my Timoni intro talk with David https://www.youtube.com/watch?v=vIdJm2W21mI

[Nalum]

As a way to learn cue and Timoni I'm currently working on a Timoni module(s) for Cert-Manager. Quite enjoy working with it all so far.

[kaessert]

Started playing with it because we're hitting the ceiling with helm and there is simply no alternative yet which i consider worth investing time in switching to ... or is there? :) Absolutely loving it so far, great engineering decisions!

[ngeorger]

https://sredevops.org/es/timoni-una-nueva-y-facil-alternativa-a-helm-o-como-gestionar-aplicaciones-complejas-en-kubernetes/

As promised :)

[mmorejon]

I'm using Timoni in my home lab Raspberry Pi 4 + k3s + Flux v2. I created modules and bundles to deploy a group of microservices called Cinema. The Cue adoption wasn't hard and the Timoni foundations are great. I'm sure the community will appreciate this initiative.

To support this project I'm sharing these ideas across Kubernetes Community Days events, especially in Spanish where we have a wide community. I had the first one in KCD Spain (The video is pending to published on YouTube)

Let me know if you need some help to translate the website to Spanish in case of need, or to support the modules creation. @ngeorger, maybe we can collaborate to push a bit more this content in the Spanish community.

[emil-jacero]

I'm starting to use CUE and Timoni at home and work. Timoni will be used heavily by me because I can publish apps and bundles using OCI artifacts with signatures.

At work I am a Platform Engineer, we are checking out CUE and Timoni because we can build something that can scale and be deployed onto "difficult-to-reach" clusters. Mainly a way to repackage existing apps (eg. loki & grafana) and bundle them together and deploy something that works, but also for packaging company services.

Bundles are grouped into categories like storage or networking. We plan to piece multiple bundles together to create the platform as a whole. The operators of the clusters can choose for example which storage bundle they need for their cluster.

The only tools that have come close to solving this are Timoni and CUE. ❤️

The only missing piece for me at the moment is the timoni-flux-controller 😉

[ametad]

Hi Stefan,

Thank you for the work you put in Timoni, it really helps me to create valid Kubernetes manifests that are also configurable, easy to debug and maintain. I am still new at creating manifests to deploy our software to Kubernetes and I find it so much easier with Timoni to find out how all kinds of resources are structured. Therefore I make less mistakes during development 👍

I use Timoni at work, because I am already busy building a CD pipeline with Flux. And because you're one of the developers at Flux I looked at your other projects too, that way I found out about Timoni.

Because there is not yet a Timoni Flux Controller, I use Timoni as a templating engine. Which is already very handy! But I also would love it when Flux could handle Timoni modules/bundles 🎉

What I still try to figure out is how I could include encrypted secrets from a Git repo to create k8s manifests with Timoni.

Keep up the good work @stefanprodan and thank you!

[robinkb]

Hi Stefan,

Thanks for developing Timoni!

I am currently reworking the automation for the bare-metal Kubernetes cluster in my homelab using Timoni and Flux. I initially developed the automation using Terraform, but got frustrated with its limitations when working with Kubernetes. Dealing with CRDs is especially painful. I am new to Flux, Cue, and (of course) Timoni, so it's quite a learning curve at the moment.

I chose Timoni probably for the same reason as many of us. I am fed up with Helm and dealing with pushing YAML through text templating. We deserve better, more sophisticated tools. Timoni looks very promising.

Eager to see where this project is going, and perhaps make some contributions!

[salotz]

Currently evaluating Timoni primarily as a kubernetes application delivery format. My company is building cloud-native products for the pharma industry and we need to deploy on BYO cloud primarily. Wouldn't say I'm using Timoni yet fully. I mostly was looking for:

• sane parametrized YAML generation (hadn't used CUE before but it seems good for the job)
• potential for client-side parametrization (timoni is easy enough to install on a cloud shell and parametrize via YAML/JSON)
• non-GitOps deployment
• some thought given to secret mgmt.
• support for easily generating different, but closely related results (i.e. a thoughtful implementation of composable components via Bundles & Modules)
• deployment mechanism supports ordered/staged application

I would still like to see some more thought out support for airgapped compatible installs and bundling of all artifacts needed for deployment into a single OCI artifact (e.g. imgpkg).

I would also like to see support for consumer self-service upgrades via a web UI (something like kubeapps or kapp-controller).

I looked at and tried other tools like Helm (of course...), Tanka (jsonnet), and kapp.

Helm is ... helm. It was going to kill us as a small team to keep using it. Everything you need to do is hard and it provides very little value except that consumers already have it installed, are likely familiar with it, and supports client side template expansion. Using well done charts is usually a decent experience as long as they aren't subcharts, which begs the question of what that meta-tool is? The Timoni module systems seems much better on the surface at least.

Tools like Tanka were great but very oriented towards internal deployments and specific directory structures and no redistributable artifacts. Also after learning Cue I see a lot of flaws in the jsonnet approach (that admittedly wouldn't have effected a smaller product like ours as much.) Kapp was the closest since in theory you can combine any YAML generation you want, except that this only really works for internal projects and you must use the kapp-controller for client-side generation. This is overkill to have a controller for this and it only supports a few template generators and primarily Helm and ytt (ytt is a no-go for me in templating).

One last comparison I will make is our K8s development environment/CI tool Garden which is great as its like a semi-scriptable build system that makes it very easy to set up DAGs of steps to do for a deployment (including tests). I would like to see more features towards this "build script" functionality for client-side installations.

[chrisalbright]

We are transitioning to a Kubernetes based cloud infrastructure. One of our goals leading us to do this is minimizing complexity and friction for dev teams deploying apps. We've explored a number of options, including straight yaml manifests, Kustomize, custom templates, custom controllers, Helm charts... None of these provide the level of abstraction or maintainability we require to achieve our goal.

I'd looked into Cue alone, and I like it very much - while it may be more complex than I'd like to impose on dev teams, I thought it would be a suitable language for abstracting some of the details of Kubernetes deployments.

Timoni so far appears to check all the boxes. Cue give us schema and validation, We are still evaluating it, and are working on a prototype but I am fairly certain it will become our preferred method for configuration management.

[lion7]

I'm currently using Timoni in my homelab to (post-)bootstrap my Talos Linux cluster.

Talos Linux is awesome, but you still have to install a CNI / CSI / Ingress after installing it to a bare-metal server. The hard part there is that there is a need for an ordered apply, e.g. I first want to have CNI up, then deploy MetalLB (needs CNI) and then the Ingress controller (needs external LB IP from MetalLB).

This is the bundle I'm using as an example of how powerful Timoni is for me:

bundle: {
	apiVersion: "v1alpha1"
	name:       "infra"
	instances: {
		// Flux AIO
		"flux": {
			module: url: "oci://ghcr.io/stefanprodan/modules/flux-aio"
			namespace: "kube-system"
			values: {
				hostNetwork:     true
				securityProfile: "restricted"
				controllers: notification: enabled: false
				env: {
					"KUBERNETES_SERVICE_HOST": "127.0.0.1"
					"KUBERNETES_SERVICE_PORT": "7445"
				}
			}
		}
		// CSI
		"openebs": {
			module: url: "oci://ghcr.io/stefanprodan/modules/flux-helm-release"
			namespace: "kube-system"
			values: {
				repository: url: "https://openebs.github.io/openebs"
				chart: {
					name:    "openebs"
					version: "*"
				}
				helmValues: {
					// https://github.com/openebs/openebs/blob/main/charts/values.yaml
					engines: {
						replicated: mayastor: enabled: false
						local: {
							lvm: enabled: false
							zfs: enabled: false
						}
					}
					// https://github.com/openebs/dynamic-localpv-provisioner/blob/develop/deploy/helm/charts/values.yaml
					"localpv-provisioner": hostpathClass: isDefaultClass: true
				}
				sync: targetNamespace: "kube-system"
			}
		}
		// Load Balancer Controller
		"metallb": {
			module: url: "oci://ghcr.io/stefanprodan/modules/flux-helm-release"
			namespace: "kube-system"
			values: {
				repository: url: "https://metallb.github.io/metallb"
				chart: {
					name:    "metallb"
					version: "*"
				}
				sync: targetNamespace: "kube-system"
			}
		}
		"metallb-config": {
			module: url: "oci://ghcr.io/lion7/modules/metallb-config"
			namespace: "kube-system"
			values: pool: addresses: ["94.*.*.*/32"]
		}
		// Ingress Controller
		"traefik": {
			module: url: "oci://ghcr.io/stefanprodan/modules/flux-helm-release"
			namespace: "kube-system"
			values: {
				repository: url: "https://traefik.github.io/charts"
				chart: {
					name:    "traefik"
					version: "*"
				}
				helmValues: {
					// https://github.com/traefik/traefik-helm-chart/blob/master/traefik/values.yaml
					persistence: enabled: true
					certResolvers: letsencrypt: {
						email:        "***redacted***"
						tlsChallenge: true
						storage:      "/data/acme.json"
					}
					ports: websecure: tls: certResolver: "letsencrypt"
				}
				sync: targetNamespace: "kube-system"
			}
		}
	}
}

[salotz]

@lion7 Agree about ordered applies. Helm makes ordering and dependencies beyond painful to deal with. Injecting specially built init containers, debugging hook ordering between multiple subcharts, dealing with orphaned hook resources... terrible.

I do think that Timoni could use something more advanced like dependency graphs for install ordering as a special case which could provide some speedups and remove the need for manual topological sorts, but hey I'll take the low level primitive over "not possible" any day.