Hi everyone! We are considering to move our GitOps...
# getting-started
a
Hi everyone! We are considering to move our GitOps Kubernetes part to Pulumi. Currently we use jsonnet and do some mutations on helm charts during post rendering. For example, we replace the helm hooks with argocd syncwaves annotations. We also don't need to apply this yaml, we just render it to our gitops repo and then it gets applied by argocd. Could anyone share their experience with using Pulumi specifically for yaml rendering without direct cluster application? And maybe solving similar problems, such as post-rendering helm mutations?
d
Using the "yaml render mode" can be problematic because it is a preview feature and lots of functionality in the provider assumes a cluster connection. In my experience with using Pulumi to manage Kubernetes workloads, one of the best aspects is how you create both the Kubernetes objects and the supporting cloud resources in a uniform way. For example, you can create IAM roles and easily set chart values based on the resultant ARNs, e.g. to install a component like cert-manager. Another approach to consider is to use the Pulumi Kubernetes Operator in combination with ArgoCD, as outlined here: https://www.pulumi.com/docs/iac/using-pulumi/continuous-delivery/argocd/ The benefit of this approach is that it lets you direct application deployments using ArgoCD, while using Pulumi as the execution engine, thus enabling ArgoCD to deploy whole workloads incl. their cloud resources. Something to consider.
a
Yes, exactly! Being able to use cloud metadata we get during deployment is the main reason we are considering pulumi! But I was thinking about the GitOps bridge architecture described in

this talk

The problem is, that we already have a huge amount of apps managed by ArgoCD and the migration to Pulumi might be painful. Meanwhile, if we would stick to just generating yaml - ultimately it doesn't matter what tool we use, so switching from our current jsonnet setup should be very easy
d
The gist of the "operator-based" solution is that you use ArgoCD to generate
Stack
resources, to compel the operator to deploy a given Pulumi stack. For example, you could use jsonnet to write some yaml containing a Stack object, which then drives an ordinary Pulumi deployment. This strategy is more practical then trying to shoe-horn the Pulumi engine directly into ArgoCD.
🙏 1
a
Gotcha, thanks!