#Hello 👋 I just joined the community
tough sail
Welcome!
I think this is a great use case for Dagger, especially because you get a CLI "for free" every time you write a dagger function.
If you went ahead writing this in go yourself you may end up eventually building something that looks a lot like dagger.
There are already a few modules out in the world that work with helm, etc, have you tried these yet?
drifting finch
10/10 would also recommend Dagger for this. I have had a lot of success replacing the lion's share of Github Actions workflows for deploying K8s clusters and workloads with Dagger scripts that do the same, with the big advantage of testing locally with ease. If I don't need to change calling conventions for the Dagger functions I have a much higher degree of confidence that what works locally will work in GHA
You also get the advantage, if you choose to use it, of breaking your CI code into units and doing unit tests like you would with other kinds of more traditional application code.
Golang is by far my favorite choice for implementing Dagger functions but Typescript is not far behind IMO
light wasp
Thanks for the quick answers! This gives me enough confidence to go ahead with a proof of concept. This will probably become clearer to me as I play around with it, but I have one design question. Would I factorise my code using native functions and only create a dagger function if its something I might want to do on its own? Otherwise, when would I use a native function vs. a dagger function?
drifting finch
Can you give a concrete example of a small task you might want to accomplish?
I do recommend starting your experimentation with something small that requires a limited number of inputs.
And usually, in my experience, Dagger is a way to take a bit of tooling somebody has already implemented and make it easier to use reliably, not a total replacement for an existing tool
Opinions seem to vary in the community
light wasp
I have a series of steps to complete with lots of validation (for robustness) and guards (for idempotency) in between. A concrete flow would be:
- deploy cloudformation stacks
helm template | kubectl apply -f -a few apps- kubectl a few more resources
drifting finch
nice! I think you've got a lot of options there. Personally, I'd start with a validation step because you're probably taking in only a couple of inputs, something like:
- a docker container (built from a local Dockerfile, Dagger build instructions, or from a private registry) that contains your validation software
- the validation rules (either built into the container, or supplied as a mounted file)
- kubernetes connection information (a kubeconfig mounted as a secret, plus a namespace to validate)
and you're producing a simple yes/no output
I think this will give you a great feel for how Dagger works in a self-contained example
But any of those other tasks you mentioned would be okay places to start also
I might stay away from Cloudformation at the beginning because that will likely require management of AWS credentials, which might prove challenging your for first implementation. I spent literally 10 hours figuring out AWS <> Dagger for my first go around and I wouldn't recommend it for your emotional stamina
It's not hard once you get it but it will color your experience of the rest of the tool
My experience with AWS in general might be summed up as "it's really convenient until you need to figure out IAM" and that also applies here
light wasp
Thanks for the advice. I'll give it a go and see what I learn.