Is Timoni With CUE a Helm Replacement?
Вставка
- Опубліковано 1 сер 2024
- I did it. I found a replacement for the management of Kubernetes resources with Helm.
I know that I said "I found a Helm replacement" quite a few times only to follow a while later with "maybe not". I think that this time I can say "I found a Helm replacement" without changing my mind a few months later.
The replacement is... Timoni backed by CUE.
#timoni #cuelang #helm #kubernetes
Consider joining the channel: / devopstoolkit
▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
➡ Gist with the commands: gist.github.com/vfarcic/bdabd...
🔗 Timoni: timoni.sh
🎬 Is CUE The Perfect Language For Kubernetes Manifests (Helm Templates Replacement)?: • Is CUE The Perfect Lan...
🎬 Manage Container (Docker) Images, Helm, CNAB, and Other Artifacts With Harbor: • Manage Container (Dock...
▬▬▬▬▬▬ 💰 Sponsoships 💰 ▬▬▬▬▬▬
If you are interested in sponsoring this channel, please use calendly.com/vfarcic/meet to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).
▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
➡ Twitter: / vfarcic
➡ LinkedIn: / viktorfarcic
▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬
🎤 Podcast: www.devopsparadox.com/
💬 Live streams: / devopsparadox
▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
00:00 Introduction to Timoni
05:06 Use Timoni as a Helm Replacement
09:14 Define Timoni Modules
11:47 Build and Push Timoni Modules
12:30 Final Thoughts on Timoni - Наука та технологія
Do you think Timoni (and CUE) can replace Helm for your apps?
Yes or rather I hope so. As for 3rd party charts I am still motivated to address them as well. I vendor all our 3rd party charts and I have thought about running helm template to make a kustomize or kpt package from the manifests but I am concerned the upgrade and maintenance would be too much but I it is not off the table. If you have any thought about how you might covert a 3rd part app into a Timoni package I would love to hear it. --- great stuff!
@tonygilkerson conversion is not a problem. Keeping up with future upgrades is the issue.
@@DevOpsToolkit I agree but I already modify the charts and therefor go through a diff-review process each upgrade so I am willing to put in the work, therefore I am interested in knowing how to perform the conversion. I want to convert a Helm chart to a Timoni module that my users can then consume and apply any set of values at deploy time (I don't use my Charts I have "users"). The problem I see is that Helm charts will omit entire sections of manifests or even entire manifests when certain values are "disabled" ... Therefore, how do I convert the helm chart to Timoni module and have that module contain both the enabled and disabled option? The only way I can think to do it is to generate a different module for each permutation, yuck!
@tonygilkerson CUE has import command to convert from yaml. I haven't tried it with Timoni but I'm guessing that once you have it a cue it should not be much additional work.
I will check out CUE import from my existing manifests! What’s one more layer 😅
To answer the title, i sure hope so. This is such a breath of fresh air
Last weeks cliff hanger was worth it :) Great overview and summary as usual!
always love your content, great stuff to watch.
Thanks!! That's awesome!
very good video! I agree, I would like to see more alternatives to helm getting adopted also from third party providers! Timoni and cue looks like the escape hatch we need!
Hiding Helm completely behind Grafana Tanka and a small jsonnet wrapper made me stop worrying about Helm. Fully upstream vendored helm chart, allowing custom values to be sent in to the helm generator while still allowing custom overrides in jsonnet gives me all the flexibility I need.
Huge tanka / Jsonnet fan, could never understand how helm became the de-facto “standard”
Huge tanka / Jsonnet fan, could never understand how helm became the de-facto “standard”
great video! helm has a first mover advantage, as you say, but i think it currently benefits more from the network effect: we are all using it because everybody else is using it.
for timoni to catch on, it needs to have enough compelling advantages to break through the inertia. you make a good case that it does..
For third party apps it stands no change precideñy because of the network effect. First party apps are easier to penetrate.
Great video. Timoni looks very promising and I'm definitely going to kick the tires on it. I hate working with Helm. Thanks!
CUE is neat, I do like it, but developing non-trivial CUE structures is still a sweet-sour experience. The error message you often get is useless due to how the logical/unification engine works, and so far there's not been any features added to CUE that would make this better.
I'm curious if you have heard of KCL and tried it? Would love to see a comparison video, pros and cons etc, with the other yaml template options we have.
I tried it and I'm using it. It's on my to-do list for a subject of one of the upcoming videos.
Awesome @@DevOpsToolkit
Thanks, very interesting. But do you know if it's possible to use Timoni directly from Terraform? I have searched online but it seems not possible at the moment.
Rimini outputs yaml and yaml can be applied with terrsform. Now, if the question is whether you can use terrsform to execute timing that will produce yaml which you can apply with terrsform, the answer is yes, through the exec finction. Still, don't waste time with terrsform for managing kubernetes resources. Use argo CD or flux.
@@DevOpsToolkit Thank you for the response. By company policy I am required to use Terraform. I admit I am not familiar with Argo and Flux. I will investigate ;)
It would be awesome if cue and timoni could extend helm charts so that we can make our first party modifications to third party apps and write them in cue.
as someone using argocd to install and maintain apps, how would argocd deploy a timoni image?
I tend to output it to yaml and store it in git repo. I believe that only yaml is readable enough for everyone to understand it. Now, how we get it that yaml is a different story (e.g. helm, Timoni, ytt, cdk8s, etc.).
@@DevOpsToolkit So, you are suggesting generating yaml outputs before pushing new manifests to Git? Is it the only way to deploy my application using ArgoCD and Timoni? In my humble opinion tools like Helm or Kustomize are more natively integrated into other tools and in this case, timoni looks very raw to be adopted at this moment. What do you think? Does it worth supporting extra logic just to apply timoni to the project?
@kostyazgara3481 i tend to often keep raw yaml no matter how it is generated. Since building images is a part of ci pipelines, pushing yaml should not be a problem (one more command). That being said, Timoni is now supported natively in Fluz and it's only a plugin away from argo CD if raw yaml is not a good option.
@@DevOpsToolkitbut, in ArgoCD, the helm are only generating the template and applying the manifests individually, right?
Using Timoni with ArgoCD should do the same, otherwise, you had to put a action before the ArgoCD to generate the manifests. I don’t like this approach for a IDP.
Maybe i am missing something
@liciomatos action is necessary since you need to build an image and change argo CD app manifest with a new tag.
You know it's very funny story Victor, that all of those months ago I bring up CUE language, (which not it seems is becoming more towards actual adoption)... so today I see your video and say hey! What's this CUE like again? ... better go check it again. So I ask Google: hey google! "cue vs jsonnet" ? To spit out some frame of reference to compare against... But then the 3rd seach result now is: KCL. With this article: "Faster than Jsonnet, CUE, and HCL, We Made ... - Dev Genius". So there we have it. CUE isn't yet fully adopted by the industry. But is already been given some successor as KCL / Kusion. I have no idea how this industry keeps functioning, other than to do some exodus some moving from AWS to Azure it seems... OK so i am looking forwards to your upcoming video or commentary / analysis on KCL / Kusion! (hopeful for 1 day, that we might eventually get to the final templating language, and stop, that can become some sort of a major part / majority share industry standard).
Hi can you please do video on "mirrord" an alternative to telepresence
That request is quite a coincidence since I'm having it on my short list 🙂
@@DevOpsToolkit great.. thanks
Done :)
ua-cam.com/video/KewUfKFPlMQ/v-deo.html
Hmmm. Okay, so as a vendor of one such third-party app, should I stick with Helm due to wide adoption and familiarity, or should I distribute my app using Timoni?
As a vendor, you should create helm charts. That's a must and everything else is optional. The reason is simple; adoption.
Is timoni mod push . similar to helm package?
It is 🙂
Essentially, cue is a replacement for helm templating while Timoni is a replacement for helm commands.
Good tool, but not enough to adopt or even try. Firstly, I agree with your action points, but they require a lot of effort for implementation, and I can assume that it could be the hardest way to move from helm. It will be the same situation as we saw in the IaS war between Pulumi and Terraform. So my assumption is that whoever was first will win.
I do tend to agree with that. Helm is bad, in part because it was first so there was nothing to compare it with. However, being first also means that companies invested in it and investments once made are rarely going away unless there are very big pain points that often have to affect business. So yeah, Helm is here to stay but that does not mean that we should not be looking for better alternatives.
I think what could drive Timoni adoption for 3rd parties is if it catch the eyes of platform teams in bigger companies. There, they often rewrite helm charts anyway so it matches their specific requirements, why not do it with Timoni instead? And if enough people are doing that, I would expect some Timoni modules to pop up in public repos. It's a big if, but let's be optimist!
Here's the idea. Combine Timoni with ChainGuard images.
you could use kustomize
I was like, what ? a CEMENT ? :)
Tanka
@BananaInCondom It still has it's rough edges, but nothing really structural.
And the foundation on jsonnet is elegant and powerful.
I use it and I love it, the only thing missing from Jsonnet are maybe types and/or validation. There are some efforts in this direction but these are just POCs unfortunately. Other than that its awesome
uhh! never!
The next question is if someone has tackled a conversation utility from a Helm Chart to a Timoni package. That would help bootstrap third party app adoption.
If you use helm template to convert into yaml, you can convert yaml to cue. That would mean that you'd need to add variables manually. It works, but it's not effortless. Timoni might come up with a more streamlined process.
@@DevOpsToolkit , that sounds good. One hole in my knowledge is how to convert Helm Hooks. For example, the helm hooks used by the Sentry helm chart. The reason I mentioned the Sentry chart is that I recently was using the helm template to export the Manifests and stopped when I realized that I couldn't apply the generated hook Manifests when I applied the others. I'm going to have to revisit that soon for my own edification.
I'm not using Sentry myself so I'm not sure which hooks it uses. Can you give me an example? I'm asking that because a) Timoni tends to have better order when applying resources and b) GitOps tools like Argo CD tend to have a mechanism how to define sync ordering. Those two are common reasons for using hooks so they might not be needed anymore.